CKS Supply Chain Security Practice Question
Which of the following is a best practice when writing a Dockerfile for a containerized application?
⚠ Common exam trap
A common pitfall is assuming that using the 'latest' tag is safe because it gets security patches automatically, but in reality, 'latest' is mutable and can introduce unexpected vulnerabilities or break reproducibility, which is critical for supply chain security in Kubernetes environments.
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 a minimal base image such as distroless or alpine
Using a minimal base image like distroless or alpine reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could be exploited. This aligns with the principle of least privilege and minimizes the number of Common Vulnerabilities and Exposures (CVEs) in the container, which is critical for supply chain security in Kubernetes environments.
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 the application as the root user for file permissions
Why it's wrong here
Running as root grants full privileges, so any container compromise yields host-level access, violating least privilege. The correct approach creates a non-root USER. Root is tempting because it sidesteps permission errors during builds, but that convenience is exactly the risk Kubernetes security contexts and Pod Security Standards restrict.
- ✓
Use a minimal base image such as distroless or alpine
Why this is correct
A minimal base image such as distroless or alpine reduces the attack surface by excluding shells, package managers and unnecessary libraries, directly satisfying the CKS requirement to minimise vulnerabilities in the container image. Distroless removes the package manager entirely, while alpine uses musl libc and a smaller package set.
- ✗
Hardcode credentials in the Dockerfile for convenience
Why it's wrong here
Hardcoded credentials persist in image layers and registry history, exposing secrets to anyone who pulls the image. The correct practise injects secrets at runtime via Kubernetes Secrets or mounted volumes. Hardcoding tempts because it avoids configuration steps, yet it breaches credential management and rotation requirements central to CKS objectives.
- ✗
Use the latest tag for the base image to get the newest features
Why it's wrong here
The latest tag is mutable, so builds become non-reproducible and may silently pull vulnerable or breaking versions. Pinning a specific digest or version tag ensures deterministic, auditable images. Latest appeals for receiving newest features automatically, but that undermines supply-chain integrity and rollback reliability in production clusters.
Go deeper
Related to this question
About these practice questions
One of 845 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 →
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.