mediumMultiple Choice
CKS Practice Question: An administrator discovers that a container has…
An administrator discovers that a container has been running with root privileges despite a PodSecurityPolicy that should prevent it. What is the most likely cause?
⚠ Common exam trap
CNCF often tests the distinction between creating a policy resource and actually enabling the admission controller that enforces it, tricking candidates into focusing on RBAC or policy content rather than the fundamental admission plugin flag.
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
✓
The PodSecurityPolicy admission controller is not enabled in the kube-apiserver.
The PodSecurityPolicy (PSP) admission controller must be explicitly enabled in the kube-apiserver's `--enable-admission-plugins` flag. Without it, PSP resources are stored in etcd but never enforced, allowing any pod to run with root privileges regardless of PSP definitions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The PodSecurityPolicy is applied in the wrong order and a less restrictive policy overrides it.
Why it's wrong here
PodSecurityPolicy evaluation is not a simple ordered list where a later, less restrictive policy can override an earlier one. The kube-apiserver sorts all PSPs by name and, after checking that the requesting user/service account is authorized to use them, selects the single most restrictive policy that still permits the pod. A root container would be allowed only if the selected PSP explicitly permits a root UID or privileged mode; mere ordering cannot cause a less restrictive policy to win out over a more restrictive one.
- ✗
The pod's service account lacks RBAC permissions to use the PSP.
Why it's wrong here
If the pod's service account lacked RBAC permissions to use any PSP, the API request would be rejected with a Forbidden error before the pod is ever created. The administrator's observation is that a container has already been running, which means the pod passed admission and was scheduled. Furthermore, RBAC authorization for PSPs is only consulted when the PodSecurityPolicy admission controller is actually enabled; without that plugin, PSP-related RBAC is never evaluated, so a missing permission could not be the reason root execution is permitted.
- ✓
The PodSecurityPolicy admission controller is not enabled in the kube-apiserver.
Why this is correct
The PodSecurityPolicy admission controller is a Kubernetes admission plugin that must be explicitly enabled via the kube-apiserver's `--enable-admission-plugins` flag. If it is not enabled, `PodSecurityPolicy` objects can exist in the cluster but are completely ignored during pod creation and update. The kube-apiserver will allow a privileged or root-running container through because no admission plugin applies the policy constraints, even if RBAC roles and bindings for the PSP are correctly configured. This is the core root cause: PSPs are only enforceable when their admission controller is active.
- ✗
The PodSecurityPolicy resource is misconfigured with an empty allowPrivilegeEscalation field.
Why it's wrong here
In a PodSecurityPolicy, the `allowPrivilegeEscalation` field controls whether a process can gain more privileges than its parent (for example, via setuid binaries or effective UID changes), and when this field is unset it defaults to `false`, which denies privilege escalation rather than permitting root. Running a container's main process as root is governed by the PSP's `runAsUser` and `runAsGroup` rules, not by `allowPrivilegeEscalation`. An empty or missing `allowPrivilegeEscalation` field would not allow root execution; it would actually block a specific privilege-escalation vector, so this misconfiguration is not the reason the container is running with root privileges.
Go deeper
Related to this question
Learn chapter
Supply Chain Security: Container Image Security
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.
Key term
Node Restriction
A Kubernetes admission controller that limits what a kubelet can modify on its own node to prevent privilege escalation and unauthorized access.
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 →
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.