hardMultiple Choice
SSCP Practice Question: A company runs containerized applications in a…
A company runs containerized applications in a Kubernetes cluster. They need to ensure that containers run with the least privilege and cannot escalate privileges. Which configuration change is MOST effective?
⚠ Common exam trap
SSCP often tests the misconception that running as non-root is sufficient for least privilege, but the exam expects you to recognize that capabilities are the granular privileges that must be dropped to prevent 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
✓
Drop all Linux capabilities from the container
Dropping all Linux capabilities is the most effective because capabilities are the granular privileges that allow a process to perform privileged operations (e.g., CAP_NET_ADMIN, CAP_SYS_ADMIN). Even a non-root user can escalate privileges if it retains capabilities. By dropping all capabilities, the container loses the ability to perform any privileged action, directly enforcing least privilege and preventing privilege escalation. This is a fundamental Kubernetes securityContext setting that aligns with the principle of least privilege.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set the container to run as non-root user
Why it's wrong here
Running as non-root blocks root-owned file access inside the container, yet a process can still set allowPrivilegeEscalation or add capabilities and gain root. It is tempting because non-root users are a standard baseline hardening step, but it does not prevent escalation.
- ✓
Drop all Linux capabilities from the container
Why this is correct
Dropping all Linux capabilities removes the kernel privileges a container could abuse, directly enforcing least privilege and blocking privilege escalation. This satisfies the stem's requirement that containers cannot escalate, unlike seccomp or read-only filesystems which restrict different attack surfaces.
- ✗
Mount the container root filesystem as read-only
Why it's wrong here
A read-only root filesystem blocks writes to the image layer but does not stop privilege escalation through setuid binaries, capabilities, or privileged mode. It is tempting as a hardening measure, and it would be correct for preventing runtime tampering with container files, but not for least-privilege enforcement.
- ✗
Enable SELinux enforcing mode on the host
Why it's wrong here
SELinux confines host processes and files, but it does not stop a container running as root from exploiting privileged flags or kernel capabilities inside the cluster. It is tempting because it hardens the underlying node, which is a separate layer from pod-level privilege controls.
Go deeper
Related to this question
About these practice questions
This SSCP question is part of Courseiva's 971-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 SSCP 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 SSCP exam.