CKS Cluster Setup Practice Question
A platform team runs a multi-tenant cluster and wants to enforce that all newly created Pods in the 'payments' namespace must run as non-root and must drop all Linux capabilities. The team decides to use a Pod Security Admission (PSA) label on the namespace. Which label value should they apply to the namespace to enforce these restrictions while still allowing other namespaces to remain unrestricted?
⚠ Common exam trap
Many exam-takers confuse the audit or warn labels with enforce, when only the enforce label actually rejects non-compliant Pods.
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
✓
pod-security.kubernetes.io/enforce: restricted
Pod Security Admission enforces one of three levels: privileged, baseline, or restricted. The restricted level is the only one that requires non-root execution and dropping all capabilities. Setting the enforce label to restricted on the payments namespace blocks non-compliant Pods there while leaving other namespaces without the label unrestricted, which satisfies the multi-tenant 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.
- ✗
pod-security.kubernetes.io/enforce: baseline
Why it's wrong here
The baseline policy prevents known privilege escalations but still allows running as root and does not require dropping all capabilities. It would not enforce the non-root or drop-all-capabilities requirements the team needs for the payments namespace. Applying baseline leaves the namespace less restricted than the stated security objective demands, so it is insufficient here.
- ✗
pod-security.kubernetes.io/audit: restricted
Why it's wrong here
The audit label only records policy violations in the audit log; it does not block non-compliant Pods from being created. The team needs enforcement that rejects non-root or capability-retaining Pods, so an audit-only label fails to meet the objective. It provides visibility without prevention, which is not what this scenario requires.
- ✓
pod-security.kubernetes.io/enforce: restricted
Why this is correct
The restricted policy enforces the most hardened Pod Security Standard, requiring non-root execution, dropping all capabilities, disallowing privilege escalation, and mandating seccomp and runtime default settings. Applying this enforce label to the payments namespace makes non-compliant Pods rejected at admission, while other namespaces without the label remain unaffected, matching the requirement.
- ✗
pod-security.kubernetes.io/enforce: privileged
Why it's wrong here
The privileged policy is the least restrictive and explicitly allows everything, including root, host access, and all capabilities. It exists for system workloads that genuinely need full access. Applying it to the payments namespace would do the opposite of the requirement, effectively disabling the security controls the team wants to impose.
Go deeper
Related to this question
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 →
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 CNCF exam blueprint
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.