CKS runAsNonRoot 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.

• ✓

  Set runAsNonRoot to true in securityContext

  Why this is correct

  Setting runAsNonRoot to true in the securityContext forces the container process to run with a non-zero UID, preventing it from having root privileges. This is a critical defense-in-depth control because even if container is compromised, the attacker cannot exploit root-level capabilities to escalate to the host. Kubernetes will also reject the pod if the image specifies USER root when admission policies enforce this setting.

• ✗

  Run containers as root inside the container for easier management

  Why it's wrong here

  Running containers as root grants the container process all Linux capabilities and full write access to mounted volumes, which often retain host permissions. If an attacker exploits a kernel vulnerability or misconfigured mount, gaining root inside the container can easily lead to root on the host. This violates the principle of least privilege and dramatically increases the blast radius of any container compromise.

• ✓

  Set readOnlyRootFilesystem to true in securityContext

  Why this is correct

  Setting readOnlyRootFilesystem to true in the securityContext makes the container's root filesystem read-only, requiring all writes to go to explicitly mounted volumes. This prevents an attacker from tampering with executable binaries, system libraries, or configuration files at runtime, even if they gain code execution. It is a powerful reduction of the attack surface and enforces a stateless, immutable container pattern, often paired with a tmpfs mount for /tmp to maintain functionality.

• ✗

  Mount the docker socket inside the container for debugging

  Why it's wrong here

  Mounting the docker socket (/var/run/docker.sock) inside a container exposes the Docker daemon's API to the container process. This gives the container the ability to create privileged containers, modify host network and storage resources, and effectively control the entire host through the daemon. Such access enables straightforward container escape and arbitrary host-level code execution, making it one of the most dangerous host paths to expose to any workload, even for debugging.

• ✗

  Use the latest tag for all images

  Why it's wrong here

  Using the 'latest' tag for images is discouraged because the tag is mutable and does not point to a specific immutable build. At any pull, 'latest' may resolve to a different image, leading to inconsistent deployments, broken rollbacks, and difficulty reproducing the exact vulnerable code. Furthermore, image scanners and security policies rely on immutable tags to identify and gate on known vulnerabilities, so 'latest' bypasses proper supply chain controls.

Go deeper

Related to this question