CKS Minimize Microservice Vulnerabilities Practice Question
An admin runs 'kubectl get pod web -o yaml' and sees the following security context. Which setting prevents privilege escalation?
⚠ Common exam trap
A common misconception is that dropping all capabilities or running as non-root alone prevents privilege escalation, but the kernel's `no_new_privs` flag (set by `allowPrivilegeEscalation: false`) is the only direct control against setuid-based escalation.
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
✓
allowPrivilegeEscalation: false
`allowPrivilegeEscalation: false` directly prevents a process from gaining more privileges than its parent process, such as through setuid binaries or gaining root capabilities. This setting is enforced by the kernel via the `no_new_privs` flag, which blocks privilege escalation attempts regardless of other security context settings.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
allowPrivilegeEscalation: false
Why this is correct
Setting allowPrivilegeEscalation to false blocks the container process from gaining more privileges than its parent, disabling setuid binaries and preventing escalation via no_new_privs. This directly satisfies the stem's requirement to identify the setting that stops privilege escalation.
- ✗
Both B and C
Why it's wrong here
Both B and C together still do not prevent privilege escalation because neither sets the no_new_privs flag. runAsNonRoot only forces a non-root UID, and dropping all capabilities removes most kernel capability sets, but the process can still execute a setuid-root binary or leverage file capabilities inherited from the container image to gain root privileges. Since escalation can occur without the process currently possessing effective capabilities, combining these two controls does not directly block the escalation path.
- ✗
runAsNonRoot: true
Why it's wrong here
runAsNonRoot: true ensures the container starts with a UID other than 0, which is a useful baseline hardening step. However, privilege escalation is not solely dependent on the initial UID; a non-root process can still invoke a binary with the setuid bit set or use a Linux capability like CAP_SETUID to alter its own UID and become root. This setting does not activate no_new_privs, so it leaves escalation vectors open and is therefore incorrect for directly preventing privilege escalation.
- ✗
capabilities: drop: [ALL]
Why it's wrong here
capabilities: drop: [ALL] removes all Linux capabilities from the container's permitted, effective, and inheritable sets, curtailing many powerful kernel operations. However, privilege escalation can still proceed through SUID programs, file capabilities assigned to executables inside the container, or kernel vulnerabilities that require no capabilities at all. Because this setting does not set the no_new_privs attribute on the process, it does not directly block the gaining of new privileges, making it insufficient as a standalone escalation prevention control.
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.