CKS Minimize Microservice Vulnerabilities Practice Question
A security engineer needs to ensure that all containers in a cluster run as non-root users. Which Pod Security Context field should be set to enforce this requirement?
⚠ Common exam trap
The CKS exam often tests the distinction between setting a specific user ID (`runAsUser`) and enforcing a non-root check (`runAsNonRoot`), where candidates mistakenly think that specifying a non-zero UID alone guarantees the container is not running as root, ignoring that the image might still run as root if the UID is not set in the image.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
runAsNonRoot: true
Setting `runAsNonRoot: true` in the Pod Security Context explicitly instructs the container runtime to verify that the container's user ID is non-zero (i.e., not root). If the container image is configured to run as root (UID 0), the Pod will fail to start, enforcing the requirement that all containers run as non-root users.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
runAsNonRoot: true
Why this is correct
The `runAsNonRoot: true` Pod security context setting forces Kubernetes to validate that the container image specifies a non-root user (e.g., via USER in the Dockerfile) or that a `runAsUser` value is explicitly set to a non-zero UID; if the image would run as UID 0, the Pod API request is rejected during admission, preventing the container from ever starting as root. This is the only option that directly enforces non-root execution at the container level, independent of the image's default behavior. It is the correct choice for the requirement to ensure all containers run as non-root.
- ✗
runAsUser: 1000
Why it's wrong here
Setting runAsUser to a non-zero UID does not guarantee that the container's image does not run as root; it only overrides the user. A root image could still run with root privileges if runAsUser is not set, but the requirement is to enforce non-root, not just set a user.
- ✗
privileged: false
Why it's wrong here
Setting `privileged: false` (which is also the default) merely ensures the container is not granted extended Linux capabilities beyond the default set and does not have host device access; it does not place any constraint on the UID under which the container's main process runs. A container running as root with default capabilities still executes with UID 0, violating a non-root requirement. Thus, disabling privileged mode addresses privilege breadth, not the identity used to run the process.
- ✗
allowPrivilegeEscalation: false
Why it's wrong here
Setting `allowPrivilegeEscalation: false` prevents the container's process from gaining additional privileges beyond those initially granted, such as through setuid binaries or `CAP_SYS_ADMIN`-style operations, but it does not restrict the initial UID or require that the container run as a non-root user. The main process can still start as UID 0; the flag only stops it from escalating further after start. Therefore, this control limits privilege escalation, not the root execution mode itself.
Go deeper
Related to this question
About these practice questions
One of 114 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.