CKS Supply Chain Security Practice Question
You are configuring ImagePolicyWebhook admission controller to reject images not signed by a trusted authority. After deploying the webhook, you notice that pods are being rejected even for images that are properly signed. Which configuration change is MOST likely to fix this?
⚠ Common exam trap
The CKS exam often tests the distinction between `failurePolicy: Fail` (default) and `failurePolicy: Ignore`, tricking candidates into thinking the issue is with webhook type or permissions rather than the failure handling behavior.
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
✓
Set failurePolicy to Ignore in the webhook configuration
The ImagePolicyWebhook admission controller uses a webhook to validate images. When the webhook is unreachable or returns an error, the default behavior is to reject the request. Setting `failurePolicy` to `Ignore` allows the API server to admit the pod when the webhook fails, which is necessary if the webhook is temporarily unavailable or misconfigured but images are properly signed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the memory limit of the API server
Why it's wrong here
Increasing the kube-apiserver's memory limit only affects its own heap and cache capacity; it does not influence the API server's ability to make outbound HTTP connections to the webhook service. ImagePolicyWebhook runs as an admission plugin inside the API server process, and when it reports that the webhook cannot be reached, the cause is typically a DNS resolution failure, network policy blocking the egress, or an invalid TLS certificate in the webhook connection. Raising the memory limit addresses resource exhaustion, not connectivity, so this action would not resolve the webhook reachability error.
- ✗
Change the webhook from 'MutatingAdmissionWebhook' to 'ValidatingAdmissionWebhook'
Why it's wrong here
ImagePolicyWebhook is a dedicated admission controller enabled via the --enable-admission-plugins flag and configured with its own configuration file; it is not an instance of MutatingAdmissionWebhook or ValidatingAdmissionWebhook. The latter two are generic webhook controllers that require you to register webhook configurations, but they do not change how ImagePolicyWebhook behaves. The error you are seeing is about the ImagePolicyWebhook plugin's inability to call its configured backend, so switching between generic webhook types has no impact on that separate mechanism.
- ✓
Set failurePolicy to Ignore in the webhook configuration
Why this is correct
When the webhook cannot be reached, the API server rejects the request. Setting failurePolicy: Ignore allows pods to be admitted even if the webhook is unavailable, but this is a temporary fix. The root cause might be network connectivity to the webhook service.
- ✗
Grant the webhook service account cluster-admin role
Why it's wrong here
The image policy webhook is an external service that receives admission requests from the kube-apiserver; it does not make requests to the Kubernetes API, so its RBAC permissions are irrelevant to whether the API server can reach it. The API server authenticates to the webhook using the credentials specified in the webhook configuration (e.g., TLS client certificate), not via a Kubernetes service account. Granting cluster-admin to the webhook's service account would be a severe security escalation and would not fix the connectivity or TLS configuration problem that prevents admission requests from arriving.
Go deeper
Related to this question
Learn chapter
Cluster Setup: Secure Configuration and Best Practices
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 114 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 →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A cluster has the ImagePolicyWebhook admission controller enabled. A pod creation is denied with the message 'image policy check failed'. The webhook server returns an error. Which of the following could be a valid reason?
hard- ✓ A.The image is not signed by a trusted authority
- B.The container runtime is out of date
- C.The image tag does not exist in the registry
- D.The pod specification has a hostNetwork: true
Why A: The ImagePolicyWebhook admission controller intercepts pod creation requests and queries an external webhook server to determine whether the image should be allowed. If the webhook returns an error (e.g., HTTP 5xx or a denial response), the admission controller fails the request with 'image policy check failed'. A common reason for the webhook to deny the request is that the image is not signed by a trusted authority, as the webhook may be configured to enforce image signature verification (e.g., using Notary or Sigstore).
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.