Courseiva
← CKS
Full test
System Hardening →hardMultiple Choice

CKS System Hardening Practice Question

A security team wants to enforce that no container in the 'restricted' namespace runs with added Linux capabilities beyond the default set (according to the restricted Pod Security Standard). Which PodSecurityConfiguration should be applied to the namespace?

⚠ Common exam trap

Candidates often confuse the 'baseline' profile with 'restricted', thinking baseline is sufficient to block added capabilities, but baseline explicitly allows a set of capabilities (e.g., CHOWN, DAC_OVERRIDE) that are not permitted under the restricted standard.

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

✓

apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "restricted" enforce-version: "latest"

The 'restricted' Pod Security Standard (PSS) is the most stringent profile, which enforces that no container runs with added Linux capabilities beyond the default set (e.g., dropping all capabilities except those required by the runtime). The 'enforce' mode blocks non-compliant pods from being created, and 'enforce-version: latest' applies the most current version of the restricted profile, ensuring that any new restrictions are automatically enforced.

Answer analysis

Option-by-option breakdown

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

  • ✓

    apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "restricted" enforce-version: "latest"

    Why this is correct

    The `restricted` enforce level applies the most restrictive Pod Security Standard, which is exactly what the security team requires. It rejects any pod that does not meet strict criteria: privileged containers are forbidden, all Linux capabilities are dropped except `NET_BIND_SERVICE`, and settings like `runAsNonRoot` and `seccompProfile` become mandatory. With `enforce-version: latest`, the policy tracks the current standard as Kubernetes evolves, ensuring ongoing compliance without manual updates.

  • ✗

    apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: warn: "restricted" warn-version: "latest"

    Why it's wrong here

    Setting `warn: restricted` only tells the API server to return a warning message to the client when a pod violates the restricted profile, but the pod is still admitted and can run with additional capabilities. This is not enforcement: a malicious or misconfigured workload is created anyway, so the security team's requirement is never actually applied. Warning may help developers notice issues, but it does not block anything.

  • ✗

    apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "privileged" enforce-version: "latest"

    Why it's wrong here

    The `privileged` enforce profile is the complete opposite of the desired security posture: it imposes no restrictions on containers, allowing privileged mode, host namespaces, and all Linux capabilities. Enforcing this profile would guarantee that any pod can run with capabilities far beyond the default minimal set, directly violating the requirement to drop all capabilities except the bare minimum. This configuration actively weakens the cluster's security baseline and would be a serious misconfiguration.

  • ✗

    apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "baseline" enforce-version: "latest"

    Why it's wrong here

    The `baseline` enforce profile is less restrictive than `restricted`; while it forbids privileged containers and host namespaces, it still permits a broader list of Linux capabilities and does not require the same hardening settings such as `runAsNonRoot` or `seccompProfile`. Because baseline allows default capabilities and additional ones beyond the minimal set, it does not satisfy the security team's explicit goal of dropping all capabilities except the default minimal set. Enforcing baseline would therefore admit workloads that restricted would correctly reject.

About these practice questions

One of 845 original CKS 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 →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way this is tested on CKS

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 security engineer wants to enforce that all containers in a namespace run without any unnecessary Linux capabilities, dropping all capabilities by default and only adding back what is needed. Which Pod Security Standard should be applied to that namespace using PodSecurity admission?

medium
  • A.Privileged
  • B.Custom
  • C.Baseline
  • ✓ D.Restricted

Why D: The Restricted Pod Security Standard is the most stringent profile, which enforces dropping all capabilities by default and only allowing those explicitly required. It sets `securityContext.capabilities.drop: ["ALL"]` and restricts `allowedCapabilities` to an empty set, ensuring containers run with minimal Linux capabilities. This directly matches the requirement to drop all capabilities and add back only what is needed.

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.