CCSP Cloud Platform and Infrastructure Security Practice Question
A security analyst discovers that a container running in a Kubernetes cluster has been compromised. The attacker escalated privileges and accessed the host's kernel. Which of the following misconfigurations most likely allowed this container escape?
⚠ Common exam trap
The trap is selecting a security-hardening option (Seccomp, read-only FS, AppArmor) as the cause of escape, when in fact those options prevent escape; the correct answer is the one that removes isolation.
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 container was run with the --privileged flag
Running a container with the --privileged flag disables container isolation and gives the container almost all capabilities of the host, including access to host devices and kernel. This allows an attacker who compromises the container to easily escape and access the host kernel, as seen in the scenario.
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 container was run with the --privileged flag
Why this is correct
The --privileged flag disables the default seccomp, AppArmor and capability restrictions, granting the container nearly all Linux capabilities plus access to host devices. That lets an attacker mount the host filesystem or load kernel modules, escaping to the host kernel.
- ✗
The container was run with a default Seccomp profile
Why it's wrong here
A default Seccomp profile still restricts available syscalls, so it does not by itself permit kernel access; the escape stems from privileged mode or host namespace sharing. It is tempting because Seccomp filters syscalls, which would be the correct hardening control when reducing a container's kernel attack surface.
- ✗
The container was run with a read-only root filesystem
Why it's wrong here
A read-only root filesystem only prevents writes to the container's own filesystem; it does not restrict kernel syscalls, capabilities, or host namespace access, so privilege escalation to the kernel remains possible. It is tempting because it hardens against persistent tampering, which would be correct for immutable workloads resisting runtime modification.
- ✗
The container was run with an AppArmor profile in enforce mode
Why it's wrong here
An AppArmor profile in enforce mode actively blocks disallowed operations, so it restricts rather than enables kernel access; the escape arises from privileged or hostPID settings. It is tempting because AppArmor confines program capabilities, which would be the correct control for limiting container behaviour to a defined policy.
Go deeper
Related to this question
About these practice questions
This CCSP question is part of Courseiva's 934-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 →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
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.