CKS System Hardening Practice Question
A pod in namespace 'secure' has the following securityContext: securityContext: runAsNonRoot: true runAsUser: 1000 capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"] The pod fails to start. The namespace is enforced with the 'restricted' Pod Security Standard. What is the most likely reason?
⚠ Common exam trap
CNCF often tests the nuance that the restricted policy forbids adding any capabilities, even if they are considered 'safe' or commonly used, and candidates may mistakenly think that dropping all capabilities is the violation or that runAsUser: 1000 is the issue.
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 adds capabilities, which is not allowed by the restricted policy.
The 'restricted' Pod Security Standard (PSS) explicitly prohibits adding any capabilities beyond the default set, which is empty. Since the pod's securityContext adds the NET_BIND_SERVICE capability, it violates the restricted policy, causing the pod to fail to start.
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 adds capabilities, which is not allowed by the restricted policy.
Why this is correct
The restricted Pod Security Standard (PSS) explicitly forbids any capability additions beyond the default set; a container that adds NET_BIND_SERVICE (or any other Linux capability) violates the 'capabilities' constraint, which requires that the effective capability set match the default and that all capabilities be dropped. Since this pod adds a capability rather than merely retaining defaults, it fails the restricted profile's validation and is rejected.
- ✗
The runAsUser is set to 1000, which is not allowed by the restricted policy.
Why it's wrong here
The restricted policy does not validate the numeric user ID beyond requiring that it is non-root; UID 1000 is a perfectly acceptable non-root user. The policy's requirement is runAsNonRoot: true, which can be satisfied by any UID other than 0, so setting runAsUser to 1000 actually helps meet compliance rather than violating it.
- ✗
The pod sets runAsNonRoot to true, which is not allowed by the restricted policy.
Why it's wrong here
Setting runAsNonRoot to true is a mandatory precondition for the restricted profile, which explicitly requires this field to ensure containers cannot escalate to root. This configuration is not only allowed but is one of the baseline checks that the policy enforces; a pod missing this setting would be the one rejected, not a pod that includes it.
- ✗
The pod drops all capabilities, which is not allowed by the restricted policy.
Why it's wrong here
Dropping all capabilities is the exact behavior the restricted policy demands: it specifies that the container's capability set must be emptied, leaving no effective capabilities. Thus, an action to drop all capabilities is a compliance measure, not a violation; the policy would fail a pod that retains any capabilities, so this pod is actually more aligned with the restricted profile.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.