Refer to the Exhibit Practice Questions

The User=backup directive overrides Restart.

Why it fails: User= sets the account the service runs as; it has no bearing on restart behaviour, so it cannot force Restart=no. It is tempting because a drop-in override can alter unit settings, but only directives of the same name override, and User= is not one of them.

The unit is not enabled.

Why it fails: Enabling controls whether the unit starts at boot, not the Restart policy reported by systemctl show. It is tempting because a disabled unit is a common cause of services not running, but here the unit is active; the override comes from a drop-in file that redefines Restart.

The Restart directive is only valid for Type=simple.

Why it fails: Restart= is valid for Type=simple, forking, notify and others; it is not restricted to Type=simple. It is tempting because Type=simple is the default and most commonly paired with Restart, but the actual cause is a later drop-in file overriding the directive.

SSH is not allowed from any source

Why it fails: SSH is allowed from the local subnet.

The INPUT chain policy is ACCEPT, so SSH should be allowed

Why it fails: The explicit DROP rule overrides the default policy.

The DROP rule for SSH is not matching because of packet count zero

Why it fails: The packet count is zero because no packets have matched yet; it will match if traffic arrives.

kill -2 1234

Why it fails: Signal 2 is SIGINT, the interactive interrupt, which the stuck process ignores just as it ignores SIGTERM; only SIGKILL (9) cannot be caught or blocked. It is tempting because SIGINT terminates most foreground processes, and it is the correct choice when you want a graceful interrupt rather than an unconditional kill.

kill -15 1234

Why it fails: SIGTERM (15) is the graceful termination request the process is already ignoring, so resending it changes nothing. SIGKILL (9) cannot be caught or blocked and forcibly ends the process; SIGTERM would be correct for a process that shuts down cleanly on request.

kill -19 1234

Why it fails: Signal 19 is SIGSTOP, which suspends the process rather than terminating it, leaving PID 1234 alive and still holding resources. It is tempting because it forcibly halts execution; it would be correct when pausing a runaway job for inspection before resuming it with SIGCONT.

The root process (PID 1234)

Why it fails: PID 5678 is the target of the signal, so that specific process is affected, not PID 1234. Sending a signal to the parent process would require naming PID 1234 directly. The root process is tempting because it owns the child, but kill acts on the PID supplied, not on process hierarchy.

All www-data processes

Why it fails: kill 5678 signals only the single process whose PID is 5678, not every www-data process. It is tempting because the target may run as www-data, but PID targeting is per-process; killing the whole group would require a negative PID or pkill.

No process, because root cannot kill www-data processes

Why it fails: Root can signal any process regardless of owner, so the kill succeeds against PID 5678. It is tempting because non-root users cannot signal other users' processes, but root bypasses that ownership restriction entirely; only the single process 5678 is affected.

systemctl status myapp.service

Why it fails: Status shows current unit state, the main process exit code and only the tail of recent journal entries, not the full error output produced before exit. It is tempting because it is the quickest service check, and it would suit a first glance at whether the unit is active or failed.

systemctl reload myapp.service

Why it fails: Reload re-reads configuration for a running unit; on a failed service it cannot surface the earlier exit output and may itself fail. It is tempting because reload avoids downtime, and it would be correct for applying configuration changes to an already active daemon.

systemctl restart myapp.service

Why it fails: Restarting the unit re-runs the service and may clear the failed state, but it generates new output rather than retrieving the previous run's error text. It is tempting because restarting is a common first response to a fault, and it would suit recovering a service after the cause is known.

The file /home/dba/file.txt is corrupt.

Why it fails: A corrupt file in the user's home directory cannot prevent SSH authentication, since login depends on credentials, shell and PAM configuration, not on file contents. It is tempting because permission or ownership faults in home directories do block logins, but corruption of a data file is unrelated to the authentication failure.

The user 'dba' is not in the 'docker' group.

Why it fails: SSH login does not consult docker group membership; that group only grants access to the Docker daemon socket. It is tempting because docker group membership is a common privilege-escalation and access-control concern, and would be the answer if the failure involved running docker commands rather than authenticating over SSH.

The home directory /home/dba does not have correct permissions.

Why it fails: Home directory permissions affect post-authentication session setup, not the SSH authentication exchange itself; sshd would still accept valid credentials. It is tempting because restrictive or wrong ownership on /home/dba commonly causes login failures, and would be correct if the exhibit showed authentication succeeding but the session aborting.

truncate -s 0 /var/log/syslog

Why it fails: Truncating syslog empties one file to zero bytes but deletes no old log files, so rotated archives and other logs remain and little space is reclaimed. It is tempting because it clears a large active log safely while the daemon keeps writing, which suits shrinking a single runaway file rather than removing old logs.

rm -rf /var/log/*

Why it fails: rm -rf /var/log/* deletes active logs and directories that running services hold open, breaking logging and risking removal of needed subdirectories. It is tempting because it removes everything under /var/log in one pass, and it would suit clearing a directory of disposable files that no process is currently writing.

du -sh /var/log

Why it fails: du -sh /var/log only reports the total size of the log directory; it deletes nothing and frees no space. It is tempting because it is the standard tool for finding what consumes disk, and it would be the right first step when identifying which directories to clean before deleting anything.

passwd -S newuser

Why it fails: passwd -S reports password status for an existing account and errors if the user is absent, so it cannot confirm existence. It is tempting because it queries account state, and would be correct when checking whether a known user's password is locked, set or expired.

usermod -c newuser

Why it fails: usermod -c sets the GECOS comment field on an existing account; it neither queries nor reports whether 'newuser' exists, and fails outright if the account is absent. It is tempting because usermod does operate on accounts, but it is the tool for modifying an existing user's attributes, not for existence checks.

userdel -v newuser

Why it fails: userdel -v removes an account, printing verbose output about the deletion; it does not test for existence and would delete 'newuser' if present. It is tempting because -v produces visible output, but userdel is the account-removal tool, used when decommissioning a user, not for verification.

The connection attempt failed because only three packets are shown.

Why it fails: A three-packet capture is the complete SYN, SYN-ACK, ACK exchange, so the handshake succeeded; packet count alone proves nothing about failure. It is tempting because a truncated capture can indicate a dropped connection, but here the sequence itself shows establishment, and the conclusion must follow the flags and sequence numbers shown.

The connection was reset by the remote host.

Why it fails: A reset would appear as a packet with the RST flag set, which the exhibit does not show; the captured flags indicate normal handshake progression instead. It is tempting because RST terminates connections abruptly, but no RST is present, so the conclusion contradicts the actual flags displayed.

The handshake is incomplete because there is no ACK from the server.

Why it fails: The server's SYN-ACK is itself the acknowledgement of the client's SYN, so a separate server ACK is not expected; the client's final ACK completes the handshake. It is tempting because the three-way handshake is often misremembered as four packets, but the SYN-ACK combines the server's SYN and ACK.

SSH service is not running.

Why it fails: If sshd were stopped, the port would be closed and connection attempts refused immediately, which contradicts the exhibit's symptom. It tempts because a stopped service is the classic cause of unreachable SSH, and checking systemctl status sshd is the correct step when no process is listening.

The root account is disabled.

Why it fails: A disabled root account is a deliberate hardening measure, not a security issue, so the exhibit cannot show it as the fault. It tempts candidates who equate any root restriction with misconfiguration, but disabling direct root login is exactly what you would configure on a hardened host.

The firewall is blocking SSH.

Why it fails: Firewall rules blocking SSH would produce connection timeouts or refusals, yet the exhibit's evidence points elsewhere. It tempts because firewalls are a common cause of unreachable services, and blocking inbound port 22 is the right diagnosis when packets are dropped before reaching sshd.

mdadm --create /dev/md0 --level=5 --raid-devices=2 /dev/sdb1 /dev/sdc1

Why it fails: --level=5 configures RAID 5, which stripes data with distributed parity and requires at least three devices, so two disks cannot satisfy it. It is tempting because RAID 5 offers redundancy and capacity efficiency, making it a common default for arrays, but the scenario explicitly requires RAID 1 mirroring across exactly two partitions.

mdadm --create /dev/md0 --level=10 --raid-devices=2 /dev/sdb1 /dev/sdc1

Why it fails: --level=10 builds a nested RAID 1+0, which needs a minimum of four devices to form mirrored stripes. It is tempting because RAID 10 also provides mirroring plus performance, but with only two partitions mdadm cannot assemble the required stripe-and-mirror layout, so the command fails.

mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb1 /dev/sdc1

Why it fails: --level=0 creates striping with no redundancy, so a single disk failure destroys the array. It is tempting because RAID 0 uses both devices for capacity and speed, but the requirement is RAID 1, which mirrors identical data across /dev/sdb1 and /dev/sdc1 for fault tolerance.

Not determinable from exhibit

Why it fails: The exhibit lists each process with its RES value, so the highest physical-memory consumer is directly readable. This option is tempting when the exhibit is assumed to be missing or unreadable, but it would only be correct if the output genuinely omitted the RES column or the process list.

nginx (PID 5678)

Why it fails: nginx is a web server whose worker processes usually hold modest resident memory compared with database or JVM processes. It is tempting because nginx is a familiar service, but it would be correct only if the exhibit's RES column showed nginx holding the highest value.

systemd (PID 1234)

Why it fails: systemd is PID 1 and typically consumes minimal resident memory, far less than application processes such as nginx or databases. It is tempting because systemd appears in nearly every process listing, but it would be correct only if the exhibit actually showed systemd with the largest RES value.

CPU starvation

Why it fails: CPU starvation leaves tasks runnable but unscheduled, shown by high load with idle CPU; the exhibit's blocked state instead points to a task sleeping on a resource such as I/O or a lock. CPU starvation would be the cause when run-queue length climbs while processors stay busy.

Memory leak

Why it fails: A leak grows resident memory over time and eventually triggers the OOM killer or swapping; it does not produce the single blocked task in the exhibit. Memory leaks are the correct diagnosis when RSS climbs steadily across many processes until allocation fails.

Network congestion

Why it fails: Congestion delays packets but does not place a process in the uninterruptible D state shown; blocked tasks typically wait on I/O or locks. Network congestion is the right diagnosis when throughput drops and latency rises across many hosts, not when a single task hangs.

ip link set eth0 up

Why it fails: Brings the interface up but DHCP may not automatically start unless configured.

ip route add default via 192.168.1.1 dev eth0

Why it fails: Adds a default route but does not bring the interface up or obtain an address.

ip link set dev eth0 up

Why it fails: Same as A; may not trigger DHCP.

systemctl restart network

Why it fails: Restarts all networking, may be disruptive and not needed.

ifconfig eth0 down && ifconfig eth0 up

Why it fails: Does not read config file; would need manual assignment.

ip link set eth0 up

Why it fails: Brings interface up but does not assign IP or route.