The parks namespace enforces the baseline Pod Security level. A developer’s Pod sets privileged: true on a container SecurityContext. What should the developer expect?
Select an answer to reveal the explanation.
Short Explanation
Baseline is the city parks rulebook that bans the wildest container powers. privileged: true is exactly that kind of power move, so admission waves the Pod off. Fix the SecurityContext instead of hoping the node will soften the policy.
Full Explanation
When the parks namespace enforces the baseline Pod Security level, a developer's Pod that sets privileged true on a container SecurityContext should be denied by Pod Security admission. Baseline forbids privileged containers because they weaken container isolation. Municipal baseline namespaces are intentionally opinionated: privileged workloads belong only in tightly controlled exceptions, not in ordinary parks application deploys.
Claiming Pod Security admission ignores privileged and only checks SELinux labels fails the baseline profile, which explicitly restricts privileged. Expecting the Pod to be admitted while kube-proxy strips the privileged bit at runtime fails because kube-proxy does not sanitize Pod security contexts, and admission should deny. Claiming only HostNetwork Pods are blocked while privileged containers are always allowed at baseline contradicts baseline controls on privileged containers.
Exam caveat: namespace labels choose enforce, warn, or audit modes—warn may allow creates while still signaling violations, which can surprise teams who thought baseline was merely advisory. Operational check: remove privileged true, re-apply the Pod or Deployment, confirm admission succeeds, and keep parks workloads aligned with the baseline profile documentation.