CompTIA Server+ Practice Test (SK0-005)

The issue is an insider threat enabled by one person holding conflicting duties. Applying separation of roles divides those duties so that the team that manages and reviews audit logs is different from the team that administers the servers. Because the log reviewers have no rights to change configuration, and the server admins have no rights to purge or alter logs, collusion would be required to repeat the attack. Copying logs to WORM media, enforcing complex passwords, or adding a host-based IDS harden security, but none of those measures by themselves stop an administrator from both disabling logging and later certifying that systems are compliant-only a clear separation of duties does.

Adding targeted folder and process exclusions for the backup application removes the heaviest scanning load from the antivirus engine only for the data paths that cause contention. Microsoft, Veritas and Veeam all document that scanning backup repositories or backup-application binaries can severely reduce throughput or cause job failures, and they recommend excluding those paths or executables to restore performance without disabling protection entirely.

Disabling real-time protection during the job sacrifices continuous malware defense and is unnecessary once exclusions are in place. Replacing the full scan with a quick or cloud-delivered scan would violate the stated compliance requirement to keep the nightly full scan. Increasing scan priority makes the antivirus consume even more CPU and I/O, further starving the backup process. Therefore, defining specific exclusions for the Veeam executables and repository folders is the best host-hardening adjustment in this scenario.

The switch that displays the NetBIOS name table of a remote host when the host is identified by its IP address is -A. The -a switch performs the same task only when you specify the remote computer's NetBIOS host name. The -n switch lists the local computer's registered NetBIOS names, and -R purges the local NetBIOS name cache and reloads any #PRE entries from the LMHOSTS file; neither of these displays a remote host's name table.

The correct next step after verifying a server is no longer in use is to submit a formal request through the change management process. This ensures that the decommissioning is formally documented, approved by all stakeholders, and scheduled, which prevents unauthorized changes and service disruptions. Updating the asset management database occurs as part of or after the decommissioning is complete, not before formal approval. Physically disconnecting the server is a later action performed after receiving approval from the change management process. Terminating vendor maintenance contracts is also a step that follows the formal decision and approval to decommission the server.

The correct answer is the slot designated as PCIe x16 (physical), x16 (electrical). For a PCIe card to operate at its maximum potential, it must be installed in an expansion slot that meets both its physical size and its required number of electrical lanes. A GPU with a PCIe x16 connector requires a physical x16 slot to fit, and it needs x16 electrical lanes to achieve its maximum data transfer bandwidth. The slot that is x16 physical but only x8 electrical would create a bottleneck, halving the potential performance of the card. The x8 and x4 slots are both physically too small for the x16 card and provide insufficient bandwidth.

The correct answer is Recovery Point Objective (RPO). RPO defines the maximum acceptable amount of data loss, measured in time, that a business can tolerate. In this scenario, the 15-minute tolerance for data loss is the RPO.

• Recovery Time Objective (RTO) is incorrect because it specifies the maximum time allowed to recover the system and restore service after a failure, not the amount of data that can be lost.
• A Service Level Agreement (SLA) is a formal contract between a service provider and a customer that documents service expectations. While an SLA would likely contain the required RPO and RTO values, it is the agreement itself, not the specific metric for data loss tolerance.
• Mean Time to Recover (MTTR) is a historical metric representing the average time it has taken to recover from past failures. It is a measure of performance, not a forward-looking planning objective like RPO or RTO.

Newer processors often require updated microcode and power-management tables that reside in the system's BIOS/UEFI image. If the firmware predates the processor's release, the board may not recognize the silicon and will halt during POST with a processor-incompatibility message. Flashing the motherboard to the latest vendor-approved BIOS/UEFI revision adds the needed microcode, allowing the new CPU to initialize correctly. Clearing CMOS, under-clocking memory, or disabling Hyper-Threading do not add microcode support and therefore will not prevent an incompatibility boot failure.

A cold site is essentially an empty shell that provides only fundamental infrastructure (electricity, HVAC, network access). Because it contains no pre-installed servers, storage, or data, its recurring cost is the lowest of the common DR-site options. The trade-off is a longer recovery time while equipment is delivered, installed, and backups are restored-often several days-making it appropriate when an RTO of multiple days is acceptable.

A hot site, in contrast, is fully equipped and kept in sync with production workloads, offering near-immediate failover but at the highest operating cost. A warm site already hosts some hardware and possibly partial data replication, shortening recovery time but still costing more than a cold site. An active-active metropolitan cluster keeps live services running in two or more datacenters simultaneously; this provides the fastest recovery and virtually no downtime but is by far the most expensive to maintain. Therefore, the cold site is the only option that satisfies the strict cost constraint while meeting the stated four-day RTO.

Most server vendors state that RDIMMs and LRDIMMs are electrically incompatible and cannot coexist in the same system. Mixing the two types causes memory-training failures, so the system stops at POST. The fix is to use only one DIMM technology across all populated slots. Removing the existing RDIMMs and repopulating every channel exclusively with LRDIMMs of identical type and speed eliminates the incompatibility and allows the server to complete POST. Placing different DIMM types in separate CPUs or slots, lowering the clock speed, or changing slot order does not resolve the fundamental electrical mismatch, so those actions will not restore normal boot operation.

The correct answer is template deployment. A virtual machine (VM) template is a master copy of a virtual machine that includes a pre-installed operating system, applications, and all necessary configurations and patches. Deploying new VMs from a template is the most efficient method for creating multiple, identical servers because it simply clones the master image, which is significantly faster than performing a full OS installation for each machine. This method ensures consistency and drastically reduces deployment time, which directly addresses the scenario's requirements.

• An unattended installation uses a script or answer file to automate the steps of a traditional OS installation. While this provides consistency, it is slower than template deployment because it must run through the entire installation and patching process for each of the 50 servers individually.
• A Physical to Virtual (P2V) conversion is a process used to migrate an existing physical server into a virtual machine. It is not a method for deploying multiple new servers.
• A bare metal installation involves installing an operating system directly onto a physical server's hardware. This is incorrect because the scenario specifies the deployment of virtual servers.

The administrator accepted Disk Management's default Master Boot Record (MBR) style when the disk was first initialized. MBR can address only 2 199 023 255 552 bytes (≈ 2.2 TB) because its 32-bit LBA field tops out at 4 294 967 295 sectors. Everything beyond that limit shows up as unallocated and cannot be added to an existing MBR volume. Re-initializing the disk with the GUID Partition Table (GPT) removes the 2 TB ceiling. Because Windows cannot convert a non-system MBR disk to GPT in-place, the safest remediation is to back up the data, delete the partition table, initialize the disk as GPT, recreate the volume(s), and restore the data. Changing NTFS cluster size or sector format does not bypass the 32-bit addressing limit, and there is no indication that the hardware is defective, so those options would not resolve the problem.

The maxage directive enforces time-based retention. Setting "maxage 180" tells logrotate to discard rotated archives that are more than 180 days old, regardless of how many files exist. The rotate directive limits the number of archives kept, not their age. The size directive triggers rotation when a file reaches a given size but does not control retention, and delaycompress only postpones compression of the most recent archive; it has no effect on how long archives are kept.

An incremental backup saves only the data that has changed since the last backup of any type (full or incremental). To perform a complete restore from an incremental backup chain, you must start with the last full backup and then apply every subsequent incremental backup in the order they were created until the point of recovery. In this scenario, the server fails on Thursday afternoon. The backups available are the full backup from Sunday, and the incremental backups from Monday, Tuesday, Wednesday, and Thursday. Therefore, the correct restore procedure is to first restore the Sunday full backup, and then apply the Monday, Tuesday, Wednesday, and Thursday incremental backups in chronological order. Skipping any incremental backup in the sequence would result in an incomplete data set and data loss.

A simulated (test) failover boots duplicate virtual machines at the recovery site so staff can verify that operating systems and applications start correctly. To avoid service disruption or IP conflicts with the still-running production VMs, the replicas must be connected to an isolated, non-routable network segment. Pausing replication is unnecessary and would defeat the goal of continuing protection, shutting down the primary VMs turns the exercise into a live failover, and updating DNS redirects users away from the primary site-both actions management explicitly forbids.

The correct answer is that the security patch updated a shared library to a version incompatible with the application. OS updates and patches often include updated versions of shared system libraries for security and functionality improvements. However, custom-developed applications can be dependent on specific versions of these libraries. When a library is updated to a version the application was not designed for, it can lead to dependency conflicts, causing the application to fail. The error message "incompatible version" in the logs points directly to this cause. This scenario is a classic example of a downstream failure caused by an update.

• Reset service account permissions would likely produce 'access denied' errors, not library version errors.
• A corrupted patch file would more likely cause the entire update process to fail rather than causing a specific post-reboot runtime error.
• Insufficient disk space would prevent new log entries or cause other file-write errors, which is not the issue indicated by the specific error message.

The correct answer is to consult the server vendor's Hardware Compatibility List (HCL). The HCL is the authoritative source that lists all hardware components, such as RAID controllers and drives, that have been tested and certified to work with a specific server model. Verifying components against the HCL before purchase is the most critical step to prevent incompatibility issues, which could cause system instability or prevent the server from booting entirely. Updating firmware is a necessary step but should be done after confirming the hardware is compatible, as the HCL often specifies required firmware versions. Checking power consumption is part of the overall installation plan but is secondary to ensuring basic hardware compatibility. Relying on compatibility between the card and drives alone does not guarantee they will work with the specific server motherboard and its BIOS/UEFI.

Only dual-port SAS disks expose two completely independent target ports on the drive itself. In a dual-domain topology each port can be cabled to a different HBA, so the operating system or RAID controller can continue I/O through the surviving path if the other path fails. SATA drives are single-port devices; they would need an interposer or port-multiplier and still could not provide true redundant access. NVMe U.2 SSDs attach over PCIe rather than SAS and cannot connect to the mini-SAS HD backplane used in this design. A wide-port SAS implementation aggregates several PHYs for more bandwidth between controllers and expanders, but an individual drive still presents only one domain and therefore does not add path redundancy. Dual-port 12 Gb/s SAS drives are therefore the only option that meets every stated requirement.

The correct answer is synchronous replication. This method writes data to both the primary and secondary storage locations at the same time. A write I/O operation is not considered complete until an acknowledgment is received from both the primary and secondary sites. This ensures that the data at both sites is identical, which achieves a Recovery Point Objective (RPO) of zero, meaning no data is lost during a failover. This is critical for transactional systems where data integrity is paramount.

• Asynchronous replication is incorrect because it writes data to the primary storage first and then copies it to the secondary site after a delay. This creates a non-zero RPO, as some data may not have been replicated at the time of a failure.
• Snapshot replication is incorrect as it captures the state of data at specific points in time. This method is suitable for less critical systems where some data loss between snapshots is acceptable, but it does not meet the zero RPO requirement for a critical OLTP database.
• Bidirectional replication describes a topology where two sites can send and receive replicated data, allowing either to act as the primary. While useful for active-active scenarios, it describes the direction of data flow, not the timing mechanism that guarantees zero data loss. Bidirectional replication can be implemented either synchronously or asynchronously, but synchronous replication is the specific method that meets the zero RPO requirement.

The metric that measures the probability that an unauthorized (impostor) subject is incorrectly granted access by a biometric system is the false acceptance rate. It directly tracks instances where a reader matches a presented template to a stored template that does not belong to the user, so it is the most relevant value for assessing how frequently attackers might slip through. The false rejection rate instead tracks how often legitimate users are denied, the crossover (or equal) error rate shows the point where false accepts and false rejects are equal-useful for tuning but not for measuring one class of error in isolation-and the failure to enroll rate concerns problems during the initial registration process, not day-to-day access decisions.

Industry guidance recommends running restore tests on a predictable schedule (weekly, monthly or quarterly) that reflects the criticality and change rate of each workload, and repeating the test whenever major system or data changes occur. This approach proves that data can be recovered while keeping the number of tests-and therefore the administrative overhead-manageable.

• Answer 1 follows that guidance, so it is correct.

• Answer 2 waits an entire year and only decrypts media, which does not confirm that systems or applications can be started from the backup.

• Answer 3 relies solely on backup logs; log success does not guarantee a usable restore because media corruption, application-level inconsistencies, or configuration drift can still prevent recovery.

• Answer 4 performs a full restore after every backup. Although this would provide strong assurance, it is usually impractical for most organizations because of the time, storage, and compute resources required for daily full-scale restores.

Therefore, scheduling periodic restore drills that are more frequent for critical or recently changed systems is the most appropriate strategy.