CCSP Cloud Platform and Infrastructure Security Practice Question
A Kubernetes cluster is being hardened. Which THREE measures should be implemented to restrict container capabilities and reduce the risk of privilege escalation? (Select three.)
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
✓
Running containers as a non-root user
Option C is correct because running containers as a non-root user (e.g., via securityContext.runAsNonRoot: true or a USER directive in the Dockerfile) prevents processes inside the container from having UID 0, which is the primary enabler of privilege-escalation exploits and container-escape techniques. Option D is correct because AppArmor or SELinux profiles enforce mandatory access control that confines container processes to a limited set of files, paths, and operations, blocking actions that even a compromised process could otherwise attempt. Option E is correct because dropping all Linux capabilities and adding back only those explicitly required (e.g., using cap-drop: ALL with a minimal cap-add list) removes dangerous privileges such as CAP_SYS_ADMIN, CAP_NET_RAW, and CAP_SYS_PTRACE that are commonly abused for privilege escalation. Option A is incorrect because privileged mode grants the container nearly all host capabilities and device access, dramatically increasing the attack surface rather than restricting it. Option B is incorrect because running containers as root gives the process full UID 0 privileges inside the container, which is exactly the risk the hardening measures are meant to eliminate.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enabling privileged mode for containers that need host access
Why it's wrong here
Privileged mode grants the container all Linux capabilities and direct host device access, directly enabling the privilege escalation the question asks to reduce. It is tempting because some workloads genuinely need host access, and it would be correct only when that requirement outweighs the hardening objective.
- ✗
Running containers as root
Why it's wrong here
Running as root gives the container UID 0, so any process breakout inherits full root privileges on the host namespace, contradicting the goal of restricting escalation. It is tempting because many default images assume root, and it would be correct only for legacy images that cannot run unprivileged.
- ✓
Running containers as a non-root user
Why this is correct
Running containers as a non-root user removes UID 0 inside the container, so a breakout or exploited process lacks root privileges on the host mount namespace. This directly reduces privilege-escalation risk, satisfying the hardening requirement alongside capability dropping and mandatory access controls.
- ✓
Applying AppArmor or SELinux profiles
Why this is correct
AppArmor and SELinux profiles enforce mandatory access control, confining container processes to declared file, network and capability permissions even if they run as root. This restricts the blast radius of a compromised container, satisfying the stem's privilege-escalation reduction requirement.
- ✓
Dropping all Linux capabilities and adding only required ones
Why this is correct
Dropping all Linux capabilities and re-adding only those required removes privileged operations such as CAP_SYS_ADMIN or CAP_NET_RAW, so a compromised process cannot escalate to host-level control. This directly satisfies the stem's requirement to restrict container capabilities.
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
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.