CKS Minimize Microservice Vulnerabilities Practice Question
An OPA/Gatekeeper ConstraintTemplate is defined with the following Rego rule:
violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.runAsNonRoot != true msg := "Container must run as non-root"
}
What happens when a pod is submitted with a container that has runAsNonRoot: true?
⚠ Common exam trap
The CKS exam often tests the subtle difference between `!= true` and `== false` in Rego — candidates mistakenly think `!= true` catches only `false` values, but it also catches `null` (missing field), and they forget that an explicit `true` passes the check, leading them to choose denial or mutation options.
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
✓
The pod is admitted
The Rego rule `container.securityContext.runAsNonRoot != true` only triggers a violation when the field is not set to `true`. When `runAsNonRoot: true` is explicitly set, the condition evaluates to `false`, so no violation is generated, and the pod is admitted without any denial or mutation. OPA/Gatekeeper by default enforces constraints by denying admission; it does not mutate resources or generate audit logs unless specifically configured for dry-run or audit mode.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The pod is admitted but an audit log is generated
Why it's wrong here
Gatekeeper acts as a validating admission webhook, so its admission decision is binary: it either allows or denies the request. It does not generate audit logs as part of the admission path; audit functionality, when enabled, runs separately and periodically reports violations on existing resources. Therefore, saying an audit log is generated upon admission is incorrect—the constraint either permits the pod or rejects it, with no implicit audit side effect.
- ✓
The pod is admitted
Why this is correct
For a pod that explicitly sets securityContext.runAsNonRoot: true, the Gatekeeper constraint's violation condition (runAsNonRoot != true) evaluates to false. Since the Rego policy only triggers a denial when a violation is found, no violation exists and the admission request is allowed. Thus the pod is admitted without any message, mutation, or further side effects.
- ✗
The pod is denied with a message
Why it's wrong here
Denial would only occur if the violation expression were true, meaning the pod spec either omits runAsNonRoot or sets it to false. In the given scenario, runAsNonRoot is explicitly true, so the condition is false and the deny logic in the constraint template never executes. Consequently, a denial message is not produced for this pod.
- ✗
The pod is mutated to set runAsNonRoot
Why it's wrong here
Gatekeeper's constraint framework is a validating webhook, not a mutating one; it cannot alter the pod spec to add securityContext fields. Mutations would require a separate mutating admission webhook, such as Gatekeeper's mutation feature or another controller, and the constraint template itself has no mutation capabilities. Therefore, the pod is not modified to set runAsNonRoot; it remains exactly as submitted.
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.