CKS Supply Chain Security Practice Question
Which TWO are recommended practices for securing a CI/CD pipeline that builds container images? (Select two.)
⚠ Common exam trap
The CKS exam often tests the distinction between build-time security (scanning, signing) and runtime security (least privilege, secret injection), and the trap here is that candidates may think storing secrets as environment variables is acceptable because it works, ignoring that they persist in image layers and are accessible via `docker history`.
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
✓
Scan images for vulnerabilities before pushing
Option B is correct because scanning images for vulnerabilities before pushing them to a registry catches known CVEs in OS packages and application dependencies early, preventing flawed artifacts from ever entering the pipeline's downstream stages or production. Option D is correct because signing images after building (e.g., with Docker Content Trust/Notary or Sigstore cosign) provides cryptographic provenance and integrity, letting admission controllers verify that only trusted, unmodified images are deployed. Option A is wrong because running containers as root violates least-privilege and dramatically increases the impact of a container escape; images should use a non-root USER. Option C is wrong because baking secrets into image layers as environment variables exposes them to anyone who can pull or inspect the image; secrets belong in a vault or secret manager injected at runtime. Option E is wrong because the mutable 'latest' tag makes builds non-reproducible and can silently pull a different, potentially compromised image; immutable, versioned tags or digests should be used.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run containers as root for compatibility
Why it's wrong here
Root inside a container weakens isolation, so a breakout grants host-level privileges. It is tempting because many legacy images assume root and run without permission errors, and would be correct only for trusted, throwaway builds, not hardened pipelines where a non-root user is required.
- ✓
Scan images for vulnerabilities before pushing
Why this is correct
Scanning images for vulnerabilities before pushing catches known CVEs in dependencies and base layers while the artefact is still inside the pipeline, preventing flawed images from reaching the registry. This satisfies the requirement to gate builds on security findings before publication.
- ✗
Store secrets in the image as environment variables
Why it's wrong here
Environment variables are readable in image metadata and container inspection, exposing credentials to anyone pulling the image. It is tempting because env vars are the simplest way to inject configuration at build time, and would be correct for non-sensitive settings rather than secrets, which belong in a vault or mounted secret.
- ✓
Sign images after building
Why this is correct
Signing images after building with tools such as Cosign creates cryptographic provenance, letting admission controllers verify authenticity and integrity before deployment. This satisfies the pipeline requirement to establish trust in artefacts, preventing tampered or unauthorised images from being deployed.
- ✗
Use the 'latest' tag for simplicity
Why it's wrong here
The latest tag is mutable, so builds are non-reproducible and a compromised push silently changes what deploys. It is tempting because it avoids version bookkeeping, and would be correct for local experimentation, not production pipelines where immutable digest pinning is required.
Go deeper
Related to this question
Learn chapter
Microservice Vulnerabilities: Secure Deployments and Runtime
Key term
Admission Controllers
Admission controllers are plugins that intercept and process requests to the Kubernetes API server after authentication and authorization, but before the request is persisted, allowing policies to be enforced on objects being created, modified, or deleted.
Key term
Image Signing and Verification
Image signing and verification is the process of digitally signing a container image to prove its origin and integrity, and then checking that signature before using the image to ensure it was not tampered with.
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.