CKS Cluster Hardening Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Enable PodSecurity admission with 'restricted' policy in enforce mode

  Why this is correct

  PodSecurity admission is the built-in replacement for PSPs; the `restricted` policy in enforce mode validates every pod against a standard set of constraints, and it specifically requires a seccomp profile of `RuntimeDefault` or `localhost`. Because it runs in the admission phase, the API server rejects any pod that does not declare the profile, making it a true enforcement control at the namespace level. This is the recommended way to guarantee seccomp coverage across all workloads.

• ✗

  Create a new PSP with seccomp profile and assign it to the namespace

  Why it's wrong here

  PSP was removed in Kubernetes 1.25, so on a modern cluster this policy object does not exist; even on older versions PSPs are cluster-scoped authorization rules, not namespace-scoped assignments. You cannot 'assign' a PSP to a namespace — instead you bind it to a ServiceAccount via RBAC, which leaves many pods unaffected if their SA lacks the binding, and seccomp requirements in PSPs are easy to bypass. Relying on PSP is defensively obsolete and not a viable enforcement solution.

• ✗

  Set seccomp profile in the kubelet configuration

  Why it's wrong here

  The kubelet's `--seccomp-default` flag only instructs the node's runtime to apply the runtime default profile when a container does not specify one; it is a runtime-level default, not an admission policy. It has no awareness of namespaces or pod security constraints, and an explicit `seccompProfile` in the pod spec overrides it, while older runtimes may ignore it entirely. Therefore it never guarantees that a given namespace cannot run without a profile.

• ✗

  Use a mutating admission webhook to add seccomp profile

  Why it's wrong here

  A mutating admission webhook can inject a seccomp profile into a pod's security context, but it does not validate or reject anything; if the webhook is not registered, fails open, or a pod already sets an unconfined profile, the mutation may simply never occur. The API server never checks the final pod state against seccomp requirements, so a client communicating directly or using a privileged profile can still result in containers without the intended restriction. It is an operational defaulting tool, not an enforcement control.

Go deeper

Related to this question