CKS Minimize Microservice Vulnerabilities Practice Question
A security admin wants to ensure that no container in a specific namespace runs as root. Which Gatekeeper ConstraintTemplate and Constraint configuration should be used?
⚠ Common exam trap
CKS often tests the direction of the Rego condition — candidates mistakenly write `== true` when the deny rule must fire on the insecure state (`!= true`), inverting the policy.
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
✓
ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot != true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
The goal is to deny any Pod whose containers do not explicitly set runAsNonRoot to true. In Rego, the deny rule must fire when the condition is violated, so the correct expression is `input.review.object.spec.containers[_].securityContext.runAsNonRoot != true`. This matches containers that either omit the field or set it to false, which is exactly the insecure state the admin wants to block. The Constraint then binds this template to Pods via match.kinds.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
Why it's wrong here
This policy inverts the intended check: it triggers a denial whenever runAsNonRoot is explicitly true. Consequently, a pod whose containers correctly set runAsNonRoot: true would be rejected, while containers that omit the field (evaluating to false) would pass, allowing potentially root-running workloads. The logic must test for `!= true` to catch false and missing values, not `== true`.
- ✓
ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot != true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
Why this is correct
This constraint correctly enforces the non-root requirement by denying any pod in which any container does not set `securityContext.runAsNonRoot` to true. In Rego, a missing field evaluates as false, so `runAsNonRoot != true` catches both explicit `false` and undefined cases, blocking containers that could run as root. The constraint scope on Pods ensures every container in the spec is evaluated without exception.
- ✗
ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.capabilities.drop != "ALL" }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
Why it's wrong here
This policy mistakenly focuses on capability drops rather than user context. Even if a container drops all Linux capabilities, it can still run as root (UID 0) and gain elevated privileges that are not necessarily gated by capabilities. The security requirement is about preventing root execution, so checking `capabilities.drop` does not address the intended control and provides a false sense of compliance.
- ✗
ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
Why it's wrong here
This check only denies containers with an explicit `runAsUser: 0`, but many images default to UID 0 without the field being set, and some legitimate configurations may set runAsUser to a non-zero value while still lacking a non-root guarantee. The `runAsNonRoot` field is the proper Kubernetes mechanism because it forces the kubelet to verify the container will not run as root, regardless of how the image or securityContext is configured, and is the recommended approach for Pod Security Standards.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.