A DevOps team deploys a containerized application to a Kubernetes cluster. They need to ensure that containers cannot run with privileged access. Which Kubernetes security mechanism should be applied?
Pod Security Standards define the privileged, baseline and restricted profiles enforced via pod security admission, blocking containers that request privileged mode. This directly satisfies the constraint that containers cannot run with privileged access, unlike RBAC, which governs API permissions rather than pod capabilities.
Why this answer
Pod Security Standards (PSS) define three profiles — Privileged, Baseline, and Restricted — that control whether pods can run with privileged access, host networking, hostPath volumes, and similar elevated capabilities. Enforcing the Restricted or Baseline profile via Pod Security Admission prevents containers from running privileged. This is the native Kubernetes mechanism for restricting pod-level privileges.
Exam trap
CV0-004 often tests the confusion between network-level controls (Network Policies) and workload-level privilege controls (Pod Security Standards) — candidates may pick Network Policies thinking they restrict container capabilities.
How to eliminate wrong answers
Option B is wrong because Network Policies control pod-to-pod network traffic (ingress/egress), not container privilege levels or security contexts. Option C is wrong because ConfigMaps store non-sensitive configuration data as key-value pairs and have no security enforcement role. Option D is wrong because Service Accounts provide identity for pods to authenticate to the Kubernetes API and external services, not runtime privilege restrictions.