Pod Security Admission: Enforce Restricted Policy with Exemptions
An administrator wants to implement Pod Security Admission (PSA) to enforce the 'restricted' policy for pods in the 'secure' namespace, but allow certain pods to use privileged containers by applying an exemption label. Which three steps are required? (Choose three.)
Quick Answer
The answer is to set the namespace label 'pod-security.kubernetes.io/enforce=restricted' on the 'secure' namespace, then apply the exemption label 'pod-security.kubernetes.io/exempt' to the specific pods that require privileged containers, and finally ensure the PodSecurity feature gate is enabled on the API server. This is correct because Pod Security Admission (PSA) uses namespace-level labels to define enforcement modes, and the exemption label allows certain pods to bypass the enforced policy without altering the namespace-wide restriction. On the CKAD exam, this tests your understanding of how PSA integrates with Kubernetes RBAC and admission control, often appearing as a scenario where you must balance security with operational flexibility. A common trap is forgetting that the feature gate must be active for any labels to take effect, or confusing exemption labels with namespace-level audit or warn modes. Memory tip: think of the namespace as a locked door (enforce=restricted) and the exemption label as a special key for specific pods to enter.
⚠ Common exam trap
The trap is that candidates may think enabling the PodSecurity feature gate is necessary, but it is default in newer Kubernetes versions. Also, they may confuse audit and enforce modes, or think a custom runtime is needed for privilege 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
✓
Use 'pod-security.kubernetes.io/audit=restricted' to log violations without enforcement.
Setting the audit label to 'restricted' logs violations, which is a common initial step to assess compliance before enforcing the policy. Option C is correct because creating a ServiceAccount and labeling it with 'pod-security.kubernetes.io/enforce=privileged' exempts pods using that ServiceAccount from the restricted policy, allowing them to run privileged containers. Option E is correct because setting the namespace label 'pod-security.kubernetes.io/enforce=restricted' enforces the restricted policy on all pods in that namespace that are not exempted. Option B is not required because the PodSecurity feature gate is enabled by default in Kubernetes v1.23+. Option D is incorrect because PSA uses security context validation, not a custom runtime.
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 'pod-security.kubernetes.io/audit=restricted' to log violations without enforcement.
Why this is correct
Setting the audit label logs violations without enforcement, which helps assess the impact before enforcing. It is a recommended step but not strictly required for enforcement. However, in this scenario, it is considered a required step for implementation.
- ✗
Enable the PodSecurity feature gate on the API server and kubelet.
Why it's wrong here
The PodSecurity feature gate is enabled by default in Kubernetes v1.23+, so enabling it manually is not a required step.
- ✓
Create a ServiceAccount for exempted pods and label it with 'pod-security.kubernetes.io/enforce=privileged'.
Why this is correct
Creating a ServiceAccount and labeling it with 'pod-security.kubernetes.io/enforce=privileged' exempts pods that use that ServiceAccount from the restricted policy, allowing them to run privileged containers. This is required for exemption.
- ✗
Install a custom container runtime that supports privilege escalation.
Why it's wrong here
PSA does not require a custom container runtime; it validates security contexts at the admission level.
- ✓
Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' on the 'secure' namespace.
Why this is correct
Setting the namespace label 'pod-security.kubernetes.io/enforce=restricted' is the primary step to enforce the restricted policy on the 'secure' namespace.
Go deeper
Related to this question
About these practice questions
One of 160 original CKAD 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 CKAD
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 cluster administrator wants to enforce that all pods in a namespace run with the 'restricted' Pod Security Standard. Which of the following is the correct way to label the namespace?
hard- ✓ A.pod-security.kubernetes.io/enforce: restricted
- B.pod-security.kubernetes.io/warn: restricted
- C.pod-security.kubernetes.io/audit: restricted
- D.pod-security.kubernetes.io/enforce: restricted
Why A: The `restricted` Pod Security Standard is enforced by applying the label `pod-security.kubernetes.io/enforce: restricted` to the namespace. This label causes the Pod Security Admission controller to reject any pod that violates the restricted policy, ensuring compliance. Only option A correctly specifies this label. Option D is a duplicate and not considered distinct.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD 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 CKAD exam.