CKS Supply Chain Security Practice Question
What is the purpose of using a non-root user in a container image?
⚠ Common exam trap
CKS often tests the misconception that Kubernetes mandates non-root containers, but the trap is that it is a security best practice, not a hard requirement, and the default behavior is to run as root unless explicitly configured.
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
✓
To reduce the attack surface and limit potential damage if the container is compromised
Running containers as a non-root user reduces the attack surface by ensuring that even if an attacker exploits a vulnerability in the application, they do not gain root privileges inside the container. This limits the potential damage, such as modifying system binaries, escaping the container via kernel exploits, or accessing host resources. In Kubernetes, this is enforced by setting `securityContext.runAsNonRoot: true` or specifying a non-root user in the Dockerfile with `USER` directive.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
To reduce the attack surface and limit potential damage if the container is compromised
Why this is correct
Running as non-root removes the container's default privileged UID 0, so a process escaping the application cannot write to root-owned paths or perform privileged kernel operations. This limits blast radius if compromised, satisfying the stem's damage-limitation requirement.
- ✗
To improve performance
Why it's wrong here
User IDs do not govern CPU, memory or I/O scheduling, so non-root has no performance effect; container runtime and cgroup limits do. Non-root exists to reduce privilege if the container is compromised, restricting what an attacker can do inside it.
- ✗
To comply with Kubernetes requirements
Why it's wrong here
Kubernetes imposes no requirement for non-root container users; pods run as root by default unless a securityContext specifies otherwise. The option is tempting because Pod Security Standards' restricted profile and many admission policies do mandate runAsNonRoot, so compliance is a genuine driver in hardened clusters — but that is policy, not the image-level purpose asked about.
- ✗
To allow the container to bind to privileged ports
Why it's wrong here
Binding to ports below 1024 requires the CAP_NET_BIND_SERVICE capability or root; running as non-root removes that privilege rather than granting it. Non-root is chosen to limit the blast radius of a container compromise, not to enable privileged port binding.
Go deeper
Related to this question
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.