CKS Supply Chain Security Practice Question
A Kubernetes cluster has Kyverno installed. You want to enforce that all container images come from a trusted registry 'trusted-registry.example.com'. Which Kyverno policy rule type would you use?
⚠ Common exam trap
Many exam-takers confuse the `validate.deny` syntax (which does not exist) with the correct approach of using a `validate` rule containing a `deny` condition, often because other tools like OPA/Gatekeeper use a `deny` rule type directly.
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
✓
validate with a deny condition
Kyverno's `validate` rule type with a `deny` condition is specifically designed to reject resources that violate a policy. In this case, the policy would deny any Pod that references an image not matching the pattern `trusted-registry.example.com/*`, enforcing the trusted registry requirement at admission time.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
validate with a deny condition
Why this is correct
Using a Kyverno validate rule with a deny condition allows you to enforce policy by rejecting any Pod that does not meet the specified criteria, such as pulling images from unauthorized registries. The deny condition is evaluated against the resource; if the condition is true, admission is blocked with a clear message. This is the canonical way to express negative constraints in Kyverno, as it directly validates the existing image field without altering it.
- ✗
mutate
Why it's wrong here
A mutate rule in Kyverno rewrites or patches resources, such as adding labels, injecting sidecars, or replacing image prefixes. It does not stop non-compliant images; it changes them, which would hide the violation rather than enforce the policy. Since you want to deny unauthorized images outright, mutating the image would not achieve the intended admission control.
- ✗
validate.deny
Why it's wrong here
Although Kyverno has a `deny` key within a `validate` rule, `validate.deny` is not a top-level or separate rule type in the Kyverno policy schema. The official structure is `apiVersion: kyverno.io/v1` `kind: ClusterPolicy` with `spec.rules[].validate.deny` — but you still declare the rule as type `validate`, not `validate.deny`. Trying to use `validate.deny` as a literal rule type will cause the policy to be invalid or ignored.
- ✗
generate
Why it's wrong here
A generate rule creates additional Kubernetes resources automatically when a trigger resource is created or updated, such as creating a NetworkPolicy whenever a Namespace matches a label. It has no effect on admission validation of the triggering Pod's image, because generate runs post-admission and does not evaluate or reject the resource. Therefore it cannot enforce a deny-list of registries.
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
2 more ways 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 Kubernetes cluster has Kyverno installed. A policy requires that all images come from a trusted registry 'trusted.example.com'. A Deployment uses the image 'nginx:latest'. When the Deployment is created, it is blocked. What Kyverno policy action is being used?
medium- ✓ A.validate with failureAction: enforce
- B.audit
- C.mutate
- D.generate
Why A: Kyverno's `validate` policy with `failureAction: enforce` is the mechanism that blocks resource creation when validation rules are violated. In this scenario, the policy checks that the image comes from `trusted.example.com`, and since `nginx:latest` does not match, the policy actively denies the Deployment, which is the behavior of `enforce` mode.
Variation 2. A pod is running in a namespace that has a Kyverno policy requiring all images to come from a trusted registry. The pod is using an image from an untrusted registry. What will happen when the pod is created?
medium- A.The pod will be created but immediately terminated
- ✓ B.The pod creation will be rejected with an admission error
- C.The pod will be created and run successfully
- D.The pod will be created but the image will be replaced with a trusted one
Why B: Kyverno operates as an admission controller in Kubernetes. When a pod is created, the Kyverno admission webhook intercepts the creation request and evaluates it against the configured policies. If the policy requires all images to come from a trusted registry and the pod uses an image from an untrusted registry, the admission webhook rejects the request, preventing the pod from being created. This results in an admission error, not a post-creation termination.
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.