CKS System Hardening Practice Question
A DevOps engineer wants to ensure that all pods in a namespace have seccomp set to RuntimeDefault unless explicitly overridden. Which approach should be used to enforce this?
⚠ Common exam trap
Many candidates confuse kubelet-level seccomp configuration (which affects the kubelet, not pods) with pod-level enforcement, or they mistakenly think deprecated PSPs are still a valid solution for seccomp enforcement.
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
✓
Configure the namespace with the label 'pod-security.kubernetes.io/enforce: restricted'
The 'restricted' Pod Security Standard enforces seccomp to RuntimeDefault as a baseline requirement. By labeling the namespace with 'pod-security.kubernetes.io/enforce: restricted', the built-in Pod Security Admission controller automatically rejects any pod that does not set seccomp to RuntimeDefault (or a custom profile), without needing a separate policy or manual auditing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a PodSecurityPolicy that sets seccomp to RuntimeDefault
Why it's wrong here
PodSecurityPolicy (PSP) is deprecated as of Kubernetes v1.21 and removed entirely in v1.25, so on any modern cluster the API simply does not exist and this manifest would be rejected. Even on legacy clusters, PSPs require a Policy API and admission controller configuration that many managed providers disable, and they are not scoped to namespaces by default. Therefore, this cannot be a supported or portable way to enforce seccomp per namespace.
- ✗
Use a cronjob to audit and modify pods that do not have seccomp set
Why it's wrong here
A CronJob that periodically scans for non-compliant Pods is inherently asynchronous and cannot prevent a Pod from running with an unconfined seccomp profile during the interval between runs. Furthermore, a running Pod's securityContext is immutable, so the only remediation is to delete and recreate the Pod, which causes downtime and requires manual or scripted intervention. This approach is insufficient as a security control because it provides no admission-time guarantee.
- ✗
Add a seccomp profile to the kubelet configuration
Why it's wrong here
Configuring the kubelet to apply a default seccomp profile affects all Pods on that node indiscriminately, regardless of the namespace they belong to. The kubelet's default profile is a node-level setting that can be overridden by Pod-level securityContext and does not consult namespace labels or Pod Security Admission. Consequently, it cannot achieve per-namespace policy enforcement and would not satisfy a requirement to secure only a specific namespace.
- ✓
Configure the namespace with the label 'pod-security.kubernetes.io/enforce: restricted'
Why this is correct
Applying the label `pod-security.kubernetes.io/enforce: restricted` to the namespace enables Pod Security Admission in enforce mode, which is a built-in admission controller. The `restricted` level of the Pod Security Standards requires Pods to set `securityContext.seccompProfile.type` to `RuntimeDefault` or `Localhost`, among other hardened settings. Any Pod that fails these requirements is immediately rejected at admission time, ensuring that all Pods in the namespace have seccomp enabled. This is the declarative, namespace-scoped mechanism that replaced PodSecurityPolicy.
Go deeper
Related to this question
Learn chapter
System Hardening: CIS Benchmarks and Auditing
Key term
Pod Security Admission
Pod Security Admission is a Kubernetes feature that enforces security standards on pods at creation time to prevent running containers with dangerous privileges.
Key term
OPA Gatekeeper
OPA Gatekeeper is a Kubernetes admission controller that enforces custom security and compliance policies on resources before they are created or updated in a cluster.
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
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.