CKS Cluster Hardening Practice Question
A pod is failing to start with: 'Error: container has runAsNonRoot and image will run as root'. The pod spec sets securityContext.runAsNonRoot: true. The container image is 'nginx:latest' which runs as root. Which change allows the pod to run while maintaining security?
⚠ Common exam trap
CNCF often tests the distinction between pod-level and container-level securityContext settings, and the trap here is that candidates might think removing `runAsNonRoot` or using a deprecated PSP is acceptable, rather than directly setting a non-root user ID in the container's securityContext.
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 runAsUser: 1000 in the container securityContext
Setting `runAsUser: 1000` in the container's securityContext overrides the default user (root) in the image, ensuring the container process runs as a non-root user (UID 1000). This satisfies the `runAsNonRoot: true` constraint at the pod level, which requires that the container's user ID is non-zero, while still maintaining security by not running as root.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove runAsNonRoot: true
Why it's wrong here
Removing runAsNonRoot: true merely disables the security check, but the underlying container still runs as root (UID 0). This relaxes the workload's security posture and violates Pod Security Standards, which require containers to run as non-root in most production namespaces. The correct action is to make the container actually run as a non-root user, not to bypass the validation.
- ✗
Add a PodSecurityPolicy that allows root
Why it's wrong here
PodSecurityPolicy is deprecated and scheduled for removal in newer Kubernetes versions, so relying on it is not a forward-looking solution. Moreover, a PSP that allows root does not change the container's effective UID; if runAsNonRoot: true is set, the kubelet or container runtime rejects the pod regardless of any policy. This option fails to address the direct failure and introduces an outdated admission control mechanism.
- ✓
Set runAsUser: 1000 in the container securityContext
Why this is correct
Setting runAsUser: 1000 in the container's securityContext explicitly forces the container process to run with a non-zero UID, which satisfies the runAsNonRoot: true validation. The kubelet checks that the effective UID of the container is not 0; by fixing the UID to 1000, the check passes while maintaining a secure, non-root execution model. This is the minimal, direct, and security-preserving fix.
- ✗
Use a mutating webhook to change the image
Why it's wrong here
A mutating webhook could modify the image or pod spec at admission time, but it requires deploying and configuring a separate webhook server, which is heavy infrastructure for a single failing pod. It is not an immediate fix, and it introduces unacceptable complexity for what is simply a missing securityContext field. Moreover, the webhook would need to be cluster-wide and might not even be installed, making this approach impractical in most real-world scenarios.
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.