Match each container security context setting to its effect.
Drag a concept onto its matching description — or click a concept then click the description.
Prevents processes from gaining more privileges than their parent
Ensures the container runs with a user ID that is not 0 (root)
Mounts the container's root filesystem as read-only
Drops all Linux capabilities, minimizing kernel privileges
Disables privileged mode, preventing access to host devices
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
runAsNonRoot: Prevents the container from running as root
Correct matches: runAsNonRoot forces non-root execution; runAsUser sets a specific UID. Common confusion is swapping these effects. Other settings like privileged and readOnlyRootFilesystem also enforce least privilege.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
runAsNonRoot: Prevents the container from running as root
Why this is correct
When set to true, the kubelet verifies that the container's image configuration does not declare a UID of 0 (root) and that no explicit runAsUser of 0 is supplied. If the container would start as root, the kubelet refuses to launch it, thereby enforcing a non-root identity at the process level. This complements SecurityContext policies by providing a fail-closed guarantee that the workload cannot inherit a root UID from the image.
runAsNonRoot: Specifies the user ID (UID) to run the container
Why it's wrong here
This incorrectly attributes the behavior of runAsUser. runAsNonRoot does not take a numeric UID value as its input; it accepts a boolean (true/false) that toggles root enforcement. To explicitly choose a UID, you configure runAsUser with an integer UID, which is a separate field in the same SecurityContext. Confusing these fields leads to invalid manifests and a misunderstanding of the admission-time validation.
runAsUser: Specifies the user ID (UID) to run the container
Why this is correct
runAsUser takes an integer value, e.g., 1000, and sets the primary user ID of the container process to that UID. This overrides any USER directive specified in the container image, giving the cluster operator direct control over which UID the process executes under. It is a common way to ensure workloads run with a least-privilege account that is defined at deployment time rather than relying on the image author.
runAsUser: Prevents the container from running as root
Why it's wrong here
This wrongly assigns the root-prevention capability to runAsUser. runAsUser only sets the UID; it does not explicitly forbid running as root, because if you set runAsUser to 0, the container will run as root. Preventing root is the purpose of the boolean runAsNonRoot field, which operates independently of runAsUser and causes the container to be rejected if its effective UID would be 0.
Go deeper
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 →
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.