CKAD Practice Question: Application Environment, Configuration and Security
A Pod specification includes: securityContext: { runAsNonRoot: true }. The container image runs as root by default. What will happen when the Pod is created?
⚠ Common exam trap
Candidates often assume Kubernetes will automatically adjust the container user to non-root when `runAsNonRoot` is set, but in reality, Kubernetes only validates the existing user and rejects the Pod if it's root—you must explicitly set `runAsUser` to a non-zero value if the image runs as root.
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
✓
The Pod will not start; the kubelet will reject it because the container tries to run as root
When a Pod specifies `runAsNonRoot: true` in its `securityContext`, the kubelet verifies that the container's user ID is non-zero (non-root) before starting the container. If the container image runs as root by default (UID 0), the kubelet will reject the Pod, and it will remain in a `ContainerCreating` or `CrashLoopBackOff` state with an error like 'container has runAsNonRoot and image will run as root'. This is a security enforcement mechanism that prevents privileged execution.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The Pod will start and immediately be OOMKilled
Why it's wrong here
OOMKilled is a Linux kernel response to a container exceeding its memory limit, and it only occurs after a process is already running. With runAsNonRoot: true and a container image that runs as root, the kubelet refuses to launch the container before any process exists, so there is no memory usage to trigger OOMKilled. The failure is a security validation error, not a resource exhaustion error.
- ✗
The Pod will run but with a warning
Why it's wrong here
Security constraints in a Pod's securityContext are mandatory; the kubelet does not produce warnings and then proceed. If runAsNonRoot is true and the image runs as root, the kubelet fails container creation, and the Pod stays in a Pending state or enters CrashLoopBackOff with an event explaining the violation. There is no "warning" mode for this check; it is a hard fail.
- ✓
The Pod will not start; the kubelet will reject it because the container tries to run as root
Why this is correct
runAsNonRoot instructs the kubelet to verify that the container's effective user is not UID 0 before starting it. When the container image specifies root as its user, the kubelet returns an error and refuses to start the container, leaving the Pod in a failed or Pending state with a container creation failure event. This prevents a root process from ever executing.
- ✗
The Pod will run successfully because K8s overrides the user to non-root
Why it's wrong here
runAsNonRoot does not automatically set a non-root user; it only verifies that the image's configured user is already non-root. If the image runs as root, the kubelet rejects the container—it does not silently override the user to satisfy the policy. To actually run as non-root you must explicitly set runAsUser to a non-zero UID or use an image built with a non-root USER; otherwise the Pod will not start.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 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 CKAD 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 CKAD exam.