CKS System Hardening Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Using read-only root filesystems

  Why it's wrong here

  Using a read-only root filesystem is a recommended hardening practice because it prevents the container's runtime processes from modifying the image layers, thwarting malware persistence and tampering with binaries or configuration files. It forces any necessary writes to be performed on a mounted ephemeral tmpfs or a dedicated volume, which are cleared or isolated on restart. Container runtimes enforce this via the --read-only flag or Kubernetes securityContext.readOnlyRootFilesystem: true, ensuring that even a compromised web server process cannot plant backdoor scripts inside the container's own rootfs. Thus, this is a valid attack-surface-reduction measure and not the non-recommended option.

• ✗

  Running containers as non-root

  Why it's wrong here

  Running containers as non-root is a standard least-privilege control because a root user inside a container, despite Linux user namespaces, retains dangerous capabilities and maps to UID 0 on the host, increasing the blast radius of a container breakout. Kubernetes implements this with securityContext.runAsNonRoot: true, which rejects images that run on UID 0, and runAsUser to a predefined unprivileged UID. Non-root execution significantly reduces the chance of host filesystem access and privilege escalation through setuid binaries or kernel vulnerabilities. Therefore, it is a recommended method to reduce attack surface, not the exception asked for.

• ✓

  Running containers with privileged: true

  Why this is correct

  Setting privileged: true in a Kubernetes pod security context is explicitly not recommended because it disables almost all container isolation features: it grants every Linux capability, removes seccomp restrictions, and allows the container to access host devices, the host kernel, and perform operations like loading kernel modules or altering network settings. The privilegeEscalation flag is implicitly forced to true, meaning the container process gains all capabilities of the root user and can use raw sockets, mount filesystems, and read/write to /dev. This effectively turns the container into a process running with host-level root privileges, making a single compromised process equivalent to a full host compromise. Such a configuration dramatically increases the attack surface and should never be used in a security-conscious cluster, making it the correct answer.

• ✗

  Disabling unnecessary system services on nodes

  Why it's wrong here

  Disabling unnecessary system services on cluster nodes is a fundamental node hardening step because every running service, especially network-facing ones like SSH, kubelet ports, or the Docker daemon socket, expands the kernel and user-space attack surface. Removing or stopping components such as the GUI, CUPS, Bluetooth stack, or unused kernel modules reduces the number of vectors an attacker can exploit post-compromise and limits lateral movement. Kubernetes node hardening guidelines often recommend minimizing the host OS footprint, using immutable infrastructure, and applying CIS Benchmarks that specifically require disabling legacy services. Since this is clearly a defense-in-depth practice that reduces the node-wide attack surface, it is a recommended method and therefore not the correct answer.

Go deeper

Related to this question