Courseiva
← CKS
Full test
hardMultiple Choice

CKS Practice Question: A cluster uses Kubernetes v1.24 with Pod Security…

A cluster uses Kubernetes v1.24 with Pod Security Admission enabled. The cluster administrator wants to enforce that all pods in the 'production' namespace run with the 'restricted' policy level, but some existing deployments use privileged containers. Which approach ensures that only new pods violating the policy are rejected, while existing pods continue to run?

⚠ Common exam trap

A common mix-up: candidates confuse Pod Security Admission with the deprecated PodSecurityPolicy, or assume that setting an enforce label will retroactively terminate existing pods, when in fact PSA only applies to new or updated 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

✓

Add the namespace label 'pod-security.kubernetes.io/enforce=restricted' and leave existing pods unchanged; new pods violating the policy will be rejected.

Pod Security Admission (PSA) in Kubernetes v1.24 enforces policies via namespace labels. Setting `pod-security.kubernetes.io/enforce=restricted` on the 'production' namespace will reject any new pod that violates the restricted policy, but existing pods are not re-evaluated and continue running. This behavior is by design: PSA evaluates pods at creation or update time, not retroactively, so existing workloads are unaffected.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Patch existing deployments to remove privileged containers, then add the label 'pod-security.kubernetes.io/enforce=restricted' to the namespace.

    Why it's wrong here

    Patching existing deployments to remove privileged containers is unnecessary and risky: Pod Security Admission evaluates only at pod creation and does not retroactively inspect already-running pods. Triggering rollouts via a patch can cause downtime and application breakage, while the single missing piece for achieving the stated goal is simply adding the namespace enforce label, which will block future offending pods without touching current workloads.

  • ✓

    Add the namespace label 'pod-security.kubernetes.io/enforce=restricted' and leave existing pods unchanged; new pods violating the policy will be rejected.

    Why this is correct

    Setting the namespace label 'pod-security.kubernetes.io/enforce=restricted' is the correct admission-control mechanism in v1.24: it makes the built-in Pod Security Admission controller reject any new pod that fails the restricted profile. Existing pods are exempt because admission only runs when a pod is created or updated, so running workloads are left untouched. The restricted profile specifically disallows privileged containers, so all future deployments in that namespace must conform or be rejected.

  • ✗

    Create a PodSecurityPolicy that restricts privileged containers and bind it to all service accounts in the namespace.

    Why it's wrong here

    PodSecurityPolicy is deprecated in Kubernetes v1.24 and is not the mechanism behind Pod Security Admission; the two are separate systems, and PSP has no effect when PSA is the active admission chain. Binding a PSP to service accounts requires the deprecated PodSecurityPolicy admission plugin to be enabled, which is not the expected or supported path for enforcing restricted profiles in a v1.24 cluster. Additionally, PSPs do not provide the three-tier (privileged/baseline/restricted) profile model that PSA uses, so even if it were enabled it would not match the requested 'restricted' enforcement semantically.

  • ✗

    Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' and use the 'inform' mode to allow existing pods.

    Why it's wrong here

    'inform' is not a valid value for the pod-security.kubernetes.io/enforce label; the valid modes are enforce, audit, and warn, and the enforce label must be set to one of the policy levels (privileged, baseline, restricted). The 'inform' mode is a fictional construct — audit and warn are the non-blocking modes that simply record or surface violations without rejecting pods. Also, the behavior of leaving existing pods unchanged is true for all PSA modes, so the proposed mechanism is both invalid and based on a misunderstanding of how admission works.

About these practice questions

This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.