CompTIA Server+ Practice Test (SK0-005)

The -E (or --preserve-env) flag tells sudo's security policy to keep the current environment variables, overriding the default env_reset behavior. This allows LD_PRELOAD and any other user-defined variables to be passed to the root process.

-i launches the target user's login shell and initializes a fresh environment, so LD_PRELOAD would be removed.
-H only resets the HOME variable to the target user's home directory and does nothing to preserve other variables.
-k (or --reset-timestamp) merely clears cached sudo credentials; it has no effect on which environment variables are passed to the command.

The server NIC is still configured for auto-negotiation. When one side of an Ethernet link is manually set to a fixed speed and duplex (100 Mb/s full) and the other side remains on auto-negotiation, the auto-negotiating device cannot determine the duplex mode. Per IEEE 802.3, it therefore defaults to half-duplex, creating a duplex mismatch. The half-duplex side detects many collisions, the full-duplex side records FCS/CRC errors, and bulk traffic slows dramatically even though basic connectivity (ping) still works.

Why the other choices are wrong:

• A faulty patch cable can cause CRC errors, but it does not normally generate high collision counts, the hallmark of a duplex mismatch.
• Incorrect IP settings would prevent or limit connectivity rather than merely slow large transfers while leaving Layer-2 error counters climbing.
• A switch-port hardware failure is more likely to drop the link entirely or flap the interface than to show consistent collision/CRC patterns.

The array currently holds 9.6 TB of data (12 TB × 0.80). Over 18 months that amount will grow by (1.04)^18 ≈ 2.03, reaching roughly 19.5 TB. A RAID 6 array provides usable capacity equal to (N − 2) × 2 TB, so each extra 2 TB drive adds exactly 2 TB of usable space. To raise usable capacity from 12 TB to at least 19.5 TB requires ⌈(19.5 − 12) / 2⌉ = 4 additional drives, bringing the array to 12 disks and 20 TB of usable space. Adding two or three drives would leave less than 19.5 TB, and a wholesale replacement with larger disks costs more than the minimum solution.

The open rack units located between the two groups of equipment allow hot exhaust air to curl back into the cold aisle and be drawn into the intakes of the upper servers. Installing blanking (filler) panels across those unused U-spaces seals the openings so cold supply air is forced through the equipment instead of bypassing it, eliminating recirculation and lowering inlet temperatures. Rotating servers so their rear panels face the cold aisle disrupts the hot-aisle/cold-aisle scheme and is specifically discouraged by industry guidelines. Swapping a perforated rear door for a solid door would trap heat rather than remove it, while increasing CRAC fan speed addresses room-level airflow-not the localized bypass caused by empty rack spaces-and wastes energy without fixing the root cause.

The correct answer is to configure the default gateway address. A default gateway is a device, typically a router, that serves as an access point to other networks. When a server needs to send traffic to an IP address outside of its own local subnet, it sends that traffic to its configured default gateway. In this scenario, the server can communicate with devices on its local 10.100.100.0/24 subnet but cannot reach the internet, which is on an external network. This indicates that the server does not have a route to external networks, a problem solved by setting the default gateway address.

• Assigning a different DNS server would not solve the problem. While DNS is required to resolve domain names to IP addresses, the fundamental issue here is network reachability, not name resolution. The server cannot reach any external IP address, which is a routing problem.
• The IP address 10.100.100.50 is a valid private IP address as defined by RFC 1918 and is not an APIPA address. APIPA addresses are in the 169.254.0.0/16 range and are self-assigned when a device cannot contact a DHCP server.
• The subnet mask 255.255.255.0 is a correct and standard mask for a /24 network, which is appropriate for the IP address assigned. It correctly defines the local network boundary.

The goal is to detect open TCP ports and perform service-version identification without launching intrusive NSE scripts. The syntax that accomplishes this is the one that enables Nmap's built-in version-detection engine (-sV) and speeds up the scan with the Aggressive timing template (-T4). No option that launches default scripts (-sC) or vulnerability probes is desired, and there is no requirement for OS fingerprinting, UDP probing, or scanning every port.

• nmap -sV -T4 203.0.113.25: Performs a TCP port scan, interrogates each open port to learn the protocol and banner, and finishes quickly because of the timing template. This satisfies all stated requirements.

• nmap -O -sS 203.0.113.25: Adds OS detection and a SYN scan but does not identify application protocols, so it misses the key requirement.

• nmap -sU -sC 203.0.113.25: Switches to UDP scanning and launches the default NSE script set, some of which are considered intrusive; it also omits the TCP ports you need to check.

• nmap -Pn -p- 203.0.113.25: Scans every port but neither detects services nor accelerates the scan, making it slower than necessary and less informative.

Therefore, nmap -sV -T4 203.0.113.25 is the command that best meets the stated requirements.

The net use command lists all active SMB drive or UNC mappings and, with the /delete switch, removes a specified mapping. Running

net use \\FS01\Profiles /delete

clears the stale connection and its credentials so the share can be re-mapped. Diskpart is a utility for local disk partitions only, mountvol edits NTFS mount points, and netstat lists network sockets; none of these can enumerate or remove SMB drive mappings.

The server must use an address that

• Falls inside the same /64 prefix as the subnet (2001:db8:22:10::/64) and
• Does not duplicate the router's gateway address and
• Is not a special-purpose (e.g., link-local) prefix.

2001:db8:22:10::25/64 satisfies these conditions: it retains the full 64-bit network prefix and chooses a unique host identifier (::25).

Why the other choices are wrong:

• 2001:db8:22:10::1/64 duplicates the gateway address, which would break connectivity.
• fe8025/64 is a link-local address (FE80/10) that is not routed beyond the local link and is never used for static global assignments.
• 2001:db8:22::25/64 is outside the required subnet; missing the "10" hextet places it in a different /64 and the host would not reach the intended gateway.

The correct answer is failing ECC memory. Error-Correcting Code (ECC) memory is designed to detect and correct single-bit errors in RAM. The logs showing a high number of corrected errors indicate that a memory module was degrading. The cessation of these logged corrections suggests the module has failed to a point where errors are now multi-bit and uncorrectable, or the ECC function itself has failed. This allows corrupted data to be passed from memory to the CPU and then written to the database, resulting in the type of subtle data corruption described. Silent data corruption on the storage array (bit rot) is less likely because the evidence specifically points to a memory issue. A zero-day exploit is unlikely to cause such random, subtle errors and is not supported by the log evidence. Filesystem journaling errors relate to inconsistencies after a crash, not the type of in-memory data corruption indicated by the ECC error logs.

In Bash an until loop executes its body repeatedly while the test command returns a non-zero (false) exit status, and it stops as soon as that command succeeds (exit status 0). Because nc -z localhost 443 fails until the port is open, wrapping the command in an until loop makes the script wait and then continue automatically when the service is ready.

A while loop has the opposite logic (it repeats only while the test command succeeds), so it would loop after the port is already open and exit immediately when the port is closed. A for loop requires a predefined list or counter and would need extra logic to stop at the right time, while a case statement is used for single evaluations rather than continuous polling. Therefore, the until loop is the most appropriate construct.

Secure Digital cards use low-cost flash that is rated for far fewer program/erase cycles than enterprise-class SSDs. When a hypervisor writes log, scratch, or OS-update data to the boot device, the repeated writes can quickly exhaust the card's limited endurance, leading to corruption or failure-even when two cards are mirrored. Throughput, power draw, hot-swap support, and RAID levels are secondary considerations; the write-cycle lifespan is the factor that most often disqualifies SD cards for anything beyond light, mostly read-only boot duties.

The correct action is to first deploy the patches to a staging environment that mirrors the production server. This approach allows the administrator to test the patches for any conflicts with the proprietary application without affecting the live production system. It is the best way to balance the need for security updates with the risk of causing application instability on a critical system.

Applying patches directly to the production server is too risky without testing, as it could cause an outage of a critical application. Withholding the patches indefinitely leaves the server vulnerable to security threats, which is also an unacceptable risk. Contacting the vendor is a reasonable step, but testing in a staging environment provides actionable data and is a more proactive and immediate step the administrator can take to assess the actual risk.

The correct answer is to configure a log rotation utility. Log rotation is the standard and most effective method for managing log files that grow over time. This process automatically renames, compresses, moves, and eventually deletes old log files based on a defined schedule or size threshold. This prevents any single file from consuming all available disk space while preserving recent logs for analysis and compliance. Increasing the disk size is only a temporary fix and does not address the root cause of the uncontrolled log growth. Writing a script to simply delete the file would result in the loss of potentially critical troubleshooting data. Disabling logging entirely by redirecting output to /dev/null would solve the space issue but is a severe anti-pattern that would make future troubleshooting and security auditing impossible.

The correct answer is to configure a GRUB password. GRUB is the bootloader for most Linux distributions. Setting a GRUB password prevents unauthorized users from modifying boot parameters or accessing single-user/recovery modes, which could be used to gain root access.

• Full disk encryption (FDE) is incorrect because, while it protects data at rest if the drive is stolen, it does not prevent an attacker with console access from interrupting the boot process and attempting to access the bootloader menu itself. The bootloader password protects access to these boot-time options.
• A host-based intrusion detection system (HIDS) is incorrect as it operates within the loaded operating system to monitor for threats and is not active during the pre-boot or bootloader stages.
• A chassis intrusion alert is a physical security measure that detects when the server case has been opened. It does not prevent an attacker who already has console access from interacting with the boot process.

The IDS is correctly detecting multiple rapid SSH connections but is misidentifying the parallel SCP sessions from the trusted backup servers as hostile and is executing firewall-drop to block their IP addresses for 15 minutes. Placing the backup servers' IP addresses in the IDS <white_list> (or <allow_list>) tells OSSEC/Wazuh never to apply an active response against those addresses. Alerts may still be generated, preserving visibility, but the backups will no longer be blocked.

• Reducing the timeout (900 → 60 s) would still interrupt the transfer and would only mask the symptom.
• Disabling the rules outright would remove protection against real SSH brute-force attacks from untrusted hosts.
• Increasing the SSH MaxSessions parameter affects the SSH daemon, not the IDS, and would not stop the IDS from dropping packets.

Therefore, adding the backup servers to the IDS white/allow list is the most effective and least disruptive fix.