Select Two (Multi-Select) Questions

Run an antivirus scan.

Why it fails: Antivirus scans quarantine or delete files, altering the disk state and potentially destroying forensic evidence needed to understand the attack.

Reboot the server in safe mode.

Why it fails: Rebooting, even in safe mode, clears memory and may activate malware that has installed boot-time persistence, hindering investigation.

Power off the server immediately.

Why it fails: Shutting down the system results in the loss of all volatile data (memory, network state), which is often crucial for forensic analysis.

Assign a static IP address to the server.

Why it fails: A static IP address is important for server management and accessibility, but it does not directly optimize network performance. It ensures consistent addressing, but performance improvements come from other configurations like teaming and jumbo frames. Static IP is a best practice for servers but not a performance optimization.

Disable TCP offloading on the network adapter.

Why it fails: Disabling TCP offloading can increase CPU usage because the processor must handle TCP segmentation and checksum calculations. This typically degrades performance rather than improving it. TCP offloading is designed to offload these tasks to the NIC, freeing CPU resources for application processing. It should generally remain enabled.

Set the network adapter to half-duplex mode.

Why it fails: Half-duplex mode allows communication in only one direction at a time, leading to collisions and reduced throughput. Modern networks use full-duplex, which enables simultaneous send and receive. Setting half-duplex would severely degrade performance and is not appropriate for a high-traffic server.

Detailed instructions for cleaning server hardware.

Why it fails: While physical maintenance is important, it is not a part of disaster recovery planning and does not aid in restoring IT services after a disruption.

Step-by-step procedures for performing backups.

Why it fails: Backup schedules and methods are part of the backup policy; the DR plan focuses on recovery procedures that use the backups to restore services.

Set each new drive's SAS address to match the controller's expected value

Why it fails: SAS addresses are factory-assigned World Wide Names burned into the drive and are not user-configurable. The controller discovers drives by their native SAS address, so there is no field to change, and attempting to alter it is neither possible nor part of the installation procedure.

Install the drives while the server is powered off to avoid damaging the backplane

Why it fails: Hot-swap bays are specifically engineered to allow drive insertion and removal while the system runs, and the backplane isolates power and signal pins during insertion. Powering off the server is unnecessary for hot-swap drives and would needlessly interrupt the services the server is providing.

Update the RAID controller firmware to the latest release immediately before insertion

Why it fails: Firmware updates can change array behavior and sometimes require a reboot, so performing one immediately before adding drives introduces risk during a maintenance window. Compatibility should be verified, but a firmware upgrade is not a required preparatory step and could itself disrupt the running server.

Update the BIOS and all device drivers to the latest versions.

Why it fails: Updating BIOS and drivers can resolve compatibility issues that cause reboots, but it is a preventive measure, not a diagnostic action. It does not gather evidence of the cause. In fact, applying updates before identifying the root cause can obscure the issue or introduce new problems. This should be done after diagnosing the problem.

Enable and review the Windows Memory Diagnostic results.

Why it fails: Windows Memory Diagnostic can detect RAM errors, but it requires a reboot to run and results are only available after the test completes. For random reboots, it is less immediate than checking event logs. While memory issues can cause reboots, this action is not the first step and may not capture the cause if the reboot is not memory-related.

Run the sfc /scannow command to check for system file corruption.

Why it fails: sfc /scannow scans and repairs corrupted Windows system files. While file corruption can cause instability, it is unlikely to cause random reboots without other symptoms. This action is more suited for application errors or boot issues, not for diagnosing hardware-related reboots. It does not provide evidence of hardware failure.

Update the NIC driver to the latest version from the vendor's website.

Why it fails: Driver updates address software or firmware issues, but a dark link LED indicates a physical layer problem. Driver issues typically do not cause the link LED to go out intermittently. Updating the driver would not resolve a cabling or switch port fault, so this is not a priority.

Reconfigure the switch port to use a fixed speed and duplex instead of auto-negotiation.

Why it fails: Hard-setting speed and duplex can sometimes resolve negotiation issues, but it is a workaround rather than a diagnostic step. The intermittent link loss and dark LED point to a physical connection problem that should be identified first. Forcing settings without understanding the root cause may mask the issue or create new problems.

Replace the server's network interface card with a known-good spare.

Why it fails: While a failing NIC could cause intermittent connectivity, the link LED on the switch going dark suggests a physical layer issue between the server and switch, not necessarily the NIC itself. Replacing the NIC is more invasive and should be done after cabling and switch port checks. The patch cable has already been replaced, so the NIC is less likely.

Set up a VPN connection for administrators to access the server management network.

Why it fails: A VPN provides secure remote network access but does not itself deliver out-of-band console access, virtual media, or power control. It is a complementary security measure for reaching management interfaces, but without a BMC or lights-out card, the VPN alone cannot meet the stated out-of-band management requirements.

Enable Remote Desktop Protocol (RDP) on all servers and restrict access via firewall rules.

Why it fails: RDP relies on the operating system being functional and the network stack being operational. It cannot provide console access when the OS is unresponsive or powered off, nor can it mount virtual media for OS installation. RDP is an in-band management tool, so it does not meet the out-of-band requirement.

Deploy a terminal server and use it as a jump host for administrative connections.

Why it fails: A terminal server or jump host centralizes administrative access but still depends on the target servers' operating systems and network connectivity. It does not offer out-of-band console access, virtual media mounting, or remote power cycling when the OS is down, so it fails to meet the core requirements.

Biweekly incremental backups to tape stored only in the primary datacenter.

Why it fails: Storing backups only in the primary datacenter means a site-wide disaster would destroy both production data and the backups, making recovery impossible. Biweekly incremental backups also provide a very coarse recovery point and slow restore times, which cannot support a four-hour RTO. This approach fails both the geographic separation principle and the recovery objectives required by the scenario.

A full-scale failover test that shuts down the primary datacenter during business hours without notifying users.

Why it fails: A full-scale failover during business hours without notification would cause an actual outage and disrupt users, which is unacceptable for most organizations. While testing is required, it should be planned and controlled. An unannounced production shutdown is not a valid disaster recovery test; it creates a real incident rather than validating procedures safely, and it does not contribute to a reliable warm site takeover within four hours.

A cold site with no pre-installed hardware or data replication, relying on emergency procurement during a disaster.

Why it fails: A cold site provides only space and power, with no pre-installed equipment or replicated data. Bringing a cold site online typically takes days or weeks because hardware must be procured, installed, and configured, and data must be restored from backups. This cannot meet a four-hour takeover requirement, so a cold site is incompatible with the scenario's warm site and recovery time constraints.

Delete the array and recreate it from scratch to ensure a clean rebuild.

Why it fails: Recreating the array destroys all data on the volume and forces a restore from backup, which is far riskier and slower than a member replacement. RAID controllers rebuild a replacement drive automatically from parity, so destroying the array is unnecessary and introduces avoidable data-loss exposure.

Force the failing drive offline immediately so the controller begins rebuilding onto a spare.

Why it fails: Forcing a predictive-failure drive offline before a replacement is staged leaves the array degraded with no redundancy. If another member fails during that window, the array is lost. The correct sequence is to have a replacement ready, confirm backups, then let the controller rebuild onto the new member.

Power down the server and remove the drive while the system is offline to avoid hot-swap risk.

Why it fails: Taking the server offline is unnecessary when the chassis and controller support hot-swap, and it increases downtime for a predictive failure that has not yet occurred. The safer approach is to replace the drive online after confirming backups and correctly identifying the bay, unless the hardware explicitly lacks hot-swap support.

Install a host-based intrusion detection system that alerts on suspicious SSH login patterns.

Why it fails: A host-based intrusion detection system provides valuable visibility and alerting, but it detects attacks rather than preventing them. It does not itself remove weak authentication methods or reduce the number of exposed entry points, so it complements hardening rather than accomplishing the stated goal of shrinking the attack surface.

Enable verbose logging of all SSH connection attempts to a remote syslog server.

Why it fails: Centralized logging supports auditing and incident response, but logging alone does not block or restrict access. Attack attempts still reach the authentication layer, so this measure improves detection and forensics without changing the underlying exposure or strengthening the authentication mechanism the team wants to enforce.

Change the SSH service to listen on a non-standard port to hide it from scanners.

Why it fails: Moving SSH to a different port is security through obscurity and does not stop a determined attacker who scans all ports. It also complicates legitimate administration and firewall documentation. The service remains reachable and the underlying authentication weaknesses are unchanged, so this does not meaningfully reduce the attack surface.

Change the SSH port from 22 to a non-standard port, such as 2222.

Why it fails: Changing the SSH port is a form of security through obscurity. It may reduce automated scanning noise but does not provide real security benefits, as attackers can easily scan for open ports. It can also complicate firewall rules and legitimate access. While sometimes used, it is not considered a best practice for reducing attack surface compared to disabling root login and using key-based authentication. Therefore, it is not one of the two best actions.

Enable password authentication to ensure only authorized users can log in.

Why it fails: Enabling password authentication is the opposite of hardening; passwords can be brute-forced or guessed. Best practice is to disable password authentication and use SSH key-based authentication, which is more secure. The scenario implies the server is public, so password authentication increases risk. This action would not reduce attack surface and is therefore incorrect.

Allow SSH access from any IP address to ensure administrators can connect from anywhere.

Why it fails: Allowing SSH from any IP address increases the attack surface by exposing the service to the entire internet. Best practice is to restrict SSH access to specific management subnets or IP addresses using firewall rules or TCP wrappers. This limits the number of potential attackers. The scenario's goal is to reduce attack surface, so this action is counterproductive and incorrect.

Schedule full backups to run only during business hours.

Why it fails: Running backups during business hours can impact performance and does not address power failure directly. Backups are important for recovery, but the scenario focuses on measures during a power failure. This action does not ensure data integrity or availability at the moment of outage. It is not a direct mitigation for power loss.

Enable write caching on all storage controllers without battery backup.

Why it fails: Write caching without battery backup risks data loss if power fails before cached data is written to disk. This compromises data integrity. The scenario requires measures to ensure data integrity, so enabling such caching is counterproductive. Battery-backed write cache would be acceptable, but without it, this is a poor choice.

Configure RAID 0 on all database servers to improve performance.

Why it fails: RAID 0 offers no redundancy; a single disk failure results in data loss. During a power failure, RAID 0 does not protect data integrity and can increase risk. The scenario requires ensuring data integrity and availability, which RAID 0 fails to provide. It is unsuitable for critical servers.

Store database credentials in a world-readable configuration file so all administrators can access them during outages.

Why it fails: World-readable credential files expose secrets to every local user and to any process that can read the filesystem, including a compromised web service. This directly worsens the impact of a breach because the attacker obtains database credentials along with the web process. Secrets should be stored with restrictive permissions or in a dedicated secrets manager and retrieved only by authorized components.

Grant the web service account sudo rights with no password so administrators can troubleshoot quickly during incidents.

Why it fails: Passwordless sudo for a service account means that anyone who compromises the web process inherits full administrative control of the host. This expands, rather than limits, the impact of a compromised account. The principle of least privilege calls for the service account to have only the permissions it needs to read content and bind its port, with no ability to escalate privileges.

Disable SELinux or AppArmor on the servers so that application updates do not fail during deployment.

Why it fails: Mandatory access control frameworks such as SELinux and AppArmor confine processes even when they run as root, so disabling them removes a key containment layer. Application update failures are usually solved with correct policy modules or targeted exceptions, not by turning off the control entirely. This action increases the impact of a compromise and works against the stated hardening objective.

The server's memory is running in single-channel mode instead of dual-channel mode

Why it fails: Memory channel configuration affects bandwidth and CPU access latency, not the storage subsystem's disk wait time. Because the observed symptom is high %iowait with low CPU utilization and multi-second disk latency on a healthy array, a memory topology issue would not produce this pattern. It is a plausible-sounding hardware change but unrelated to the reported bottleneck.

The network interface has negotiated a lower speed, causing the file server's clients to time out

Why it fails: A degraded network link affects client throughput and can cause timeouts, but it would not raise the server's local %iowait or produce multi-second latency on the local data volume as measured by iostat. The measured metrics point to the storage stack, not the NIC. This distractor confuses a client-side connectivity symptom with a server-side disk bottleneck.

The array is rebuilding after a member disk replacement, consuming all available controller bandwidth

Why it fails: The scenario explicitly states that no rebuild or patrol read is active, so this cannot be the cause. A rebuild would also show elevated controller activity and a degraded or rebuilding status in management tools. Selecting this ignores a stated fact and misattributes the latency to an operation that is not occurring.

Configure the share to use SMB 3.1.1 with encryption.

Why it fails: SMB encryption secures data in transit but does not affect permission enforcement. While it is a good security practice, it does not ensure that permissions are consistently applied across platforms. The requirement is about permission consistency, not data confidentiality.

Install Services for Macintosh (SFM) on the server.

Why it fails: Services for Macintosh is a legacy feature that provided AFP file sharing for older Mac clients. It is deprecated and not available in Windows Server 2022. Modern macOS clients use SMB, so SFM is neither necessary nor supported. This option would not help and could introduce compatibility issues.

Enable Access-Based Enumeration (ABE) on the share.

Why it fails: ABE hides files and folders that users do not have permissions to access, improving the user experience by reducing clutter. However, it does not enforce permissions across platforms; it only affects visibility. While useful, it does not address the core requirement of consistent permission enforcement for both Windows and macOS clients.

Disable error correction in the BIOS to prevent further errors.

Why it fails: Disabling error correction would mask the symptoms but not fix the underlying issue. It could lead to uncorrectable errors and data corruption. Error correction is a critical feature for server reliability. The administrator should instead diagnose and replace faulty components or update firmware to resolve the errors.

Reinstall the operating system to eliminate software-related memory errors.

Why it fails: Reinstalling the OS is unlikely to resolve hardware-level memory errors. Corrected memory errors and MCEs are typically hardware or firmware related. Reinstalling the OS is time-consuming and disruptive, and it would not fix faulty RAM or outdated firmware. The administrator should first address the hardware and firmware.

Replace the power supply unit with a higher-wattage model.

Why it fails: While power issues can cause reboots, the presence of corrected memory errors and MCEs strongly indicates a memory subsystem problem, not a power supply issue. A higher-wattage PSU would not address memory errors and could introduce unnecessary changes. The administrator should focus on diagnosing the memory first.

CPU

Why it fails: CPU issues typically cause system-wide problems like crashes or performance degradation, not isolated network connectivity loss. While a CPU overheating could lead to throttling, it would not specifically cause intermittent network drops. Checking the CPU is not a targeted first step for network connectivity issues.

Hard drive

Why it fails: Hard drive failures can cause system instability, but they are unlikely to cause only intermittent network connectivity. Network issues are more directly related to network hardware and cabling. Checking the hard drive would be relevant for storage-related problems, not network connectivity. Thus, it is not a primary check here.

Power supply unit (PSU)

Why it fails: While a failing PSU can cause random reboots or shutdowns, it is less likely to cause only network connectivity loss. Intermittent network issues are more often related to network components. The PSU would typically affect the entire system, not just network. Therefore, it is not a primary check for this symptom.

Move all existing DIMMs to the slots belonging to the second processor to balance the load.

Why it fails: Moving all memory to the second socket's slots would leave the first processor without local memory, forcing remote memory access and hurting performance. The correct approach is to populate both sockets' slots according to the vendor's population rules rather than concentrating memory under one CPU.

Reinstall the operating system so it can detect the additional processor sockets.

Why it fails: Modern operating systems detect additional logical processors at boot and load the appropriate scheduler and kernel support automatically. Reinstalling the OS is unnecessary and risks data loss, so it is not a required step for a CPU upgrade on supported hardware.

Disable hyper-threading in firmware so the second processor's cores are recognized.

Why it fails: Hyper-threading is a per-core feature and does not control whether a second physical processor is detected. Disabling it would reduce logical processor count and could hurt the virtualization workload, so it is unrelated to making the new socket functional.

systemctl status httpd

Why it fails: Checking the web service status may reveal whether the service is running, but it will not show I/O statistics or which processes are blocked on disk. The scenario already points to a system-wide I/O bottleneck, so service-level status is too narrow and does not identify the contributing devices or processes.

free -m

Why it fails: The free command reports memory and swap usage, which can hint at memory pressure but does not identify disk-level or per-process I/O contributors. While swap activity may relate to I/O, free alone cannot show which devices or processes are saturating the storage subsystem, so it does not address the bottleneck.

netstat -tulpn

Why it fails: netstat lists network connections and listening ports. It is useful for network troubleshooting but provides no information about block device utilization or per-process disk I/O. It would not help identify the processes in D state or the storage device causing the bottleneck.

RAID 6 arrays on every production server to protect against multiple simultaneous drive failures.

Why it fails: RAID protects against disk failure inside a single server and does nothing for a total site loss, which is the scenario being addressed. It also would require new hardware on every server, consuming budget without improving disaster recovery capability. Local redundancy is a availability control, not a disaster recovery control.

A second UPS with extended battery modules installed in the same server room as the primary UPS.

Why it fails: Additional battery capacity in the same room extends runtime during a short outage but provides no protection when the entire facility is destroyed or inaccessible. Two UPS units in one location share the same single point of failure, so this investment does not advance the goal of recovering after a total site loss.

A cloud-based warm standby environment running replicated virtual machines for all 40 servers with automatic failover.

Why it fails: A warm standby with replication for every server would meet the availability goal but far exceeds a limited budget and is more capability than the stated requirement of restoring critical workloads. It also duplicates the entire estate rather than prioritizing the workloads that actually need protection, making it a poor fit for the approved project scope.