CKS Minimize Microservice Vulnerabilities Practice Question
Which TWO of the following are valid ways to enforce that a container runs as a non-root user?
⚠ Common exam trap
The CKS exam often tests the misconception that PodSecurityPolicy (PSP) is still a valid option, but it has been removed since Kubernetes v1.25, so candidates must know that Kyverno or OPA/Gatekeeper policies are the modern replacements for enforcing non-root execution.
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 runAsNonRoot: true in the pod securityContext
Setting `runAsNonRoot: true` in the pod's `securityContext` explicitly instructs the kubelet to validate that the container's user ID is not 0 (root) before starting the container. If the container attempts to run as root, the kubelet will refuse to start it, providing a strong enforcement mechanism at the Kubernetes level.
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 the container image to use a root user
Why it's wrong here
Configuring the container image to use a root user explicitly sets the effective UID to 0 for every process in the container. This directly contradicts the requirement to enforce non-root execution, as root privileges are granted by default. This is not a policy or enforcement mechanism; it merely ensures the container runs as the most privileged user, making the workload unsafe and non-compliant.
- ✓
Set runAsNonRoot: true in the pod securityContext
Why this is correct
Setting `runAsNonRoot: true` in the pod securityContext is a native Kubernetes admission check that forces the container's effective user ID to be non-zero. When this is set, the kubelet will verify the image's user configuration, and if the container image is set to run as root (UID 0), the pod creation is rejected. To pass this check, either the image must define a non-root `USER` directive or the pod must explicitly set a non-zero `runAsUser`. This is the fundamental built-in method for enforcing non-root containers.
- ✗
Use a PodSecurityPolicy (PSP)
Why it's wrong here
PodSecurityPolicy (PSP) was an admission controller that could enforce non-root and other security constraints, but it has been deprecated since Kubernetes 1.21 and completely removed in v1.25. In current Kubernetes releases, the PSP API object no longer exists, so referencing it as a valid enforcement method is obsolete and would fail in a real cluster. Its official replacement is Pod Security Admission (PSA), which uses predefined standardized profiles, or external policy engines such as Kyverno or OPA Gatekeeper.
- ✓
Use a Kyverno policy to validate runAsNonRoot
Why this is correct
Kyverno is a dynamic admission controller that automatically applies policies to Kubernetes resources as they are created or updated. By writing a ClusterPolicy that requires `securityContext.runAsNonRoot: true` in pod specifications, Kyverno can reject any pod that doesn't comply, with the ability to mutate the resource to inject the setting. This provides a flexible, modern enforcement mechanism that works on any Kubernetes cluster without needing built-in PSP or PSA policies.
- ✗
Set runAsUser: 0 in the container securityContext
Why it's wrong here
Setting `runAsUser: 0` in the container's securityContext explicitly sets the process's UID to 0, which is the root user. This is the exact opposite of enforcing non-root execution, as it forces the container to run with full root privileges. This configuration does not enforce any security restriction; rather, it is a common misconfiguration that exposes the container to serious security risks.
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 →
Same concept, more angles
2 more ways this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which field must be set in a Pod's security context to prevent the container from running as the root user?
easy- A.runAsUser: 1000
- B.readOnlyRootFilesystem: true
- C.allowPrivilegeEscalation: false
- ✓ D.runAsNonRoot: true
Why D: The `runAsNonRoot: true` field in a Pod's security context enforces that the container's entrypoint cannot run as UID 0 (root). If the container image attempts to run as root, the container runtime (e.g., containerd) will reject the container from starting, ensuring compliance with the principle of least privilege and mitigating root-based container escapes.
Variation 2. Which TWO of the following are valid Pod Security Context settings to harden a container? (Select 2)
medium- A.privileged: true
- B.runAsUser: 0
- ✓ C.runAsNonRoot: true
- ✓ D.readOnlyRootFilesystem: true
- E.allowPrivilegeEscalation: true
Why C: Setting `runAsNonRoot: true` in the Pod Security Context forces the container to run with a user ID (UID) other than 0 (root). This is a fundamental hardening measure that prevents an attacker who gains code execution inside the container from having root privileges, thereby limiting the blast radius of a compromise. It is a recommended practice in the CIS Benchmark for Kubernetes and directly addresses the principle of least privilege.
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.