CKS Supply Chain Security Practice Question
A development team uses a custom container image for their application, built from a base image that includes multiple CVEs. The security team requires that no container runs with known critical vulnerabilities. Which approach best ensures that only images with no critical vulnerabilities are deployed in production?
⚠ Common exam trap
CNCF often tests the distinction between shift-left security (preventing vulnerabilities at build time) versus runtime enforcement (admission controllers), and the trap here is that candidates choose admission controllers (Option A) because they seem to block vulnerable images, but they fail to realize that the image must already exist in the registry and may have been built with vulnerabilities, whereas CI/CD scanning prevents the image from being created in the first place.
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
✓
Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.
Integrating an image scanner like Trivy into the CI/CD pipeline ensures that any image with critical vulnerabilities is blocked before it is even built or pushed to a registry. This shift-left approach prevents vulnerable images from ever reaching the production environment, aligning with the security team's requirement to deploy only images with no critical vulnerabilities.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure a Kubernetes admission controller (e.g., Kyverno) to reject pods using images with critical vulnerabilities.
Why it's wrong here
An admission controller such as Kyverno operates at the Kubernetes API layer, after the image has already been built and pushed; it can only reject a Pod creation request based on metadata such as the image reference, not prevent the unsafe artifact from existing in the registry. To make an informed decision it would still depend on an external scanner's report, and a misconfigured or non-enforced policy leaves a gap. This positions admission control as a defense-in-depth control rather than the primary prevention mechanism for vulnerable images.
- ✗
Scan the base image before building the application image.
Why it's wrong here
Scanning the base image alone ignores vulnerabilities introduced in the application layer, such as insecure npm or pip dependencies added during build, custom code weaknesses, or artifacts downloaded by RUN instructions. A base image may appear clean at one point, but the final image can still contain critical CVEs from those later build stages. The scan must target the fully assembled image to reflect the actual runtime artifact.
- ✓
Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.
Why this is correct
Integrating a scanner like Trivy into the CI/CD pipeline creates a build-time quality gate: it scans the final image after all layers are assembled and fails the pipeline if critical vulnerabilities are found, so vulnerable images are never pushed to the container registry. This shift-left approach automates prevention at the earliest practical stage and provides a clear signal to developers before the image reaches deployment. This is the recommended primary control for supply chain security.
- ✗
Manually review vulnerability reports after the image is deployed.
Why it's wrong here
Manually reviewing vulnerability reports after deployment is reactive and leaves a vulnerable image running in production during the review window; there is no automatic block and the process depends on human timeliness and diligence. By the time the report is read, the workload may already be exposed, requiring an emergency remediation or rollback. This approach cannot stop a vulnerable image from being deployed and should only supplement automated gates, not replace them.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 114-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.