CKS Minimize Microservice Vulnerabilities Practice Question
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?
⚠ Common exam trap
Candidates often mistakenly think that the Baseline profile is sufficient for non-root requirements, but Baseline only blocks host-level privilege escalation and does not prevent containers from running as root. The Restricted profile explicitly requires MustRunAsNonRoot, making it the correct choice.
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
✓
Restricted profile with enforce mode
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Baseline profile with enforce mode
Why it's wrong here
The Baseline profile in Pod Security Admission is designed to enforce a basic level of security but does not include a runAsNonRoot requirement. It only prohibits privileged containers, host namespaces, and other obvious host access. Therefore, even with enforce mode active, a pod running as root would be admitted, failing the auditor's requirement.
- ✓
Restricted profile with enforce mode
Why this is correct
The Restricted profile is the most stringent Pod Security level and explicitly mandates runAsNonRoot: true, forcing containers to run as a non-root user. When set to enforce mode, the Pod Security Admission controller rejects any pod that fails this check, along with other Restricted requirements like seccomp and capability drops. This directly satisfies the auditor's demand that no pod runs as root.
- ✗
Baseline profile with warn mode
Why it's wrong here
Warn mode does not block pods; it merely adds a warning event to the audit log and a user-facing warning. Combined with the Baseline profile, which lacks any runAsNonRoot rule, warn mode provides no actual protection against root containers. The pod would still run as root, and the administrator would only see a non-actionable warning.
- ✗
Privileged profile with audit mode
Why it's wrong here
The Privileged profile explicitly allows all security settings, including privileged containers and running as root, since it represents the unrestricted policy. Audit mode records violations to the audit log without enforcing anything, so it never blocks or rejects the pod. Consequently, a root-running pod is allowed without any meaningful consequence.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 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 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.