CKS Minimize Microservice Vulnerabilities Practice Question
During a security audit, a team discovers that their microservice application, deployed on Kubernetes, is vulnerable to container breakout attacks. The containers run as root and have many Linux capabilities. Which set of Pod Security Standards (PSS) enforcement modes and policies would best mitigate this risk?
⚠ Common exam trap
CNCF often tests the misconception that 'baseline' PSS is sufficient for most security needs, but the trap here is that 'baseline' still allows root and default capabilities, which are exactly the vectors exploited in container breakout attacks, making 'restricted' the only adequate choice for this specific risk.
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
✓
Use 'restricted' PSS with Enforce mode
The 'restricted' Pod Security Standard with 'Enforce' mode is the correct choice because it mandates the most stringent security controls, including dropping all Linux capabilities and preventing containers from running as root. This directly mitigates container breakout attacks by eliminating the excessive privileges that enable such exploits. 'Enforce' mode actively blocks non-compliant pods, ensuring the policy is applied without relying on user awareness or audit logs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use 'privileged' PSS with Warn mode
Why it's wrong here
Privileged profile disables all Pod Security Standard restrictions, permitting privileged containers, host namespaces, and all Linux capabilities, which maximizes the risk of container breakout. Adding Warn mode does not change this behavior because warning merely adds an admission annotation and does not block or reject the pod, so a compromised container can still leverage root privileges and elevated capabilities to escape.
- ✗
Use 'baseline' PSS with Audit mode
Why it's wrong here
Baseline profile (non-privileged) does prevent privileged containers and host namespace sharing, but it still allows running as root and keeps default capabilities like CHOWN and SETUID, which are often enough for a breakout. Audit mode is purely reactive: it only logs policy violations and never intercepts them, so pods that violate baseline are admitted and execute with the same dangerous root context, meaning the audit log is of no help during an active attack.
- ✓
Use 'restricted' PSS with Enforce mode
Why this is correct
Restricted profile in Enforce mode is the only combination among the choices that both selects the strongest pod-hardening policy and actually enforces it at admission time. Restricted requires runAsNonRoot=true, sets seccompProfile to RuntimeDefault, drops all capabilities except NET_BIND_SERVICE, and mandates a read-only root filesystem, which together deprive an attacker of the most common kernel exploits. Because Enforce mode rejects non-compliant pods before they are created, there is no opportunity for a restricted-violating pod to run and escape.
- ✗
Use 'baseline' PSS with Enforce mode
Why it's wrong here
Baseline with Enforce mode does force every pod to comply with the baseline standard, but baseline still allows root user execution and default capability sets. Even with enforcement, a root-running pod can install kernel modules, modify host files if volumes are mounted, or use standard tools like mount/nsenter to break out, so the enforcement is meaningless if the policy itself is too permissive for the threat model.
Go deeper
Related to this question
Learn chapter
Cluster Setup: Secure Configuration and Best Practices
Key term
Pod Security Admission
Pod Security Admission is a Kubernetes feature that enforces security standards on pods at creation time to prevent running containers with dangerous privileges.
Key term
Pod Security Standards
Pod Security Standards are a set of predefined Kubernetes policies that control the security context of pods to prevent privilege escalation and enforce least privilege.
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A security auditor requires that all pods in a cluster must not run as root. Which Pod Security Standard (PSS) and enforcement mode should be applied at the namespace level?
medium- A.Baseline profile with enforce mode
- ✓ B.Restricted profile with enforce mode
- C.Baseline profile with warn mode
- D.Privileged profile with audit mode
Why B: The Restricted profile is the only Pod Security Standard that prohibits running containers as root by enforcing the 'MustRunAsNonRoot' security context constraint. Applying it in 'enforce' mode ensures that any pod violating this rule is immediately rejected at admission time, which directly meets the auditor's requirement.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF 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 CKS exam.