Courseiva
System Hardening →easyMultiple Choice

CKS System Hardening Practice Question

An administrator wants to restrict pods from running as root. Which admission controller should be enabled?

⚠ Common exam trap

CNCF often tests the misconception that NodeRestriction or ServiceAccount can enforce pod-level security policies, but these controllers serve entirely different purposes—NodeRestriction is for kubelet authorization, and ServiceAccount is for identity management, not for restricting root access.

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

✓

PodSecurity

The PodSecurity admission controller (D) is the correct choice because it enforces the Pod Security Standards (Privileged, Baseline, Restricted) defined in the Kubernetes documentation. By enabling this controller, the administrator can configure a policy that prevents pods from running as root, typically by setting the 'Restricted' profile which requires 'runAsNonRoot: true' and 'runAsUser: > 10000' in the pod security context.

Answer analysis

Option-by-option breakdown

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

  • ✗

    NodeRestriction

    Why it's wrong here

    NodeRestriction is a kubelet authorization admission controller that constrains the kubelet's ability to modify Node and Pod objects, such as preventing it from altering its own Node's status or Pod bindings. It does not inspect or enforce any container security context, so it cannot restrict the user ID that container processes run as. Thus, it is entirely unrelated to the goal of preventing root execution.

  • ✗

    AlwaysPullImages

    Why it's wrong here

    AlwaysPullImages is an admission controller that forces every Pod creation to query the image registry and always pull the image, even if it already exists locally on the node. This prevents the reuse of stale or tampered images but has no effect on the runtime user of the container processes. An image can still be configured to run as root, so this mechanism does not satisfy the administrator's requirement.

  • ✗

    ServiceAccount

    Why it's wrong here

    The ServiceAccount admission controller manages the default service account and the automatic mounting of API credentials into Pods, ensuring Pods use the correct identity for API access. It does not evaluate or modify the Pod's securityContext or the user ID of container processes. Therefore, while it controls authentication to the Kubernetes API, it cannot prevent a container from running as root.

  • ✓

    PodSecurity

    Why this is correct

    PodSecurity is the correct answer because it is a built-in admission controller that enforces the Pod Security Standards, specifically the 'restricted' profile, which mandates that containers run as a non-root user (e.g., runAsNonRoot: true and runAsUser set to a non-zero ID). It validates the Pod's securityContext during creation and rejects any Pod that attempts to run as root. This directly implements the administrator's policy to restrict root execution.

Go deeper

Related to this question

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 →

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.