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

Data at rest refers to data stored on a persistent medium, such as records on disk, which encryption at that layer directly protects if the storage medium itself is ever compromised or stolen. Data in transit instead refers to data actively moving across a network connection, requiring a different protection mechanism to secure the connection itself as data moves between systems. Recognizing that data requires different protection mechanisms depending on its current state is foundational to designing a comprehensive data security strategy that does not leave either state unprotected.

POST, or Power-on Self-Test, performs a hardware self-diagnostic check during startup, reporting numeric or alphanumeric codes that indicate exactly where in the startup process a failure occurred, which can dramatically narrow down troubleshooting compared to a generic failure to boot with no further information. These POST codes are typically documented by the specific hardware vendor, so consulting the correct reference for that exact server model is necessary to correctly interpret what a specific code actually indicates. Recognizing and correctly interpreting POST codes is a foundational hardware troubleshooting skill, since it often points directly to a specific failed component rather than requiring broader trial-and-error diagnosis.

A rogue process or service is an unfamiliar, unaccounted-for process consuming resources, which could indicate malware or unauthorized software running on the server, warranting immediate investigation rather than being dismissed as routine background activity. This differs from a properly configured firewall rule or validated file integrity checksum, both of which represent security controls working correctly rather than a security concern requiring investigation. Investigating an unfamiliar process typically involves identifying what the process actually is, whether it corresponds to any legitimately installed software, and whether it exhibits behavior consistent with malware before deciding on an appropriate remediation action.

The ability to reach a server by IP address but not by hostname or FQDN points specifically to a name resolution problem rather than a general connectivity problem, since basic network reachability is clearly still working. DNS failure or misconfiguration is the most likely cause, since DNS is specifically responsible for translating a hostname into the IP address that the client actually needs to establish the connection. A firewall blocking all traffic, a bad cable, or a misconfigured NIC would typically prevent reaching the server by IP address as well, which does not match this scenario's specific symptom pattern.

Clock skew occurs when a server's system clock drifts significantly out of sync with other systems it depends on, such as a domain controller, which can cause authentication failures since many authentication protocols rely on time-synchronized tickets or tokens that become invalid if the clock difference exceeds an allowed tolerance. A memory leak or buffer overrun instead are unrelated technical issues involving how an application manages memory, which would not specifically cause domain authentication failures tied to clock synchronization. Ensuring servers are properly configured to synchronize their clocks via NTP against a reliable time source prevents this specific and often confusing authentication failure pattern.

Misconfigured RAID reflects an array that was not properly set up for the drives actually installed, which can produce exactly this kind of unexpected capacity and degraded performance behavior. Mismatched drives specifically calls out that combining drives with different rotational speeds and capacities within a single array is a recognized cause of storage problems, since the array's overall performance is often constrained by its slowest member drive, and capacity calculations can behave unexpectedly with inconsistent drive sizes. Using matched, identical drives within a RAID array whenever possible avoids introducing this specific, avoidable category of storage problem.

CMOS battery failure causes a server to lose its BIOS configuration settings and system clock time whenever it loses power, since the CMOS battery is specifically responsible for maintaining these settings while the server is powered off. A failed power supply instead would typically prevent the server from powering on at all, rather than allowing it to boot but repeatedly losing its saved configuration. Replacing the CMOS battery, which is typically an inexpensive and straightforward repair, resolves this specific recurring symptom without requiring any deeper hardware investigation.

The troubleshooting methodology calls for testing a theory of probable cause before acting on it, since an untested assumption could lead to wasted effort or an unintended side effect if the theory turns out to be wrong. If the test confirms the theory, the administrator proceeds to plan and implement a fix; if not, a new theory is established or the issue is escalated. Jumping straight to a fix skips validating that the theory actually explains the observed symptoms, which risks applying a fix that does not actually address the real underlying cause.

A differential backup captures all changes made since the last full backup, regardless of any other backups taken in between, which means each successive differential backup grows larger over time until the next full backup resets the baseline. This differs from an incremental backup, which instead captures only the changes since the most recent backup of any type, making each incremental backup smaller but requiring every incremental backup since the last full backup to be applied in sequence during a restore. Choosing between differential and incremental backup strategies involves weighing backup size and speed against the complexity and total time required for a full restore.

OS hardening disables unused services, closes unneeded ports, and removes unnecessary software at the operating system level, reducing the overall attack surface before a server is placed into production. Application hardening instead addresses securing specific applications running on the server, such as installing the latest patches for that application, which is a related but distinct hardening layer from operating system-level configuration. Applying OS hardening as a standard step in server deployment, rather than only after an incident occurs, significantly reduces the number of potential entry points available to an attacker from the outset.

An insider threat comes from someone who already has legitimate authorized access, such as an employee with database access, misusing that access for harmful purposes like stealing sensitive data to sell. This differs from hardware failure or data corruption, which are technical risks unrelated to a person deliberately misusing legitimate access. Insider threats can be particularly damaging precisely because existing access controls are often designed to keep unauthorized parties out, rather than to detect misuse by someone who already legitimately holds valid credentials.

Role-based access control grants access based on a user's assigned job function, such as database administrator, tying permissions to that role rather than assigning them individually to each user. Rule-based access control instead enforces a blanket condition, such as blocking logins outside business hours, applying uniformly regardless of a user's specific assigned role. Combining role-based and rule-based access control within a single system, such as applying a time-of-day rule on top of otherwise role-based permissions, provides layered access logic rather than relying on only one model exclusively.

An access control vestibule, sometimes called a mantrap, uses two interlocking doors where the second cannot open until the first has fully closed, specifically to control entry one person at a time and help prevent tailgating by an unauthorized individual. A bollard instead is a sturdy vertical post designed to prevent vehicle intrusion, which is a completely different physical threat than controlling pedestrian entry through a vestibule. Combining an access control vestibule with other physical controls, such as card readers or biometric locks, provides layered physical security for particularly sensitive areas like a server room.

Floor load limitations must be verified before installing heavy rack-mount equipment, since an older building's floor may not be rated to support the combined weight of several fully loaded racks, and exceeding that rating creates a serious structural safety hazard. Rail kit compatibility and PDU placement are important installation details, but they do not address whether the floor itself can safely bear the equipment's weight in the first place. Consulting the building's structural specifications before installation is a foundational safety step that should never be skipped simply because rack layout and cabling details feel more immediately pressing.

Per-core licensing charges a fee based on the number of physical or virtual processor cores available to the application, which means a server with more cores available to that application incurs a higher licensing cost than an identical deployment with fewer cores, even running the exact same software. This differs from a flat per-server licensing model, which charges the same fee regardless of how many cores the server actually has. Understanding which licensing model a specific software product uses is important for accurately budgeting and for making informed hardware sizing decisions, since choosing a higher core count server could unexpectedly increase licensing costs under a per-core model.

Life-cycle management deliberately tracks an asset through every stage from initial procurement through active usage to eventual end of life and disposal, ensuring each stage is managed proactively rather than treating disposal as an unplanned afterthought once a device is no longer needed. Warranty tracking and labeling instead address specific individual details within the broader inventory record, which are components of, but not the complete picture of, full life-cycle management. Managing the full life cycle deliberately helps an organization plan budget for eventual replacements and ensures decommissioned assets are properly disposed of rather than left in limbo indefinitely.

A variable stores a named value, such as a hostname, for later reuse throughout a script, avoiding the need to repeat the same literal value multiple times and making the script easier to update if that value ever changes. A loop instead repeats the same command or block of commands once for each item in a list, such as iterating through server names, which is a fundamentally different scripting construct from simply storing a single value. Understanding both constructs, along with conditionals and comparators, is foundational to writing basic server administration scripts that go beyond a single linear sequence of commands.

Overprovisioning allocates more total virtual resources, such as CPU cores, to guest virtual machines than the physical host actually has available, relying on the assumption that not every VM will demand its full allocation at the same time. This can improve overall resource utilization efficiency, but it also carries the risk of resource contention if actual demand from multiple VMs simultaneously exceeds what the host can truly provide. Careful capacity planning and monitoring of actual VM resource usage over time helps administrators tune overprovisioning ratios that improve efficiency without risking a genuine performance problem during peak demand.

Active-active clustering has both nodes actively processing production traffic simultaneously, which both provides redundancy and can increase total usable capacity compared to a standby node sitting idle. Active-passive instead keeps one node on standby, only taking over once the active node fails, which typically means the standby node's capacity is not being productively used during normal operation. Choosing active-active over active-passive often depends on whether the application can actually support simultaneous multi-node processing without data consistency conflicts.

Thresholds define specific levels that, when crossed by a monitored metric such as disk utilization, trigger an alert, providing proactive notification before a resource issue becomes a full outage. Event logs instead retain a history of system events over time, supporting later review and investigation, which is a different monitoring function from real-time threshold-based alerting. Both elements work together as part of comprehensive server monitoring, with thresholds providing immediate proactive alerts and event logs providing the historical record needed for later troubleshooting or auditing.

APIPA automatically assigns an address in the 169.254.x.x range when a DHCP-configured device fails to reach a DHCP server, providing a fallback address that at least allows local network communication with other APIPA-addressed devices, though it does not provide internet or normal network routing. Seeing a 169.254.x.x address is a strong diagnostic signal that DHCP is failing for that device, since this range is specifically reserved for exactly this fallback scenario. Troubleshooting an APIPA address should focus on why DHCP communication is failing, such as a network connectivity issue or an unreachable DHCP server, rather than treating the APIPA address itself as the actual problem.

A slipstreamed or unattended scripted installation automates the installation process, including drivers, additional applications, and patches, allowing the same configuration to be deployed consistently across many servers without manually clicking through the installer on each one. A manual GUI installation instead requires an administrator to interactively complete each installation, which does not scale efficiently across fifty separate servers. Scripted, unattended installations are especially valuable for large-scale deployments, since they ensure configuration consistency across every deployed server while dramatically reducing the manual effort compared to individual manual installs.

Out-of-band management provides remote access to a server's console, power controls, and even BIOS settings through a dedicated management interface that operates independently of the server's own operating system, which is exactly why it remains functional even when the OS itself is completely unresponsive. This differs from in-band management, which relies on the operating system itself being up and reachable over the network, making it useless in exactly the scenario where out-of-band management proves most valuable. Vendor implementations of out-of-band management, such as iLO or iDRAC, are standard tools for remotely administering and recovering servers without requiring physical presence at the rack.

Drives and fans are commonly designed as hot-swappable components in enterprise server chassis, specifically to allow replacement without requiring a full system shutdown and the resulting downtime. Confirming that a specific component is actually rated as hot-swappable before removal is essential, since attempting to remove a non-hot-swappable component while the system is powered on could cause damage or an unexpected system crash. Even with genuinely hot-swappable components, proper handling precautions, such as following the vendor's specific removal and insertion procedure, still matter for a safe, successful replacement.

RAID 5 stripes data with distributed parity across all drives, tolerating a single drive failure while sacrificing only one drive's worth of capacity to parity, which maximizes usable capacity compared to RAID 10's mirroring approach. RAID 10 instead mirrors and stripes data together, offering excellent performance and fault tolerance but at the cost of losing half the total raw capacity to mirroring, which is a less capacity-efficient tradeoff than RAID 5. RAID 0 offers no fault tolerance at all, and JBOD simply concatenates disks without any redundancy, making neither suitable when tolerating a drive failure is a stated requirement.