CKS Minimize Microservice Vulnerabilities Practice Question
You have created a ValidatingWebhookConfiguration to reject pods without resource limits. When you try to create a pod without limits, it is created successfully. What is the most likely reason?
⚠ Common exam trap
Candidates may incorrectly assume the ValidatingWebhookConfiguration is misconfigured (e.g., missing objectSelector or wrong failurePolicy) when the actual issue is that the webhook backend service is unreachable. In Kubernetes, if the API server cannot reach the webhook server, the failurePolicy (default Ignore) allows the pod creation, so the pod passes through without validation. This is a common pitfall where the webhook service itself is not running or not accessible, rather than a configuration error.
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 service is not running or is unreachable
The most likely reason a pod without resource limits is created successfully despite a ValidatingWebhookConfiguration is that the webhook service itself is not running or is unreachable. When the API server cannot contact the webhook endpoint, the default behavior (failurePolicy: Ignore) allows the request to proceed, so the pod is created without validation. If the webhook were functioning correctly, it would reject the pod; thus, the failure to reject indicates a connectivity or service issue.
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 is not matching the namespace labels
Why it's wrong here
Namespace label selectors only scope which namespaces the webhook intercepts; a non-matching selector means the webhook never fires, so admission proceeds unmodified. Label selectors are tempting because they are a common scoping mechanism, and would be the cause if the pod were created in an excluded namespace.
- ✓
The webhook service is not running or is unreachable
Why this is correct
An unreachable webhook service causes the API server's admission call to fail. With failurePolicy set to Ignore (the default), the API server permits the request, so the pod is created despite the ValidatingWebhookConfiguration. This satisfies the stem's constraint: rejection never occurs because the webhook cannot be evaluated.
- ✗
The webhook is configured with failurePolicy: Fail
Why it's wrong here
failurePolicy: Fail makes the API server reject requests when the webhook is unreachable, so it enforces rather than bypasses validation. It is tempting because Fail is the strict setting administrators often choose deliberately, and would be correct when the requirement is to block pods if the webhook call itself errors.
- ✗
The pod is being created by a controller like a Deployment
Why it's wrong here
Admission webhooks run on every API request regardless of the originating controller; a Deployment-created pod still passes through the API server, so this does not explain the bypass. It is tempting because controller-managed pods are a common source of unexpected objects, and would matter if the webhook excluded specific service accounts.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.