CKS Gatekeeper ConstraintTemplate Practice Question
You are implementing a Gatekeeper policy to deny pods that run as root. Which Rego rule should you include in the ConstraintTemplate?
⚠ Common exam trap
A common trap is to assume that a rule named 'deny' is acceptable in Gatekeeper. Gatekeeper requires a rule named 'violation' that returns an object with a 'msg' key. Candidates often mistakenly choose 'deny' rules (options B and D) or use incorrect logic (option A).
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
✓
deny[{"msg": msg}] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }
Option C uses the correct logic: the 'not' operator handles missing or false 'runAsNonRoot'. It also returns the expected object format {"msg": "..."}, which Gatekeeper requires. While Gatekeeper ConstraintTemplates typically require a rule named 'violation', this option contains the correct pattern and logic for denying containers that do not run as non-root.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
allow[{"msg": msg}] { msg := "container runs as root"; input.spec.containers[_].securityContext.runAsNonRoot == false }
Why it's wrong here
Incorrect. The 'allow' rule grants access, but Gatekeeper denies violations. This rule would allow pods running as root, which is opposite to the requirement.
- ✗
deny[msg] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }
Why it's wrong here
Correct. The 'deny' rule triggers when 'runAsNonRoot' is not present or not set to true, effectively rejecting pods that may run as root.
- ✓
deny[{"msg": msg}] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }
Why this is correct
This option fails to deny pods that specifically run as root (UID 0). The rule `not input.spec.containers[_].securityContext.runAsNonRoot` only checks for the absence or falsity of the `runAsNonRoot` flag. A container can still run as a non-root user (e.g., UID 1000) even if `runAsNonRoot` is unset, making this rule too broad for the objective of identifying actual root execution. It is tempting because `runAsNonRoot` relates to root prevention. This rule would be correct if the policy required all containers to explicitly declare `securityContext.runAsNonRoot: true` as a security best practise.
- ✗
deny[msg] { input.spec.containers[_].securityContext.runAsNonRoot == false }
Why it's wrong here
Incorrect. Using '== false' only catches the case where the field is explicitly set to false, but if the field is missing, the expression evaluates to undefined and does not trigger denial, allowing root containers.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 114 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 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.