CKS Supply Chain Security Practice Question
Which TWO are best practices for Dockerfile security? (Select 2)
⚠ Common exam trap
The CKS exam often tests the misconception that environment variables are a safe way to pass secrets to containers, but in reality they are easily leaked through Docker metadata and runtime introspection.
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 non-root user
Running containers as a non-root user reduces the risk of privilege escalation attacks. If an attacker compromises the container, they will not have root privileges, limiting their ability to modify system files or escape the container. This is enforced by using the USER directive in the Dockerfile to specify a non-root UID (e.g., USER 1001).
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 a non-root user
Why this is correct
Running as non-root limits the impact of a breach. Containers share the host kernel, so a root process escaping the container can gain root on the host. In the Dockerfile, use the USER directive to switch to an unprivileged user, and in Kubernetes set securityContext.runAsUser/runAsNonRoot. This ensures that even if the application is compromised, the attacker only has the privileges of that user, not root.
- ✓
Use a minimal base image (distroless)
Why this is correct
Minimal images have fewer components and fewer vulnerabilities. Distroless images contain only the application and its runtime dependencies, with no package manager, shell, or system utilities. This drastically reduces the number of potential CVEs and entry points for an attacker. However, debugging becomes harder, so use an ephemeral debug container or a similar strategy for troubleshooting.
- ✗
Store secrets in environment variables
Why it's wrong here
Storing secrets in environment variables is insecure because they can be read by any process inside the container, shown in `docker inspect`, or leaked through application error logs. Environment variables set with ENV in a Dockerfile also get baked into the image layers, making them recoverable from the image. Use Kubernetes Secrets or an external vault with proper encryption, RBAC, and rotation instead.
- ✗
Install SSH server for debugging
Why it's wrong here
Installing an SSH server in a container is a bad practice because it adds a persistent network service that must be secured, exposing a new attack surface. It also requires managing keys and increases the risk of unauthorized access. For debugging, use `kubectl exec` or an ephemeral debug container with the necessary tools, without compromising the runtime image.
- ✗
Run the container as root
Why it's wrong here
Running a container as root is risky because a vulnerability in the application then gives the attacker root privileges inside the container, and due to the shared host kernel, this can escalate to host compromise. The container runtime has defenses like user namespaces, but they are not a substitute for least privilege. Drop all capabilities, set read-only root filesystem, and run as non-root to reduce this risk.
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 →
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.