CompTIA Server + SK0-005 (V5) Exam Practice Test 3

Cost of security versus risk explicitly weighs the expense of an additional security measure against the actual risk that measure would mitigate, recognizing that not every dataset justifies the same level of security investment, particularly low-value, already-public data. Retention policy scheduling instead addresses how long data is kept, which is a different data security consideration from evaluating whether a specific security control's cost is actually justified by the risk it addresses. Applying this cost-versus-risk evaluation consistently helps an organization allocate its security budget toward controls that protect its genuinely highest-value and highest-risk data, rather than spreading effort evenly regardless of actual risk level.

Replicating the problem under controlled conditions confirms it is a genuine, consistent issue rather than a one-time fluke or user error, providing a reliable way to verify later whether an attempted fix actually resolved the problem. Without successfully replicating the problem first, it becomes much harder to confidently confirm whether a subsequent fix actually addressed the real issue or whether the problem simply did not recur by chance during testing. This step occurs early in the troubleshooting methodology, right alongside gathering information and identifying what has recently changed, before moving on to establishing and testing a theory of probable cause.

Outdated intrusion detection configurations, specifically stale detection signatures that were never updated after initial installation, explain why a known attack pattern failed to trigger an alert, since detection tools rely on current signature data to recognize known threats. This differs from properly configured firewall rules or correctly enforced group policy, both of which represent working, properly maintained controls rather than a configuration issue causing a detection gap. Establishing a regular update schedule for intrusion detection signatures, rather than a one-time installation with no ongoing maintenance, is essential for these tools to remain effective against evolving known threats over time.

A bad or degraded network cable is confirmed as the most likely root cause here, since replacing the physical cable itself immediately resolved the intermittent connectivity issue, after configuration-based causes had already been ruled out. A misconfigured NIC, DNS failure, or improper VLAN configuration would instead typically require a configuration change to resolve, rather than being fixed simply by physically swapping the cable. This scenario is a good reminder that even in an era of increasingly complex network configurations, a simple physical layer problem like a degraded cable remains a common and often overlooked cause of intermittent connectivity issues.

Missing dependencies describes exactly this situation, where an application update requires a specific supporting component, such as a shared library version, that is not currently present on the server, causing the installation to fail. Clock skew instead involves system time synchronization problems, which is an entirely unrelated category of issue from a missing software dependency. Resolving a missing dependency typically requires installing the specific required component first, then retrying the original update, rather than repeatedly attempting the same failing installation without addressing the actual missing prerequisite.

Array rebuild describes the automatic process a RAID array undergoes to restore full redundancy after a drive failure, which in this case was still in progress when a second failure occurred. Multiple drive failure specifically describes the second failure occurring before the rebuild completed, which exceeds RAID 5's single-drive fault tolerance and results in total data loss, since RAID 5 can only survive one simultaneous drive failure. This scenario illustrates exactly why larger, higher-capacity arrays with longer rebuild windows are increasingly built using RAID 6 instead, since RAID 6's two-drive fault tolerance specifically protects against this kind of second failure occurring during an extended rebuild period.

Memory errors and failures directly explain a kernel panic, since corrupted or failing memory can cause the operating system kernel to encounter an unrecoverable error and halt abruptly to prevent further data corruption or instability. A power supply fault instead would more commonly cause a complete unexpected power loss rather than a kernel panic specifically pointing to a memory-related diagnostic cause. Running memory diagnostic tools to confirm which specific module is failing, then replacing that module, directly addresses this root cause rather than only reactively restarting the server after each panic without addressing the underlying hardware failure.

Making one change at a time and testing after each individual change is a core troubleshooting methodology principle, since applying three changes simultaneously makes it impossible to determine which specific change, if any, actually resolved the problem. This violation also creates risk, since if a problem does get resolved, the technician cannot confidently roll back only the ineffective changes without also potentially reversing the change that actually fixed things. Disciplined, one-change-at-a-time troubleshooting takes more individual test cycles but produces a much clearer, more reliable understanding of exactly what actually fixed the problem.

A synthetic full backup combines a previous full backup with subsequent incremental backups to construct a new full backup image, without needing to re-read all of the original source data directly from the production system again, which reduces the load placed on production systems compared to running a traditional full backup from scratch. This approach can significantly reduce backup windows for very large datasets, since only the incremental changes need to be read from production, while the bulk of the synthetic full backup is assembled from already-backed-up data. Understanding synthetic full backups as distinct from traditional full backups helps explain why backup software might report a full backup completing much faster than expected given the total data size involved.

Hardware hardening disables unneeded physical ports and sets a BIOS password to prevent unauthorized changes to boot configuration, addressing security at the physical hardware and firmware configuration level rather than the operating system or application layers. OS hardening instead addresses operating system-level configuration, such as disabling unused services, which is a related but distinct hardening layer from physical port and BIOS-level protections. Applying hardware hardening alongside OS and application hardening provides defense at every layer, since a vulnerability at any single layer alone could otherwise be exploited if the other layers are not similarly protected.

Unwanted duplication and unwanted publication are specific data loss prevention concerns covering exactly this pattern, where sensitive data is first copied to an unauthorized location and then later exposed publicly, whether deliberately or accidentally. This differs entirely from hardware failure or CMOS battery failure, both of which are technical hardware risks unrelated to data being copied and exposed through human action. Data loss prevention tools specifically designed to detect and block this kind of unauthorized copying and sharing help catch this pattern before sensitive data actually reaches an unintended public audience.

Auditing logins tracks exactly which user accounts logged in over a given period, providing visibility into who accessed the system and when. Auditing group memberships and deletions instead tracks changes to group membership and any deleted files, which are different but related auditing categories covering permission changes and data removal rather than simple login activity. Comprehensive auditing across all of these categories, logins, group memberships, and deletions, together with user activity broadly, provides a much fuller picture of what has actually happened on a system than any single auditing category alone.

Architectural reinforcements include building design features like reflective glass and signal-blocking materials specifically intended to prevent outside observation and electromagnetic eavesdropping, integrating security considerations directly into the facility's physical construction rather than relying solely on separate add-on controls. Fencing and security guards instead address perimeter and personnel-based access control, which are different physical security categories from reinforcements built into the architecture itself. Some highly sensitive facilities go further with datacenter camouflage, deliberately making the building's purpose and location inconspicuous, as an additional architectural security layer.

A blade enclosure consolidates multiple thin server modules, called blades, into a single shared chassis that provides common power, cooling, and networking infrastructure to every blade simultaneously, improving density and reducing redundant infrastructure compared to individual standalone servers. A tower chassis instead is a standalone, freestanding server unit with its own dedicated power and cooling, which is a completely different form factor from a shared blade enclosure. Blade enclosures are especially valuable in space-constrained data centers where maximizing compute density within limited rack space is a priority.

A license true up periodically reconciles actual software deployment counts against purchased license counts, ensuring the organization pays for any additional licenses needed to cover deployments that have grown beyond the originally purchased amount, which commonly occurs under volume licensing agreements. Skipping regular true-up reconciliation risks the organization operating out of compliance with its licensing agreement, potentially leading to unexpected costs or penalties if a vendor audit later discovers unlicensed deployments. Performing this reconciliation proactively and regularly, rather than waiting for a vendor-initiated audit, gives the organization more control over managing and budgeting for its licensing compliance.

Warranty status tracks whether a specific asset or component remains covered under the manufacturer's original warranty, directly informing whether a failed component qualifies for a free replacement or whether the organization must instead purchase a new part out of pocket. Life-cycle management instead addresses the asset's broader stage from procurement through disposal, which is a related but distinct asset management concern from the specific, narrower question of current warranty coverage status. Maintaining accurate warranty information as part of routine asset inventory avoids unnecessarily paying for a replacement part that would actually have been covered under an active warranty.

Script types like Bash and PowerShell represent distinct scripting languages suited to different operating system environments, Bash being native to Linux and Unix-like systems and PowerShell being native to Windows, though cross-platform versions of each do exist. Environment variables instead store system values like a configured installation path in a way that a script can reference dynamically, avoiding the need to hardcode a value that might differ between systems or change over time. Using environment variables rather than hardcoded values makes scripts more portable and maintainable across different systems, regardless of which specific scripting language the script happens to be written in.

A private cloud model runs workloads entirely on dedicated infrastructure owned and controlled exclusively by a single organization, providing maximum control over the underlying infrastructure at the cost of the organization bearing full responsibility for its management and maintenance. A public cloud model instead runs workloads on shared infrastructure operated by a third-party provider, which trades some direct control for reduced infrastructure management burden and typically greater elasticity. Choosing a private cloud model often reflects specific regulatory, security, or control requirements that a shared public cloud environment cannot adequately satisfy for that organization's particular workloads.

Failover automatically shifts a workload to a secondary node when the primary node fails, providing continuity of service despite the primary's failure. Failback then deliberately shifts the workload back to the original primary node once it has been repaired and is ready to resume its normal role, completing the full cycle back to the pre-failure configuration. Properly testing both failover and failback, rather than only failover, ensures the cluster can both handle an initial failure and cleanly return to normal operation afterward without introducing a new problem during the failback transition itself.

Deduplication identifies and eliminates duplicate copies of the same data block across the file system, storing only one actual copy and referencing it from every location that would otherwise contain a redundant duplicate. Compression instead reduces the actual size of stored data by encoding it more efficiently, which is a different technique from deduplication, since compression works on a single copy's actual content rather than eliminating redundant copies across the system. Both techniques can be used together to reduce overall storage consumption, with deduplication removing redundant copies and compression further shrinking the size of whatever unique data remains.

Static IP addressing assigns a fixed address by hand that never changes, which is appropriate for a critical server like a domain controller whose address other systems depend on remaining consistent and predictable. Dynamic addressing via DHCP instead automatically assigns addresses from a pool that may change over time, which is convenient for client workstations where the exact address rarely matters to other systems, but is generally undesirable for a server other systems need to reliably reach at a consistent address. Choosing static addressing for critical infrastructure servers like domain controllers avoids the disruption that could occur if a DHCP lease renewal ever assigned that server a different address.

A bare metal installation installs an operating system directly onto physical server hardware with no hypervisor layer involved, giving that OS direct, exclusive access to the underlying hardware resources. A virtualized installation instead installs the OS as a guest running on top of virtualization software, sharing the underlying physical hardware with potentially other guest operating systems on the same host. Choosing bare metal over virtualized installation often reflects a need for maximum direct hardware performance or a specific requirement that precludes running within a virtualized guest environment.

RAID 6 uses double distributed parity across the array, allowing it to tolerate two simultaneous drive failures without data loss, which provides stronger fault tolerance than RAID 5's single parity at the cost of slightly reduced usable capacity and write performance. This extra fault tolerance becomes increasingly valuable as drive capacities grow larger, since larger drives take longer to rebuild after a failure, during which a second failure becomes a genuine risk that RAID 5's single-parity protection would not survive. Choosing RAID 6 over RAID 5 for very large capacity arrays reflects this practical concern about extended rebuild windows increasing the real-world risk of a second failure occurring before the first rebuild completes.

A KVM setup provides direct local keyboard, video, and mouse access to a server, allowing hands-on administration without a separate dedicated monitor and keyboard permanently attached to every single server. A crash cart instead is a dedicated mobile cart specifically equipped with a KVM setup and other tools, designed to be wheeled to whichever server currently needs local hands-on attention, rather than requiring a technician to carry components individually. Both concepts work together, with the crash cart providing the mobile platform and the KVM setup providing the actual local input and display connectivity once positioned at the target server.

Write-intensive SSDs are specifically rated for durability under heavy write cycles, using more durable flash memory and additional over-provisioning to withstand the wear that high write volume workloads place on solid-state storage. Read-intensive SSDs instead are optimized and priced for workloads dominated by read operations rather than heavy sustained writes, making them a poor fit for a write-heavy workload that would wear them out prematurely. Choosing the correctly rated SSD wear category for a given workload's actual read/write ratio helps avoid premature drive failure and unplanned replacement costs.