CKS Practice Question 5: Pod Security Admission Enforce
Certified Kubernetes Security Specialist (CKS) · Test 1 · question 5 of 10
After labelling an existing namespace with pod-security.kubernetes.io/enforce=restricted and pod-security.kubernetes.io/enforce-version=latest, you observe that privileged Pods that were already running are untouched, and that kubectl apply -f deployment.yaml for a non-compliant Deployment returns no error at all, yet no new Pods ever appear.
What explains this behaviour?
Show answer and explanation
Answer:
Pod Security admission is a validating admission controller evaluated when a Pod is created or updated. It never evicts or mutates Pods that already exist, which is why the running privileged Pods survive the relabelling. For workload resources, the object itself is admitted, the Deployment is stored happily, and the violation only surfaces when its ReplicaSet controller attempts the Pod create, so you find the message with kubectl describe replicaset or in the ReplicaSet's events. Adding the warn (and audit) labels alongside enforce is what gives you immediate feedback at kubectl apply time on the workload resource.
Option A describes a policy engine that Pod Security admission is not. There is no controller that sweeps and evicts violating Pods; that has to be done deliberately by an operator.
Option B is wrong about the exemption. Pods created by controllers are checked exactly like user-created Pods; the check simply happens against the Pod object the controller submits.
Option D is out of date. PodSecurity has been enabled by default since v1.23 and is stable since v1.25; the namespace labels alone are enough to activate it.
Reference: Pod Security Admission