CKS Minimize Microservice Vulnerabilities Practice Question
A developer reports that a pod fails to start with the error 'container has runAsNonRoot and image will run as root'. The pod spec includes securityContext.runAsNonRoot: true but does not specify runAsUser. The container image's Dockerfile does not set a USER instruction. Which change should you make to the pod spec to resolve the error while still enforcing non-root execution?
⚠ Common exam trap
The trap here is thinking that allowPrivilegeEscalation or readOnlyRootFilesystem can satisfy runAsNonRoot, but only an explicit non-root runAsUser or a non-root USER in the image resolves the error.
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
✓
Set securityContext.runAsUser to a numeric UID greater than 0.
The runAsNonRoot check fails when the effective UID is 0. Setting a numeric runAsUser greater than 0 provides a non-root UID, satisfying the policy. Other security context fields like privileged, allowPrivilegeEscalation, and readOnlyRootFilesystem do not change the user ID and therefore do not fix this error.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set securityContext.readOnlyRootFilesystem to true.
Why it's wrong here
readOnlyRootFilesystem mounts the container's root filesystem as read-only, which is a good security practice but unrelated to the user ID. The container would still try to run as root and fail the runAsNonRoot check. This field does not address the root cause of the error, which is the absence of a non-root UID.
- ✓
Set securityContext.runAsUser to a numeric UID greater than 0.
Why this is correct
When runAsNonRoot is true and the image would run as root (UID 0), the kubelet rejects the container. Specifying a numeric runAsUser greater than 0 tells the runtime to run the process as that non-root UID, satisfying the policy. This is the correct fix because it both resolves the error and maintains the non-root enforcement requirement.
- ✗
Set securityContext.allowPrivilegeEscalation to false.
Why it's wrong here
allowPrivilegeEscalation controls whether a process can gain more privileges than its parent, but it does not set the user ID. The container would still attempt to run as root, triggering the same runAsNonRoot error. This field is a useful hardening measure but not a solution for the missing non-root UID.
- ✗
Set securityContext.privileged to true.
Why it's wrong here
Setting privileged to true gives the container full host access and bypasses many security restrictions, but it does not resolve the runAsNonRoot error. In fact, privileged containers often run as root, which would violate the non-root policy. This change would weaken security and still fail the admission or kubelet check.
Visual reference
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.