CKS Supply Chain Security Practice Question
You want to allow only images from a specific registry (e.g., myregistry.io) to be deployed in your cluster. Which tool or approach is best suited for this requirement?
⚠ Common exam trap
A common misconception is that NetworkPolicy can control image sources, but NetworkPolicy operates on network traffic, not on admission of pod specifications.
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
✓
Use OPA/Gatekeeper to create a constraint that checks the image registry
OPA/Gatekeeper allows you to define a ConstraintTemplate and a Constraint that validates the image registry in pod specs via a Rego rule. This approach enforces admission control at the API server level, rejecting any pod that references an image from an unauthorized registry before it is persisted in etcd.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use OPA/Gatekeeper to create a constraint that checks the image registry
Why this is correct
OPA/Gatekeeper operates as a validating admission controller that can evaluate the entire Pod spec before creation. By writing a ConstraintTemplate and a Constraint with Rego logic, you can inspect every container's image field, including initContainers and ephemeral containers, and enforce that the image reference begins with your approved registry host. This is the correct approach because admission control is the only layer that can consistently reject non-compliant workloads across all nodes and namespaces.
- ✗
Set up a NetworkPolicy to block traffic from other registries
Why it's wrong here
NetworkPolicy works at the network layer (L3/L4) and governs traffic between pods and to external IPs/CIDRs using selectors and ports. It does not understand or evaluate the image reference used by a pod, and image pulls are performed by the kubelet from the node, not from inside the pod's network namespace. Therefore, a NetworkPolicy cannot prevent a pod from running an image from an unapproved registry; it only restricts connectivity, not workload admission.
- ✗
Configure an ImagePolicyWebhook
Why it's wrong here
ImagePolicyWebhook is an admission controller that calls an external HTTP service to make image-related admission decisions, and it is commonly deployed to verify image signatures or check for known vulnerabilities, not to simply allowlist a registry. While you could theoretically write a custom backend that rejects non-approved registries, that is building a custom policy engine from scratch. The standard, declarative way to enforce registry allowlisting is a policy engine like OPA/Gatekeeper, not a signature-verification hook.
- ✗
Modify the kubelet configuration to only pull from a specific registry
Why it's wrong here
The kubelet is the node agent responsible for pulling images and running containers, but it has no configuration option to restrict which registries may be used; it simply pulls whatever image reference is sent in the Pod spec. Editing kubelet config per node would be inconsistent, non-centralized, and still bypassable because the kubelet will accept any valid image if it can be pulled. Registry allowlisting must be implemented at the admission stage, before the Pod spec is persisted or dispatched to nodes.
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 →
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. An OPA/Gatekeeper constraint is configured to allow only images from 'trusted-registry.io'. A pod is created with image 'trusted-registry.io/app:v1' but is denied. Which is the MOST likely cause?
hard- A.The constraint is only applied in the default namespace
- B.The image tag is not pinned to a digest
- C.The image is not signed
- ✓ D.The constraint uses regex and the image does not match the pattern
Why D: The most likely cause is that the OPA/Gatekeeper constraint uses a regex pattern to match allowed image registries, and the image 'trusted-registry.io/app:v1' does not match that pattern. Gatekeeper constraints often rely on Rego rules that check image strings against regex patterns; if the pattern is too restrictive or incorrectly defined (e.g., requiring a trailing slash or specific path), valid images can be denied. This is a common misconfiguration where the regex does not account for the full image reference format.
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.