CCSP Cloud Platform and Infrastructure Security Practice Question
A cloud security auditor is reviewing container runtime configurations. Which TWO practices help prevent a container from compromising the host operating system?
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
✓
Using a read-only root filesystem
Option A, using a read-only root filesystem, is correct because it prevents a compromised container process from writing malicious files, modifying binaries, or persisting changes to the container's filesystem, which limits the ability to tamper with the host through mounted volumes or writable layers. Option D, dropping all Linux capabilities, is correct because Linux capabilities grant fine-grained kernel privileges (e.g., CAP_SYS_ADMIN, CAP_NET_ADMIN); dropping all of them removes the ability to perform privileged operations like mounting filesystems, loading kernel modules, or manipulating network stacks that could be leveraged to escape the container and affect the host. Option B is wrong because disabling SELinux removes a mandatory access control layer that confines container processes, weakening host protection rather than strengthening it. Option C is wrong because privileged mode gives the container nearly all host capabilities and device access, dramatically increasing the risk of host compromise. Option E is wrong because mapping the host's Docker socket into a container effectively grants control over the Docker daemon, allowing the container to launch privileged containers or access the host, which is a well-known container escape vector.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Using a read-only root filesystem
Why this is correct
A read-only root filesystem prevents processes inside the container from writing to or modifying the underlying host-mounted filesystem, blocking a common container-to-host compromise path. It satisfies the requirement to stop containers compromising the host operating system.
- ✗
Disabling SELinux inside the container
Why it's wrong here
Disabling SELinux strips the mandatory access control confinement that limits a container's reach into host resources, weakening isolation. It tempts because disabling SELinux can resolve permission conflicts during troubleshooting, yet production hardening requires SELinux enforcing, not disabled.
- ✗
Running containers in privileged mode
Why it's wrong here
Privileged mode grants the container full access to host devices and kernel capabilities, removing the isolation boundary that prevents host compromise. It tempts because privileged containers simplify tasks needing hardware or kernel access, but least-privilege capability assignment is the hardening requirement.
- ✓
Dropping all Linux capabilities
Why this is correct
Dropping all Linux capabilities removes every granular privilege—such as `CAP_SYS_ADMIN` or `CAP_NET_RAW`—that a containerised process could otherwise inherit from the host kernel. This directly satisfies the stem’s requirement to prevent container-to-host compromise by eliminating the capability-based attack surface that could allow privilege escalation or direct kernel manipulation.
- ✗
Mapping the host's Docker socket into the container
Why it's wrong here
Mounting the host Docker socket gives the container control over the Docker daemon, permitting it to start privileged containers and mount host paths, which enables host compromise rather than preventing it. It is used for container-management tooling, not runtime hardening.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
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 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.