CKS Supply Chain Security Practice Question
You have configured Kyverno to enforce that all Pods must have an image from a trusted registry. However, a newly created Pod is not being rejected even though it uses an untrusted image. What is the most likely reason?
⚠ Common exam trap
Watch out — candidates often assume admission control is bypassed by controllers like Deployments, but in Kubernetes, all API requests—including those from controllers—go through admission webhooks; the real issue is usually a misconfigured failure policy or rule mismatch.
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 Kyverno webhook is not invoked because the failure policy is set to Ignore or the resource is not matched by the policy's rules
Kyverno operates as a dynamic admission controller via a MutatingAdmissionWebhook or ValidatingAdmissionWebhook. If the webhook's failure policy is set to `Ignore`, the webhook will not block the Pod creation when it fails to invoke, and the Pod will be admitted. Additionally, if the policy's rules do not match the Pod (e.g., due to incorrect resource selection or namespace exclusion), the webhook will not be triggered, allowing untrusted images through.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Kyverno is not an admission controller; it only mutates resources
Why it's wrong here
Kyverno is fundamentally an admission controller: it installs both a MutatingAdmissionWebhook and a ValidatingAdmissionWebhook into the cluster. These webhooks intercept API requests at the admission phase, allowing Kyverno to not only mutate resources (like adding default labels) but also validate them and reject noncompliant requests. The claim that it 'only mutates resources' conflates one of its capabilities with its full role; validation and generation are also core features.
- ✗
The Kyverno policy requires an external registry to compare images, which is unavailable
Why it's wrong here
Kyverno policies can enforce image rules (e.g., disallowing the 'latest' tag, requiring a specific registry prefix, or checking for an allowed image signature) using YAML pattern matching and conditional anchors directly on the Pod's image field. These rules are evaluated from the resource definition alone, requiring no external network calls. Only specific policy types like 'verifyImages' explicitly query a container registry, and your scenario does not indicate that such a policy is in use.
- ✓
The Kyverno webhook is not invoked because the failure policy is set to Ignore or the resource is not matched by the policy's rules
Why this is correct
The failurePolicy field in Kyverno's ValidatingWebhookConfiguration controls what happens when the webhook cannot be invoked or errors. If set to 'Ignore', any webhook failure is silently ignored and the request proceeds, so the policy would not block the Pod if, for example, the webhook endpoint is unavailable. Additionally, Kyverno policies can have match statements (e.g., specific kinds, namespaces, label selectors) — if this Pod does not match those criteria, the webhook receives the request but the policy simply does not apply to it.
- ✗
The Pod was created by a Deployment controller, which bypasses admission control
Why it's wrong here
Kubernetes admission controllers run for every API request, regardless of whether the requester is a human user, a Deployment controller, or any other automation. When a Deployment creates a ReplicaSet, and that ReplicaSet later creates a Pod, each of those create requests is processed by the API server's admission chain, including any dynamically configured admission webhooks. Thus a Pod created by a Deployment is not bypassing admission control; its Pod creation request still triggers Kyverno's webhook if the webhook's rules match Pod resources.
Go deeper
Related to this question
Learn chapter
Cluster Hardening: Resource Quotas and Limit Ranges
Key term
OPA Gatekeeper
OPA Gatekeeper is a Kubernetes admission controller that enforces custom security and compliance policies on resources before they are created or updated in a cluster.
Key term
Node Restriction
A Kubernetes admission controller that limits what a kubelet can modify on its own node to prevent privilege escalation and unauthorized access.
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.