CKS Minimize Microservice Vulnerabilities Practice Question
An admin has deployed a ValidatingWebhookConfiguration that denies pods with `runAsNonRoot: false`. After creating a pod that does not set `runAsNonRoot` at all, the pod is created successfully. Why did the webhook not deny it?
⚠ Common exam trap
The CKS exam often tests the misconception that a webhook's failure policy (Ignore/Fail) controls whether it denies requests, when in fact the `rules` matching is the primary gate for webhook invocation.
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 webhook configuration's rules do not match the pod create operation
A is correct because the ValidatingWebhookConfiguration's `rules` define which API operations (e.g., create, update) and resources (e.g., pods) trigger the webhook. If the rules do not include the `create` operation for pods, the webhook will not intercept the pod creation request, so the pod is created without validation. The pod's security context (missing `runAsNonRoot`) is irrelevant if the webhook never fires.
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 webhook configuration's rules do not match the pod create operation
Why this is correct
For a ValidatingWebhookConfiguration to be triggered, the incoming request must match the declared rules on apiGroups, apiVersions, resources, and operations. If the rules omit the 'pods' resource or the 'create' operation (or the pod's API version/group), the API server bypasses this webhook entirely. Thus, the observed absence of any admission response is fully explained by a rules mismatch, making this the correct answer.
- ✗
The webhook's failure policy is set to Ignore
Why it's wrong here
The failurePolicy field only governs what happens after the API server successfully dispatches a request to the webhook and the webhook either errors, times out, or is unreachable. With 'Ignore' the API server fails open and allows the pod, but the webhook is still contacted first. Since the pod was created without the webhook ever being invoked, a failurePolicy of Ignore cannot account for the missing admission call.
- ✗
The webhook is only applied to pods in a specific namespace
Why it's wrong here
While webhook configurations can be scoped to specific namespaces using namespaceSelector labels, this restricts only which namespaces' objects trigger the webhook; it does not make the webhook 'only applied to pods in a specific namespace' absent a configured selector. The question provides no information that a namespaceSelector was set or that the pod's namespace fell outside it, so this is an unsupported inference.
- ✗
The webhook only applies to pods created with a specific service account
Why it's wrong here
ValidatingWebhookConfiguration uses rules and selectors based on object metadata (like namespace labels or object labels), but never on service accounts. The AdmissionReview payload contains userInfo (including username, groups, and service account across the 'system:serviceaccount' namespace), yet the webhook configuration itself cannot designate a service account as a match criterion. Therefore, a service-account limitation could not be the cause of the webhook never being called.
About these practice questions
One of 845 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.