Hard Difficulty Questions

Neither

Why it fails: The exhibit shows one file whose type differs from httpd_sys_content_t, so claiming neither is wrong. This distractor tempts candidates who assume default contexts are always correct after a fresh install, which would hold only if every file had been labelled properly.

style.css

Why it fails: style.css already carries the httpd_sys_content_t type Apache requires, so it is not the mislabelled file. This distractor tempts candidates who assume CSS assets need a separate context; that would be true only if the file sat outside the document root or used a custom policy type.

Both

Why it fails: Only one file carries a mismatched type; the other already has httpd_sys_content_t, so both cannot be incorrect. Choosing this suggests the candidate overlooked that a correctly labelled file exists, a scenario that would apply only if every listed file showed a wrong context.

RUN --mount=type=cache

Why it fails: A cache mount speeds up repeated package downloads by persisting build cache between builds; it does not merge stages or shrink the final image. Multi-stage builds with a single final stage are what combine stages. Cache mounts suit iterative local builds where dependency re-downloading dominates build time.

Layer caching

Why it fails: Layer caching reuses unchanged layers to accelerate rebuilds; it does not combine build stages or remove intermediate artefacts from the shipped image. Multi-stage builds are the mechanism that merges stages. Layer caching is the right answer when the goal is faster rebuilds, not a smaller final image.

Using a smaller base image like Alpine

Why it fails: Swapping to Alpine changes the base image, not the build structure, so intermediate layers and artefacts still ship in the final image. It is tempting because Alpine images are small, and would be correct when the requirement is trimming runtime footprint rather than eliminating build-time dependencies.

rwxrwxr-x (775)

Why it fails: That would be umask 002.

rwxrwxrwx (777)

Why it fails: That would be umask 000.

rw-rw-r-- (664)

Why it fails: That is typical for files, not directories.

apparmor_parser -r /etc/apparmor.d/profile

Why it fails: apparmor_parser -r reloads a profile from disk; it does not change the mode of an already-loaded profile, so complain mode persists unless the file itself was edited. It is tempting because reloading is how profile changes take effect, and it is correct after editing flags in the profile file, but aa-enforce is the direct mode-switch command.

aa-status --enforce /etc/apparmor.d/profile

Why it fails: aa-status only reports loaded profiles and their modes; it cannot switch a profile to enforce. The tempting assumption is that a status tool also toggles state, but enforcement is applied with aa-enforce, which writes the profile's flags and reloads it.

aa-complain /etc/apparmor.d/profile

Why it fails: aa-complain switches a profile into complain mode, the opposite of the required change, so it would leave the service logging violations without blocking them. It is tempting because it is the canonical AppArmor mode-management tool and its syntax mirrors aa-enforce, making it the obvious command to reach for when adjusting profile modes.

Set the setgid bit only on /data

Why it fails: The setgid bit only forces new files to inherit the directory's group; it does not override the user's umask, so group write permission can still be stripped. It is the right mechanism when group inheritance alone is required, but here default ACLs are also needed to enforce group read/write.

Set the sticky bit on /data

Why it fails: The sticky bit restricts deletion and renaming within a shared directory to each file's owner, doing nothing about group ownership or permission bits. It is chosen for world-writable directories such as /tmp to stop users deleting each other's files, not to enforce group ownership and access.

Configure ACL default permissions only on /data

Why it fails: Default ACLs set inherited permissions but do not change the owning group of newly created files, which still comes from the creator's primary group. ACLs are correct when only inherited access rights are needed; this policy also requires group ownership, which the setgid bit supplies.

initramfs

Why it fails: The initramfs is a temporary early userspace image that loads drivers needed to mount the real root filesystem, then hands over and is discarded. It is tempting because it executes immediately before the component in question, but it does not start services or manage system state; the init system does that.

GRUB2

Why it fails: GRUB2 is the bootloader; it loads the kernel and initramfs into memory and then exits, so it cannot start user-space services. It is tempting because it is the visible boot stage preceding kernel execution, but service startup and system-state management occur later, under the init system.

Kernel

Why it fails: The kernel has already been loaded and handed control onward; it does not start user-space services or manage system state after initramfs runs. It is tempting because the kernel underpins the whole boot, but service startup belongs to the init system, such as systemd, which the kernel merely launches as the first user-space process.

openssl genrsa -out key.pem 2048 && openssl req -new -key key.pem -out req.pem

Why it fails: This also works but is two commands, not one step. The question asks for one step.

openssl req -new -key key.pem -out req.pem

Why it fails: This assumes the private key already exists, does not create one.

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

Why it fails: This creates a self-signed certificate, not a CSR.

rescue.target

Why it fails: Rescue starts some services; emergency is more minimal.

multi-user.target

Why it fails: Multi-user starts networking and services, not ideal for recovery.

graphical.target

Why it fails: Graphical target starts the GUI, not minimal.

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.

netstat -rn

Why it fails: netstat -rn only displays the routing table; it does not modify routes. Therefore, it cannot set a default gateway.

route add default gw 192.168.1.1

Why it fails: The `route add default gw` command is a legacy method that works on many Linux distributions to set a default gateway.

ip route add default via 192.168.1.1

Why it fails: The `ip route add default via` command is the modern standard for setting a default gateway in Linux.

lsof

Why it fails: lsof lists open files and the processes holding them; it does not scan for rootkit binaries or kernel modifications. It tempts because hidden file handles can hint at compromise, but that is forensic guesswork — lsof would be correct for diagnosing file locks or open descriptors, not rootkit detection.

netstat

Why it fails: netstat reports network connections, routing tables, and interface statistics; it performs no rootkit detection. It tempts because rootkits often hide listening ports, so administrators inspect sockets, but that is manual investigation — netstat would be correct for connection troubleshooting, not rootkit scanning.

clamav

Why it fails: ClamAV is an antivirus scanner targeting malware and viruses in files and mail, not rootkit-specific integrity checking. It tempts because it is a well-known Linux security tool, and would be the right choice for malware or email gateway scanning, not for detecting hidden kernel-level rootkit components.

chcon -R -t httpd_sys_content_t /webfiles

Why it fails: chcon applies the context directly but writes no persistent policy entry, so a full filesystem relabel reverts /webfiles to default_t and access breaks again. It is tempting because it sets httpd_sys_content_t immediately and recursively, which is exactly what a temporary test or a path already covered by policy would need.

setenforce 0

Why it fails: setenforce 0 switches SELinux to permissive mode, disabling enforcement entirely rather than labelling /webfiles, so it neither sets httpd_sys_content_t nor persists as a context change. It is tempting as a quick troubleshooting step to confirm SELinux is the blocker, but it leaves the server unprotected and the mislabelling unresolved.

restorecon -Rv /webfiles

Why it fails: restorecon resets files to the context defined by the active SELinux policy for their path, so a non-standard directory like /webfiles has no matching policy rule and the files revert to default_t, remaining inaccessible. It is tempting because restorecon persists across relabels, but it requires a prior semanage fcontext mapping to work here.

status

Why it fails: Incorrect: status is automatically generated and not part of the input manifest.

Change the SSH port to a non-standard port to evade automated attacks.

Why it fails: Changing the SSH port to a non-standard port relies on security through obscurity; automated scanners can easily probe other ports, so it is not a reliable mitigation.

Disable password authentication and force key-based authentication only.

Why it fails: Disabling password authentication and forcing key-based authentication is a strong security practice, but it is not the most direct mitigation for the current attack scenario and could inadvertently lock out users who rely on passwords.

Increase MaxAuthTries to allow more retries before disconnection.

Why it fails: Increasing MaxAuthTries would allow more retries before disconnection, which worsens the attack by giving attackers more attempts per connection.

The SSH configuration file has a syntax error.

Why it fails: A syntax error would produce different error messages.

The firewall is blocking port 22.

Why it fails: Firewall blocking would not cause 'Address already in use'.

The SSH service is not enabled to start on boot.

Why it fails: The service is enabled but failed to start.

ss -tan

Why it fails: ss -tan lists TCP sockets and their states but does not attribute a listening port to a process, so it cannot reveal which process holds 8080. It is tempting because it shows port activity, yet identifying the owning process requires ss -tlnp (or lsof -i :8080), which includes PID information.

ss -tln

Why it fails: 'ss -tln' lists listening TCP sockets with their local addresses and ports, directly revealing which process holds 8080. It is tempting because it appears to filter listeners, but the stem asks for the process, and ss alone omits the PID unless -p is added.

ss -r

Why it fails: 'ss -r' resolves hostnames rather than displaying socket state or listening ports, so it cannot identify the process bound to 8080. It tempts because name resolution output looks like diagnostic detail, but port allocation conflicts require the listening-socket view instead.

The container has no logging driver configured.

Why it fails: Kubernetes captures container stdout/stderr through the container runtime's logging mechanism, so no separate logging driver is configured per container; empty output instead points to the process writing nothing before exiting. It is tempting because logging drivers exist in Docker, and would be the answer if the container ran under a runtime requiring explicit log configuration.

The log file is rotated and deleted.

Why it fails: kubectl logs reads the container runtime's log files on the node, and rotation retains recent output; a CrashLooping container's latest attempt would still show entries. It is tempting because log rotation genuinely removes old data, and would be correct if the container had run long enough for its earlier output to be rotated away before the failure.

The pod is not scheduled on any node.

Why it fails: An unscheduled pod stays Pending, never reaching CrashLoopBackOff, which requires a container that starts and exits repeatedly on a node. It is tempting because Pending pods also produce no logs, and would be the answer if kubectl get pods showed Pending with scheduling events such as insufficient resources or taints.

vgcreate vg01 /dev/sdb

Why it fails: vgcreate builds a new volume group and would fail or create a separate group rather than adding /dev/sdb to the existing vg01. It is tempting because it does incorporate a physical volume, but it suits initial volume group creation, not extending an existing group.

vgextend vg01 /dev/sdb1

Why it fails: vgextend adds physical volumes to an existing volume group, but the stem specifies the spare disk /dev/sdb, and /dev/sdb1 is a partition that may not exist. It is tempting because vgextend is the right command family, but the device argument must match the disk being added.

lvresize -L +100G vg01

Why it fails: lvresize changes the size of an existing logical volume, not the volume group's physical volume membership, so it cannot add a spare disk. It is tempting because it manipulates LVM capacity, and would be correct when extending or shrinking an LV after the PV has already been added with vgextend.

Install kernel-debuginfo packages.

Why it fails: Debuginfo packages supply symbol information for interpreting an existing vmcore during analysis; they do not configure capture. They belong in the post-crash analysis step, where resolving function names and offsets from the dump is required.

Ensure /var/crash has a vmcore file.

Why it fails: Checking for a vmcore file in /var/crash verifies a dump already exists rather than configuring capture, so it cannot ensure a valid dump is produced. It is tempting because that path is where kdump writes vmcore after a successful capture, making it the right check when confirming a completed dump.

cat

Why it fails: cat reads raw bytes and prints compressed data as binary garbage, so it cannot display the decompressed contents. It is tempting because cat is the standard way to view plain text files, and piping it into a decompressor works, but cat alone does not decompress anything.

less

Why it fails: less has no built-in decompression, so opening a gzip or bzip2 file shows unreadable binary rather than the original text. It is tempting because less is the usual pager for viewing text files, and zless exists precisely to page compressed files, but plain less cannot decompress them.