CKS Minimize Microservice Vulnerabilities Practice Question
An administrator wants to enforce a policy that all containers must drop ALL capabilities and not allow privilege escalation. Which YAML snippet correctly implements this requirement in a PodSecurityPolicy-like manner using a security context? (Note: PodSecurityPolicy is deprecated; consider using a ValidatingAdmissionPolicy or OPA/Gatekeeper, but for this question choose the correct security context fields.)
⚠ Common exam trap
The exam often tests the distinction between `privileged: false` (which only disables privileged mode) and `allowPrivilegeEscalation: false` (which actively prevents privilege escalation), leading candidates to incorrectly choose option A.
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
✓
securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }
It sets `allowPrivilegeEscalation: false` to prevent privilege escalation (e.g., via setuid binaries) and `capabilities: { drop: ["ALL"] }` to remove all Linux capabilities from the container. This combination enforces the requirement that containers start with no extra privileges and cannot gain more, aligning with the principle of least privilege in PodSecurityPolicy-like enforcement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
securityContext: { privileged: false, capabilities: { drop: ["ALL"] } }
Why it's wrong here
Setting privileged: false is the default in Kubernetes and is effectively a no-op; it does not set the allowPrivilegeEscalation field, which controls whether a process can gain more privileges than its parent, such as through setuid binaries. The kernel's default behavior for container processes is to allow privilege escalation unless explicitly disabled, so even with a drop of all capabilities, the security context remains incomplete. Without allowPrivilegeEscalation: false, the container could still execute a setuid executable to elevate privileges. Therefore, merely setting privileged to false fails to enforce the desired restriction.
- ✓
securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }
Why this is correct
This configuration correctly sets both the allowPrivilegeEscalation field to false, which prevents the container process from gaining additional privileges through mechanisms like setuid executables or non-default capability handling, and drops all Linux capabilities via the capabilities.drop field, so the container begins with zero capabilities. Dropping ALL ensures that even if a vulnerability allows arbitrary code execution, the attacker cannot acquire kernel capabilities to compromise the host. This combination aligns with the Kubernetes Pod Security Standards restricted profile, which requires both settings to be explicitly configured. It is the only option that fully satisfies the policy's requirement.
- ✗
securityContext: { allowPrivilegeEscalation: false, capabilities: { add: ["ALL"] } }
Why it's wrong here
Adding ALL to capabilities is the direct opposite of dropping ALL; it bestows every Linux capability on every process in the container, including CAP_SYS_ADMIN and CAP_NET_ADMIN, which are typically reserved for the host root. While allowPrivilegeEscalation: false is set, having all capabilities means the process can perform privileged operations without needing to escalate, so the restriction is effectively meaningless. This configuration would make the container as privileged as one running with privileged: true, violating the intended least-privilege policy and greatly increasing the attack surface. The policy requires capabilities to be dropped, not added.
- ✗
spec: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }
Why it's wrong here
The placement of these fields is invalid: allowPrivilegeEscalation and capabilities are nested under securityContext, not directly under the spec key. In the pod or container schema, the correct structure is container.securityContext.allowPrivilegeEscalation and container.securityContext.capabilities, so a top-level spec field would be ignored or rejected by the Kubernetes API. Even if the YAML were interpreted, spec does not contain these keys, meaning the security settings would not be applied to the container. This configuration fails because it mislocates the policy fields rather than applying them at the container security context level.
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.