CompTIA SK0-005 Practice Test 2026

Explanation:

The server is stuck at "Configuring Memory............." during POST (Power-On Self-Test), even after reboot, indicating the BIOS/UEFI firmware cannot complete memory initialization.

This phase involves:

Detecting installed DIMMs,
Training memory channels (SPD data, timing, voltage),
Building the memory map for the OS.

A failed DIMM (e.g., ECC error, dead chip, loose seating, or incompatible module) halts this process—BIOS retries indefinitely or hangs to prevent data corruption. Out-of-Band (OOB) management (iLO, iDRAC, IPMI) remains accessible because it runs on a separate baseboard management controller (BMC) with independent firmware and network stack, not reliant on system RAM. However, the host OS is unreachable because memory training never completes, preventing boot loader or kernel loading. LED diagnostics (if available) often show amber memory fault lights.

Why Others Are Incorrect

B. The VRAM is insufficient

VRAM (Video RAM) is GPU-specific and irrelevant to server console POST. Memory configuration occurs before video initialization; insufficient VRAM causes display issues after boot, not a hang during memory training.

C. The RAID cache has failed

RAID controller cache (BBU or flash) failure triggers storage degradation or write-back disable, logged post-boot. Memory configuration happens before PCI enumeration or RAID BIOS—cache issues do not block early POST phases.

D. The BIOS needs to be updated

Outdated BIOS may cause compatibility issues with new DIMMs, but typically results in no boot with error code or beep codes, not an indefinite hang at "Configuring Memory". A truly incompatible BIOS would fail quickly, not loop retries.

Reference:
Server+ Objective 5.1 – Troubleshoot boot failures including memory initialization errors during POST.
HPE iLO / Dell iDRAC User Guide: “OOB management remains operational during host POST hang due to independent BMC.”
UEFI Specification v2.9: Memory Initialization Phase – “System halts on unrecoverable DIMM failure.”

Explanation:

The scenario describes a classic test of a high-availability cluster. Let's break down the steps:

Initial State: A two-node cluster with one node "active" (handling the workloads) and one node "passive" (on standby).

Test Action: Ann shuts down the active node. This simulates a failure.

Cluster Behavior (Failover): The cluster correctly detects the failure, and the passive node becomes active. This process is known as Failover. The cluster is now functioning, but on the secondary node.

Goal: Ann wants to return the cluster to its original configuration, meaning she wants the originally active (and now powered-on) node to resume its role as the active server.

The specific feature that allows an administrator to manually or automatically return the workload to the primary node after a failover is called Failback.

Failback is the process of switching operations back to the primary, preferred, or most powerful node after it has been restored to a healthy state. This is exactly what Ann needs to do to complete her task.

Why the Other Options Are Incorrect:

A. Heartbeat: This is the mechanism the cluster uses to monitor the health of its nodes. A constant communication signal (the "heartbeat") is sent between nodes. If the signal is lost, the cluster assumes a node has failed and initiates a failover. While essential for the initial failover, the heartbeat itself does not perform the return-to-original operation.

C. Redundancy: This is a design principle, not a specific action or feature. Having a passive node is a form of redundancy, but the term describes the state of having backup components, not the process of switching between them.

D. Load Balancing: This is a technique to distribute workloads across multiple nodes to optimize resource use and prevent any single node from being overwhelmed. This scenario describes a high-availability (active-passive) cluster, not a load-balancing (active-active) cluster. In a load-balanced setup, there is no concept of "returning to an original" active node in the same way.

Reference:

This question touches on the core objective of high-availability clustering, which is a key topic in the SK0-005 exam, specifically under Domain 5.0: Disaster Recovery.
Understanding the difference between failover (automatic recovery to a secondary system) and failback (restoring operations to the primary system) is a fundamental concept for a server administrator.

Explanation:

To ensure members of the accounting department can access the server, the server must be placed on the same subnet/VLAN as their devices. A subnet mask of /24 corresponds to the network 172.16.25.0 – 172.16.25.255, which allows devices to communicate directly without routing. The IP address 172.16.25.90 falls within this valid network range, and the chosen default gateway 172.16.25.254 is a typical router address for that subnet. This configuration ensures seamless communication within the VLAN and proper routing outside the network if needed.

Why Other Options Are Incorrect

B. 172.16.25.101/16 | Gateway: 172.16.25.254

A /16 mask (255.255.0.0) places the server in a much larger network: 172.16.0.0 – 172.16.255.255. Although the IP is in the same numerical range, this subnet would not match the VLAN configuration used by accounting. Mismatched subnet masks cause devices to interpret different network boundaries, resulting in inconsistent connectivity or failed local communication.

C. 172.16.25.254/24 | Gateway: 172.16.25.1

The IP 172.16.25.254 is typically used as the subnet’s default gateway address or a reserved network boundary value, and should not be assigned to a server. Additionally, the proposed default gateway 172.16.25.1 does not align with common gateway assignments on this VLAN, leading to routing failures and no external communication.

D. 172.16.26.101/24 | Gateway: 172.16.25.254

The IP address is in a different network entirely (172.16.26.0/24). Devices on 172.16.25.0/24 would treat it as a remote subnet, requiring routing even for local access. This breaks direct communication with accounting department users and would prevent access without proper routing rules, which are not indicated.

Reference
Devices must share the same IP network range, subnet mask, and VLAN to communicate directly. The default gateway must be within the same subnet and typically uses the highest usable address for structured network design.

Practical Networking Tip

When deploying a new server:
Confirm assigned VLAN and subnet mask from network documentation
Choose an unused static IP inside the correct VLAN range
Use the proper gateway defined for that subnet
Verify connectivity using ping to local hosts, then gateway, then external networks

Explanation:

The disk is already mounted at /newdisk (as stated: “mounted a new hard disk… with a mount point of /newdisk”), but users cannot create files or directories — a classic symptom of the filesystem being mounted read-only.

In Linux, a filesystem can be mounted read-only due to:

Default mount behavior for certain devices (e.g., some USB drives)
Errors detected during mount (e.g., journal replay issues)
Explicit ro option in /etc/fstab or during manual mount

To fix write access without unmounting, use the remount option with rw (read-write):
bashmount -o remount,rw /newdisk
This command:

Keeps the filesystem mounted
Changes mount options in-place
Enables write permissions immediately

Why the other options are incorrect:

A. echo /newdisk >> /etc/fstab
Incorrect. This only appends a malformed line to /etc/fstab. It does not define a valid filesystem entry (missing device, type, options, etc.) and does nothing to fix current mount. It also won’t remount anything.

B. net use /newdisk
Incorrect. This is a Windows command (net use) used to map network drives. It has no meaning in Linux.

D. mount -a
Incorrect. This mounts all filesystems listed in /etc/fstab that are not already mounted. It does not remount currently mounted filesystems and does not change options like ro → rw.

References:

CompTIA Server+ SK0-005 Exam Objectives

2.3 – Given a scenario, perform basic Linux server administration tasks → Includes mounting filesystems and modifying mount options.

Linux mount(8) Man Page

“-o remount,rw — Re-mount a currently mounted filesystem with new options (e.g., from ro to rw).”

Red Hat Enterprise Linux – Storage Administration Guide

“Use mount -o remount,rw /mountpoint to enable write access on a read-only mounted filesystem.”

Exam Tip:

Users can’t write + mount point already exists = likely mounted read-only → use mount -o remount,rw
This is a common SK0-005 troubleshooting question involving Linux storage administration.

Explanation:

The scenario describes a server where a critical service fails to start after a routine update, and rolling back the update does not resolve the problem. This strongly suggests that the service depends on other software components or system updates that are either missing or incompatible. In complex systems, services often rely on libraries, frameworks, drivers, or other supporting services to function correctly. When an update is applied partially or out of sequence, these dependencies may not be satisfied, leading to a service failure. This is not uncommon in environments where updates are applied selectively rather than using a full patching process.
A comprehensive troubleshooting approach in such cases involves checking event logs for dependency failures, verifying that all prerequisite updates for the service have been applied, and ensuring that supporting libraries or frameworks are compatible with the updated system. Without satisfying these dependencies, a service will repeatedly fail to start, regardless of reboots or rollback attempts.

Why Other Options Are Incorrect:

A. The server requires another reboot to complete the rollback:

While certain updates or patches may require multiple reboots, this is generally related to file locks or pending system changes. A service failing due to missing dependencies will not be fixed simply by rebooting. Event logs specifically indicate a core service failure rather than a system pending state, which rules out the need for an additional reboot as the primary cause.

B. The administrator is not authorized to run the service:

Permission or administrative access issues usually generate explicit error messages, such as “Access Denied” or “Insufficient Privileges.” In this case, the logs point to the service failing to initialize, not being blocked by user access. The administrator’s credentials are unlikely to affect a service that is configured to start automatically unless explicitly restricted, which is not indicated here.

D. The account used to run the service has expired:

An expired service account would prevent authentication-related operations, such as logging into the system or accessing network resources. It would trigger authentication errors rather than cause the service to fail due to missing libraries or system dependencies. Since the event logs indicate a core service failure immediately on startup, this points to a technical issue rather than an account or credential problem.

Reference:
Core services rely on a hierarchy of dependent components, frameworks, and libraries to operate correctly. Failure to meet these dependencies, especially after applying updates, is a common cause of service startup issues. Administrators should follow comprehensive patch management procedures, ensuring all updates and prerequisites are applied in the correct sequence, and check logs for dependency-related errors when troubleshooting service failures.

Practical Tip:

When a service fails after an update:
Review event logs to identify which dependencies are failing.
Verify that all prerequisite updates or supporting software are installed.
Check compatibility of all libraries or frameworks the service relies on.
Only consider account permissions or reboots after ruling out dependency issues.

Explanation

To effectively mitigate a recurring security breach caused by a software exploit, the administrator must address the root cause and harden the system's defenses. The initial virus removal is only a temporary fix; the underlying vulnerability must be closed. Furthermore, enabling a local firewall adds a crucial layer of defense, restricting unauthorized access and preventing future exploitation attempts. Finally, updating the antivirus ensures the system can detect and block the latest threats, maintaining long-term security and high availability.

Correct Answer (C, D, F)

Patch the vulnerability (C): This is the most critical step because the infection occurred due to "an exploit of a known vulnerability." If the flaw is not patched, the server remains vulnerable, and the infection will likely reoccur, directly preventing future mitigation.

Enable a host firewall (D): This adds a strong defense layer directly on the server. It controls incoming and outgoing traffic, limiting access to essential ports only. This can block future attempts to exploit the patched or any new vulnerability and helps maintain the server's availability by filtering malicious traffic.

Update the antivirus software (F): This ensures the endpoint protection can recognize and stop the latest strains of malware, including the one that just infected the server, and any variants that may appear in the future. Regular updates are key to maintaining robust security and availability.

Why Other Options Are Incorrect

A. Run a vulnerability scanner on the server.

While useful, scanning is a detection/assessment step, not a mitigation step. The scenario already identified the vulnerability ("an exploit of a known vulnerability"). The priority is to fix it (patch) and prevent the exploit (firewall/antivirus), not just confirm its existence.

B. Repartition the hard drive that houses the database.

Repartitioning is a destructive and time-consuming administrative task that does not inherently improve security or remove a software vulnerability. It would drastically reduce high availability and offers no security benefit over simply patching the flawed software.

E. Reformat the OS on the server.

Reformatting and reinstalling the OS is an extreme last resort for deep-seated rootkits or if the system integrity is severely compromised. It drastically impacts high availability (downtime). Since the issue is tied to a known vulnerability in the database software, patching and securing the system is a much faster, less disruptive, and more targeted mitigation strategy.

G. Remove the database software.

This would stop the vulnerability, but it would also stop the server from fulfilling its intended function (hosting sensitive data via the database). This action destroys availability, which the prompt explicitly states must be maintained.

H. Air gap the server from the network.

Air gapping is a security measure that physically isolates the server, but it makes the server unavailable to its users and the network, thus violating the requirement to maintain high availability.

Reference
This question touches upon fundamental principles of server security, incident response, and continuity of operations. A well-structured security posture dictates a multi-layered approach involving patch management to eliminate known flaws, host-based security (like firewalls) to control network access, and endpoint protection (like updated antivirus) to block threats. These actions are standard practices in the "Eradication and Recovery" phases of any security incident management framework.

Explanation:

In a high availability (HA) cluster (e.g., VMware vSphere HA, Microsoft Failover Cluster, Linux Pacemaker, etc.), the best practice before patching a host is to live-migrate (or failover) all virtual machines to another healthy node. This ensures:

Zero downtime for workloads (if using vMotion, Live Migration, etc.)
The host being patched is completely empty of running VMs
The cluster remains fully protected during maintenance

This process is called putting the host into Maintenance Mode, which automatically triggers VM migration.

Why the other options are incorrect:

A. Disable the heartbeat network.
Incorrect and dangerous. The heartbeat network is how cluster nodes detect failures. Disabling it risks split-brain scenarios, false failovers, or total cluster outage.

B. Fallback cluster services.
Incorrect. “Fallback” is not a standard term in HA clustering. You do not revert services before patching — you evacuate them to another node.

C. Set the cluster to active-active.
Incorrect. Most HA clusters are already active-active or active-passive by design. Changing the cluster mode is not required and may not even be applicable or safe mid-operation.

References:

CompTIA Server+ SK0-005 Exam Objectives

4.1 – Explain the importance of patching and updates in a virtualized environment
3.5 – Given a scenario, perform server maintenance in a clustered environment

VMware vSphere Documentation – Entering Maintenance Mode

“Before applying patches, place the ESXi host in Maintenance Mode. vSphere DRS automatically migrates all powered-on VMs to other hosts.”

Microsoft Failover Cluster – Node Maintenance

“Use Suspend-ClusterNode and Move-ClusterVirtualMachineRole to evacuate VMs before patching.”

Red Hat Enterprise Linux HA Add-On

“Relocate services using pcs resource move before patching a node.”

Exam Tip:

Patching a host in HA cluster → always evacuate workloads first via failover/live migration.
Never disable heartbeat or change cluster mode.
This is a core SK0-005 best practice question on cluster maintenance.

Explanation

The administrator has successfully completed the diagnostic phase of troubleshooting. The root cause has been identified and confirmed through testing. The logical progression is now to move from diagnosis to resolution.

Correct Answer D. Establish an action plan.

Why it is correct:

Before making any changes to a production system, especially a server, it is critical to plan the solution.
An action plan outlines the specific steps required to resolve the issue, considers potential risks, defines a rollback plan in case the solution fails, and may schedule the implementation during a maintenance window to minimize user impact.
Implementing a fix without a plan can lead to unintended consequences and further downtime.

Why Other Options Are Incorrect

A. Document the findings and actions:

While documentation is a crucial part of the entire troubleshooting process, it is typically the final step, performed after the issue has been fully resolved.
Documenting findings now, before implementing and verifying the fix, would be premature.

B. Escalate the issue to the management team:

Escalation is for when the problem is beyond the administrator's scope, requires approval, or cannot be diagnosed.
In this case, the administrator has already successfully diagnosed the root cause, so escalation is unnecessary.

C. Implement the solution:

This is the step that comes after establishing an action plan.
Jumping directly to implementation without a plan is reckless.
The plan ensures the solution is applied safely, systematically, and with a clear path for recovery if something goes wrong.

Reference
This follows a structured troubleshooting methodology, such as the CompTIA troubleshooting theory or the ITIL framework for incident and problem management. These methodologies emphasize establishing a plan of action after identifying the root cause and before implementing any changes to ensure a controlled and predictable resolution.

Explanation

An orange (or amber) light on a server’s front panel typically signals a non-critical but degrading fault, such as a failing power supply, predictive failure of a drive, or a discharged RAID cache battery. After a power outage, components with capacitors or batteries (like the RAID controller’s write-cache battery or BBWC) can lose charge if the outage exceeds their hold-up time, triggering a warning. Slow performance often correlates with RAID arrays running in write-through mode due to a failed or depleted battery, bypassing the cache. The technician should prioritize checking components tied to front-panel health indicators and post-outage behavior rather than CPU or general RAM issues.

Correct Answer & Why It Is Correct
D. RAID battery

It is correct because the RAID controller’s battery-backed write cache (BBWC) or flash-backed write cache (FBWC) maintains data during power loss. A power outage can drain the battery if it is old or degraded, causing the controller to disable write-back caching and switch to slower write-through mode, which explains the performance drop. The orange LED is commonly mapped to RAID subsystem warnings (e.g., battery <24-hour learn cycle or failure), making this the most direct next step.

Why Other Options Are Incorrect

Option A: CPU

CPU errors usually trigger red/critical LEDs, system halts, or thermal events in logs, not orange degradation lights. Performance slowdown from CPU would show high utilization or throttling in OS metrics, not a front-panel warning tied to a recent outage.

Option B: Power supply

A failing PSU often shows amber on its own status LED or via IPMI, but a single PSU failure in a redundant setup would trigger a critical alert or automatic failover, not degraded performance. Post-outage slowness without system crash points away from PSU as the primary cause.

Option C: RAM

Memory faults produce ECC errors, correctable/uncorrectable warnings in SEL logs, or blue-screen crashes, typically with red/amber memory-specific LEDs. There is no direct link between a power outage and RAM-induced slowness unless corruption occurred, which would not produce an orange system health light alone.

Reference
Dell PowerEdge Server Front Panel Indicators (iDRAC9 User Guide – Amber = Degraded); HPE ProLiant Gen10 LED Status Table (System Insight Display – Orange for RAID Battery); Broadcom MegaRAID Storage Manager (Battery Learn Cycle & Write Policy Impact on Performance); LSI/Avago RAID Controller Technical Brief (BBWC Discharge After Power Loss).

Explanation

The backup type being used is B. Incremental because it requires another file (specifically, the last full backup and potentially other incremental files) to fully restore the data.
An Incremental backup only captures the data that has changed since the last backup of any type (either a full backup or the previous incremental backup).
Because each incremental file (like 01062020.bak) contains only a small "slice" of the changes, it cannot be used alone to restore the entire system or dataset to the point in time it was taken.
Restoration from an incremental backup set requires the initial full backup (the base) PLUS all subsequent incremental backups applied sequentially, up to the desired restore point. This is why the technician noted that 01062020.bak "requires another file to restore data."

Incorrect Options

A. Full

A Full backup contains a complete copy of all the data at the time it was created. It is the only backup type that can be restored entirely on its own, without requiring any other backup files.

C. Snapshot

A Snapshot is a point-in-time reference (like a freeze-frame) of a virtual machine or a volume's file system, typically storing only the differences from the base image. While a snapshot is dependent on a base image, it is a feature of virtual environments or file systems (like ZFS) and not a traditional file-based backup type that fits the .bak extension and the described dependency chain as closely as an incremental backup does.

D. Differential

A Differential backup is dependent on another file, but only one other file:
the last full backup. A differential backup captures all changes since the last full backup.
To restore from a differential set, you only need the most recent full backup and the most recent differential backup. It does not require all previous differential or incremental files, unlike the incremental method.