Refer to the Exhibit Practice Questions

Disable IPv6 on the network adapter.

Why it fails: Disabling IPv6 does not affect IPv4 address assignment, so the APIPA address and lost connectivity remain; the server needs its static configuration restored. Disabling IPv6 is correct when IPv6 causes resolution or routing conflicts on a host that already has valid IPv4 connectivity.

The DHCP server is unreachable; check DHCP server availability.

Why it fails: The exhibit shows a static address already configured, so DHCP reachability is irrelevant; the fault lies elsewhere, such as an incorrect default gateway or subnet mask. Checking DHCP availability would be the right step only when a client is configured to obtain its address automatically and receives an APIPA address.

Release and renew the DHCP lease.

Why it fails: The exhibit shows an APIPA address, meaning the DHCP request failed; releasing and renewing simply repeats that failed request and cannot produce the required static 10.0.0.50. Renewal is correct when a client is meant to obtain its address dynamically from a working DHCP server.

Check for failure of the liquid cooling system for CPU1.

Why it fails: Most servers use air cooling; liquid cooling is uncommon and would require verification, but it's not the first step without other evidence.

Replace CPU1 because the high temperature indicates an internal short.

Why it fails: A CPU that overheats is rarely faulty; almost always it's a cooling issue. Internal shorts would result in immediate failure, not gradual temperature increase.

Install additional high-speed fans to increase static pressure.

Why it fails: Adding fans may help but does not fix the underlying airflow path problem; it also may not be possible in a 1U/2U chassis.

The Nginx service is not running.

Why it fails: If Nginx were down, it would not log this error; the reverse proxy must be operational to generate the entry.

The firewall on the reverse proxy is blocking port 80.

Why it fails: A firewall block would typically result in a timeout, not an immediate connection refusal from the upstream server.

The client's DNS cannot resolve example.com.

Why it fails: The error occurs at the backend connection level, long after client DNS resolution has succeeded.

Tune the database engine's query cache size.

Why it fails: Query cache tuning can help in specific scenarios, but the overwhelming evidence of swapping points to a systemic memory shortage that tuning cannot fully overcome.

Configure the server to use a larger swap partition.

Why it fails: Enlarging swap would encourage more swapping, severely degrading performance; it's a stopgap, not a solution.

Replace the existing hard drives with faster SSDs.

Why it fails: SSDs would reduce I/O latency, but the high swapping indicates insufficient RAM; SSDs alone won't eliminate frequent disk-based reads due to low memory.

The DNS server's root hints are misconfigured.

Why it fails: Root hints are used when the server needs to forward queries for external domains; for its own zone it answers authoritatively.

The DNS server is not configured to forward queries to an external DNS server.

Why it fails: The server is authoritative for contoso.com, so forwarding is not needed for records within its own zone.

The DNS server has an incorrect reverse lookup zone configuration.

Why it fails: Reverse lookup zones map IP addresses to names; this query is for a name to IP, so reverse zone configuration is not involved.

Enable XMP profile in the BIOS to force all DIMMs to 2666 MT/s.

Why it fails: XMP (Extreme Memory Profile) is an overclocking feature typically unavailable or unsuitable for stable server operations with registered memory.

Clear the CMOS to reset the memory training data.

Why it fails: Clearing CMOS might trigger retraining but will not override the hardware limitation imposed by the 2133 MT/s DIMM.

Move the DIMM from A1 to A2 and the DIMM from A2 to A1.

Why it fails: Swapping slots does not eliminate the speed mismatch; the slowest DIMM still dictates the memory bus speed.

Disabling root login via SSH.

Why it fails: Disabling root would stop attacks on root, but the shown compromise occurred on the 'admin' account; this control does not address the successful breach of a non-root user.

Enforcing a strong password policy.

Why it fails: Strong passwords reduce the likelihood of quick guesses, but if the password is eventually discovered through repeated attempts (as shown for 'admin'), the attack still succeeds without a lockout mechanism.

Using a different SSH port.

Why it fails: Changing the default port may reduce automated scans but does not stop a targeted brute-force attack once the port is known (as indicated by port 22 in the log).

The SATA controller driver is corrupted; reinstall the driver

Why it fails: A driver issue is less likely; reinstalling the driver would not fix a hardware problem.

The disk has a bad sector; run CHKDSK and monitor

Why it fails: While bad sectors may cause this, the error indicates a controller issue; the safest action is to replace the drive to prevent data loss.

The disk is experiencing high I/O; upgrade to SSD

Why it fails: Upgrading to an SSD is unnecessary and doesn't address the immediate error; the drive is failing.

Power supply wattage

Why it fails: Power supply wattage affects power delivery, not cooling. An undersized PSU might cause power issues or shutdowns, but it would not directly cause overheating. Overheating is typically related to inadequate cooling, not power capacity. Thus, checking PSU wattage is not relevant to this scenario.

Disk fragmentation

Why it fails: Disk fragmentation affects storage performance, not server temperature. Fragmentation can cause increased disk activity, but this would not lead to overheating unless the cooling system is already compromised. It is not a relevant factor for diagnosing overheating issues in a data center environment.

CPU utilization

Why it fails: High CPU utilization can generate more heat, but if the server is in a properly cooled data center and still overheating, the root cause is likely a cooling system failure, not workload. While CPU load could contribute, it is not the primary check when other servers in the same environment are not overheating.

The filesystem on /dev/sda is corrupted.

Why it fails: Filesystem corruption produces metadata errors such as bad superblock or journal aborts, not the hardware sense-key and I/O error pattern in dmesg. It is the correct diagnosis when mount fails or fsck reports inconsistencies. The exhibit indicates the underlying disk is failing.

The SCSI cable is loose.

Why it fails: A loose SCSI cable typically produces resets, timeouts or device-offline messages rather than the medium and sense-key errors shown. It is the right diagnosis when dmesg reports transport-level faults such as aborted commands. The exhibit points to failing sectors on the disk itself.

The RAID controller firmware is outdated.

Why it fails: Outdated RAID controller firmware usually causes controller resets, cache errors or degraded arrays, not per-sector medium errors on /dev/sda. It is the right answer when the controller logs firmware faults or the array misbehaves. The dmesg output shows the physical disk failing.

RAID controller

Why it fails: RAID controller issues might present as disk array failures or rebuild logs, not specific medium errors on a single drive.

RAM module

Why it fails: Faulty RAM typically causes memory parity errors or kernel panics, not I/O errors with sense key reporting.

Power supply

Why it fails: Power supply failures often generate power-related log entries (e.g., voltage warnings), not disk I/O errors.

The DNS service is not resolving the web server's FQDN.

Why it fails: DNS issues would prevent the client from contacting the server at all, not generate a Kerberos ticket encryption error.

The domain controller clock is out of sync with the web server.

Why it fails: Clock skew generates a different error (KDC_ERR_SKEW) and is not indicated by an encryption type mismatch.

The service account for the web server has an expired password.

Why it fails: Password expiration would cause an authentication failure with event ID 4771, not an encryption type error.

The hard drive data cable is loose

Why it fails: A loose data cable typically produces intermittent I/O errors, detection failures or no POST drive recognition, not the specific boot-time error shown. It is tempting because cabling is a common physical fault, and reseating SATA or power connectors is the correct first step when a drive disappears entirely from BIOS.

The boot sector is corrupted

Why it fails: Boot sector corruption yields a distinct message such as 'Invalid partition table' or 'Operating system not found', not the exhibit's error. It is tempting because boot-sector repair via bootrec or fixmbr is the right remedy when the MBR or partition boot record is damaged and the drive itself is healthy.

The hard drive has failed

Why it fails: Total drive failure usually presents as no detection, clicking, or SMART failure, and the exhibit's error would not be the primary symptom. It is tempting because a dead drive is a common cause of boot failure, and replacement is correct when diagnostics confirm the disk is physically unusable.

Add more network bandwidth to speed up VM provisioning.

Why it fails: Bandwidth accelerates data transfer during provisioning, but the RTO is dominated by sequential phases such as restore and validation, not throughput. It is tempting because network speed is a visible bottleneck, yet it is the correct choice only when transfer time, rather than fixed restore or validation steps, is the largest contributor.

Use a warm site with pre-configured storage.

Why it fails: A warm site with pre-configured storage still requires servers to be started and data restored before the application runs, so the recovery phase is not eliminated. It is tempting because pre-staged storage shortens restore time, but that suits a shorter RTO only when compute is already running and merely needs powering on.

Automate application validation to reduce that phase by half.

Why it fails: Halving application validation shortens only that phase; the remaining restore and provisioning phases still exceed the two-hour target, so the RTO is not met. It is tempting because validation is often lengthy, but automating it is the right choice only when validation itself is the dominant contributor to the timeline.

The server's default gateway is incorrect

Why it fails: A wrong default gateway would break off-subnet routing, yet local clients reaching the server on the same subnet would still connect; the iptables output shows a rule dropping inbound port 80, which blocks traffic regardless of gateway configuration. Gateways matter when hosts must reach networks beyond their own broadcast domain.

SELinux is enforcing and blocking port 80

Why it fails: SELinux denials would surface in audit logs and typically block the service from binding, yet the server is confirmed listening; the iptables output shows the INPUT chain dropping or rejecting inbound port 80. SELinux is tempting because it commonly blocks non-standard ports, and it would be correct if httpd were bound to a port absent from its policy.

The web server is not bound to the correct IP address

Why it fails: Binding to the wrong IP would leave port 80 unlistened on the expected address, but the stem confirms the service is running and the exhibit shows an iptables rule rejecting inbound HTTP. Binding is the culprit when netstat shows the listener on 127.0.0.1 instead of the interface address.