CCSP Cloud Application Security Practice Question
A company is deploying a containerized application on Kubernetes. The security team requires that containers run with the least privilege, and that any attempt to escalate privileges within a container is blocked. Which Kubernetes security context setting should be applied to the pod specification?
⚠ Common exam trap
ISC2 often tests the distinction between preventing privilege escalation and other security controls like dropping capabilities or running as non-root, leading candidates to confuse capability removal with escalation prevention.
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
Setting `allowPrivilegeEscalation: false` in the pod's security context directly blocks any attempt by a container process to gain more privileges than its parent process, such as through setuid binaries or syscalls like `setuid()`. This satisfies the requirement to prevent privilege escalation within the container, aligning with the least privilege principle.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
runAsNonRoot: true
Why it's wrong here
runAsNonRoot blocks containers starting as UID 0 but does not prevent a process from gaining privileges afterwards. It suits workloads where the image must never launch as root; blocking escalation itself requires allowPrivilegeEscalation set to false alongside a restrictive capability drop.
- ✗
capabilities: drop: ['ALL']
Why it's wrong here
Dropping all capabilities removes Linux capabilities but does not set allowPrivilegeEscalation to false, so setuid binaries can still gain privileges. It is tempting because dropping ALL is a recognised hardening step, and it would be correct when the goal is solely to strip capabilities rather than block escalation.
- ✗
readOnlyRootFilesystem: true
Why it's wrong here
readOnlyRootFilesystem prevents writes to the container filesystem but does not stop privilege escalation via setuid binaries or capability gains. It is tempting because it is a common least-privilege hardening measure, and it would be correct when the requirement is filesystem immutability rather than blocking escalation.
- ✓
allowPrivilegeEscalation: false
Why this is correct
Setting allowPrivilegeEscalation to false prevents a container process from gaining more privileges than its parent, blocking mechanisms such as setuid binaries and file capabilities. This satisfies the stem's requirement that privilege escalation attempts within the container be blocked.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CCSP question from scratch — 934 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 CCSP practice question is part of Courseiva's free ISC2 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 CCSP exam.