Refer to the Exhibit Practice Questions

lvextend -L+10g vg0/var

Why it fails: lvextend grows a logical volume's size and never changes its active or inactive state, so the inaccessible /var remains offline. It is tempting because lvextend also targets vg0/var, and it is the correct command when an active volume simply needs additional capacity.

lvscan

Why it fails: lvscan only reports logical volume attributes, including active state, so it diagnoses that var is inactive without activating it. It is tempting because it names the volume and confirms the fault, and it would be the right command when you need to enumerate LVs before deciding what to fix.

lvcreate -a y vg0/var

Why it fails: lvcreate builds a new logical volume, so running it against the existing vg0/var fails rather than activating anything. It is tempting because the -a y flag does set activation at creation time, which is why lvcreate -a y is the right tool when provisioning a fresh LV, not reviving an inactive one.

The container's IP address is incorrect.

Why it fails: The container answers on its own IP, proving the address is valid and the web server is running. It is tempting because a mistyped address would explain unreachability, and an incorrect container IP would be the right choice when curl to that address also fails to connect.

Nginx is configured to listen on a different port.

Why it fails: The container responds on port 80 via its own IP, so Nginx is listening there; only host-IP access fails, indicating no published port mapping. It is tempting because a misconfigured listen directive would explain the symptom, and that would be the right choice when curl to the container IP on port 80 also fails.

The container is not running.

Why it fails: The stem states the container is reachable via curl on its container IP, which proves the process is running and serving traffic; a stopped container would refuse that connection too. It tempts because checking container state is a sensible first diagnostic, and it would be the answer if curl to the container IP also failed.

The server is experiencing a network timeout.

Why it fails: A network timeout produces a client-side timeout error or HTTP 504 from a gateway, never a completed 200. Timeouts are diagnosed when requests hang or fail to reach the server. Since the call returned 200, connectivity succeeded and the empty body originates in the application or query layer.

The SSL certificate is expired or invalid.

Why it fails: An expired or invalid TLS certificate causes handshake failures, typically surfacing as connection errors or HTTP 495/496, not a successful 200 with an empty body. Certificate validation matters when diagnosing trust or handshake failures, but here the request completed, so the response payload itself is the issue.

The API endpoint has been moved permanently (301).

Why it fails: A 301 response redirects the client to a new location and returns that status code, not 200. Permanent redirects matter when endpoints are relocated and clients must follow Location headers. Here the call already returned 200, so the endpoint resolved correctly and the empty payload stems from something else.

The script is owned by the wrong user

Why it fails: Ownership does not determine whether run-parts executes a /etc/cron.daily script; the execute permission bit does. Ownership tempts because incorrect ownership blocks other scheduled tasks, yet here the exhibit points to a missing execute bit, which prevents execution regardless of which user owns the file.

The cron daemon is not running

Why it fails: A stopped cron daemon would prevent every scheduled job from running, not just this one script, and the exhibit shows other jobs functioning. It tempts because a dead daemon is a classic cause of silent scheduling failure, but the evidence isolates the fault to this file's permissions.

The script is not listed in /etc/crontab

Why it fails: Scripts in /etc/cron.daily are run by run-parts, which reads the directory directly; /etc/crontab does not need individual entries for them. The option tempts because /etc/crontab does schedule jobs, but those are explicit user-and-command lines, not directory-based daily runs.

Anacron is not installed

Why it fails: Anacron's absence does not stop cron from executing /etc/cron.daily entries; cron itself runs them, and anacron merely catches up missed jobs on systems not running continuously. It tempts because anacron does handle daily jobs, but the exhibit's failure concerns the script's own attributes, not the scheduler's presence.

Change the ownership to root.

Why it fails: Ownership is already apache and mode 664 grants group write, so the denial stems from an SELinux type mismatch on the log file, not Unix ownership. Changing ownership to root would worsen access. Root ownership is correct for system binaries or protected configuration files, not for a daemon's own writable log.

Set the httpd_can_network_connect boolean.

Why it fails: The httpd_can_network_connect boolean governs outbound network connections from httpd, not filesystem writes, so toggling it leaves the SELinux denial on /var/log/app.log unresolved. That boolean is the right fix when a web application must reach a remote database or API and SELinux blocks the socket.

Disable SELinux for the httpd daemon.

Why it fails: Disabling SELinux enforcement for httpd removes the mandatory access control protecting the whole service, exceeding what a single log-write denial warrants and breaching the requirement to maintain policies. Per-domain disabling is chosen only when a vendor application is fundamentally incompatible with targeted policy and no custom module can be written.

Change the owner to the user with chown

Why it fails: The script already has an owner; changing ownership with chown does not add the execute bit to the file's permission mode, so the kernel still refuses execution. chown is used to transfer file ownership between users or groups, which would be the right action for reassigning accountability, not granting execute rights.

Change the group to the user's primary group

Why it fails: Group ownership governs access for other accounts, not the execute bit the user needs, so chgrp leaves the permission denied error intact. It is tempting because group membership is a legitimate way to grant shared access, correct when several users must read or write the same file.

Set the permissions to 644 with chmod

Why it fails: Mode 644 grants read and write to the owner and read-only to group and others, leaving no execute bit set, so the kernel still returns Permission denied. chmod 644 is used to make a data file readable by all while writable only by its owner, which is correct for configuration or document files, not executables.

The service type should be forking

Why it fails: Type=forking suits daemons that background themselves after a parent exits; a script running in the foreground with Type=simple is expected to stay in the foreground, so forking would make systemd misjudge startup. It is tempting for traditional daemonised services, which is when forking is genuinely required.

The service file lacks an [Install] section

Why it fails: The [Install] section governs enablement and boot-time symlinks, not execution, so its absence leaves manual start unaffected. It is tempting because omitting it prevents systemctl enable, and it would be the correct answer when a service starts fine but does not launch automatically at boot.

The Requires directive is missing

Why it fails: Requires only adds a dependency relationship; its absence does not itself cause a unit to enter failed state. It is tempting because missing dependencies do break units, and Requires would be correct when the service genuinely needs another unit active, such as a database, before starting.

The volume group is corrupted.

Why it fails: Corruption of a volume group would typically surface as a VG status fault or missing VG, not a PV flagged unavailable. The exhibit points to the PV layer itself, so blaming the VG misreads which LVM object reports the fault.

The logical volume is not mounted.

Why it fails: A missing mount leaves the filesystem inaccessible but does not change the physical volume's status in pvdisplay; an unmounted LV still reports the PV as available. Mounting is a filesystem-layer action, unrelated to LVM's own metadata tracking of the PV.

LVM metadata is damaged.

Why it fails: Damaged LVM metadata would usually produce checksum or read errors and an unknown PV, not a clean 'not available' status. The exhibit indicates the PV exists but is not allocatable, which points elsewhere than metadata corruption.

The file is world-writable.

Why it fails: World-writable permissions let any user modify or replace the file's contents, but the exhibit's security implication concerns the SUID/SGID privilege bits, not write access. It is tempting because world-writable files are a genuine risk, and it would be correct if the permissions showed the final write bit set for others.

The SGID bit is set, allowing users to run passwd with group root.

Why it fails: The SGID bit on an executable makes it run with the file's group, not root's group; passwd's privilege comes from its SUID root bit, which sets the effective user ID. It is tempting because SGID does confer elevated group rights, and it would be correct for a shared directory or a group-privileged binary.

The sticky bit is set, preventing deletion of the file.

Why it fails: The sticky bit on a directory restricts deletion of files to their owners; on a file it is largely obsolete and does not prevent deletion. It is tempting because it genuinely governs deletion rights, but only within shared directories such as /tmp, not for the file permissions shown in the exhibit.

The network router is blocking the user's traffic.

Why it fails: Traffic to a server on the same subnet is delivered by ARP and Layer 2 switching, never through the router, so router filtering cannot explain one local host failing while another succeeds. Router ACLs are the answer when failures cross subnet boundaries.

The web server is down.

Why it fails: A server outage would prevent the second host on the same subnet from connecting too, contradicting the exhibit. Server-down is the right conclusion when all clients, regardless of subnet, report connection timeouts or refused connections to that service.

DNS is resolving to the wrong IP for the user.

Why it fails: A wrong DNS record would typically affect every host using that resolver, yet another host on the same subnet reaches the server, so name resolution is not the differentiator. DNS troubleshooting is correct when multiple clients resolve a name to a stale or incorrect address.

To log all successful login attempts on the system

Why it fails: Successful logins are recorded through watches on authentication paths such as /var/log/faillog or PAM-related files with specific syscall filters, not by file watches on account databases. It is tempting because login auditing is a standard requirement, and dedicated rules for authentication events would be the right choice.

To log any modifications to the audit configuration itself

Why it fails: Auditing the audit configuration itself requires watches on /etc/audit/ and auditd.conf with write and attribute-change permissions; file-access rules on account databases do not cover those paths. It is tempting because tampering with auditd is a recognised threat, and such watches would be correct for detecting configuration changes.

To log all read accesses to /etc/passwd, /etc/shadow, and /etc/group

Why it fails: The rules' watch keys and permission filters determine which file accesses are recorded; a rule set targeting write and attribute-change events would not capture read accesses. It is tempting because auditing /etc/passwd, /etc/shadow and /etc/group is a common hardening goal, but that requires read-permission watches on those paths.

The SSH configuration file has a syntax error.

Why it fails: A syntax error in sshd_config causes sshd to refuse to start and log a parse error naming the offending line, which the exhibit does not show. It is tempting because misconfiguration commonly breaks sshd, and would be correct if the log quoted an unrecognised keyword or bad directive.

The sshd PID file cannot be written.

Why it fails: An unwritable PID file produces a specific error about /run/sshd.pid and typically follows a permissions or stale-file problem, which the exhibit does not indicate. It is tempting because PID file issues do stop sshd, and would be correct if the log referenced that path.

The SSH port is already in use by another service.

Why it fails: A port already in use yields an explicit bind error naming the address and port, showing another process holds 22. The exhibit shows no such bind failure. It is tempting because port conflicts are a common sshd startup fault, and would be correct if the log reported Address already in use.

The container is running in privileged mode.

Why it fails: Privileged mode grants the container broad capabilities and would typically bypass, not cause, permission errors. It tempts because privileged mode is associated with permission problems. The actual cause is host filesystem ownership or mode denying the container's non-root user access to the bind-mounted path.

The Docker daemon is not running as root.

Why it fails: The daemon runs as root by design; that is unrelated to a container's bind mount permission error. This tempts because daemon privilege sounds relevant to access control. The real mechanism is UID/GID mapping: the container process's user lacks permission on the host path, regardless of daemon privileges.

The volume path on the host does not exist.

Why it fails: A missing host path makes Docker create an empty directory (with -v) or fail outright, but the reported symptom is a permission error, not absence. This distracts because nonexistent bind sources are a common startup failure. The actual cause is host file ownership or mode denying the container's user access.

sudo passwd -x 90 root

Why it fails: The -x flag sets maximum password age in days, but passwd -x 90 root also needs the password changed to take effect; chage -M 90 sets the expiry directly on the shadow entry. Tempting because passwd manages password ageing, yet chage is the dedicated tool for account expiry fields.

sudo chage -E 90 root

Why it fails: chage -E sets the account expiration date, not the password maximum age, so it would disable root on a fixed date rather than force a 90-day rotation. Tempting because chage is the correct tool for ageing policy, but -M, not -E, controls password lifetime.

sudo usermod -e 90 root

Why it fails: usermod -e sets the account expiry date, locking the account on a calendar date rather than enforcing a 90-day password lifetime. Tempting because usermod modifies account attributes, but password ageing belongs to chage -M or passwd -x, which write the shadow maximum-age field.

The service is masked.

Why it fails: Masking symlinks the unit to /dev/null, so systemctl status would show "masked" rather than the loaded/active state the exhibit displays; the option misreads the output. It tempts because masked units cannot start, and that diagnosis would be correct if the exhibit showed a symlink to /dev/null.

The service is inactive.

Why it fails: Inactive means loaded but not running, whereas the exhibit shows the unit's current state as active; the option contradicts the displayed Active line. It tempts because inactive is a common sshd fault, and it would be correct if the exhibit showed Active: inactive (dead) with no listening process.

The service has exited.

Why it fails: An exited service shows as inactive (dead) with no running process; the exhibit would need to show that state. It is tempting because 'exited' sounds like a stopped service, but a running sshd is active, so this misreads the status output.