A security engineer is hardening a Kubernetes cluster. They want to reduce the risk of container escape attacks. Which combination of settings is most effective at the pod security context level?
Drops all capabilities, enforces non-root, and read-only filesystem – defense in depth against escapes.
Why this answer
Setting `runAsNonRoot: true` prevents the container from running as the root user, `readOnlyRootFilesystem: true` prevents writes to the container's root filesystem, and dropping all Linux capabilities with `drop: ['ALL']` removes all kernel privileges. Together, these three settings at the pod security context level drastically reduce the attack surface for container escape attacks by eliminating common privilege escalation vectors.
Exam trap
The CAS-004 exam often tests the misconception that setting a specific `runAsUser` (like 1000) is equivalent to enforcing non-root execution, when in fact `runAsNonRoot: true` is the explicit directive that prevents root UID (0) from being used, regardless of the numeric UID set.
How to eliminate wrong answers
Option B is wrong because `runAsNonRoot: false` allows the container to run as root, which is a primary vector for container escape; even with a read-only root filesystem, a root process can still use capabilities or syscalls to break out. Option C is wrong because setting `runAsUser: 1000` does not prevent running as root (it only sets a specific UID but does not enforce non-root), and adding `NET_ADMIN` capability grants network administration privileges that can be abused for escape, increasing risk rather than reducing it. Option D is wrong because `privileged: true` disables all security isolation, effectively giving the container host-level access, and `readOnlyRootFilesystem: false` allows writes to the root filesystem, making container escape trivial.