Municipal HR applies a deny-all NetworkPolicy in a shared namespace and immediately loses access from their management Pods to the API Pods they still need. What operational lesson applies?
Select an answer to reveal the explanation.
Short Explanation
Slamming every door shut locks you out too — plan the allow-list and a break-glass path before flipping deny-all.
Full Explanation
Municipal HR applying a deny-all NetworkPolicy in a shared namespace and immediately losing access from management Pods to API Pods they still need illustrates that deny-all policies have a wide blast radius; stage allow rules for required peers and break-glass access before or with the deny. Default-deny is powerful for shared civic namespaces but will black-hole legitimate HR admin paths if allow lists are not prepared.
Deny-all NetworkPolicies do not only affect Pods created after the policy while never disturbing existing connections in the absolute way claimed—new connections are subject to policy, and operational impact is immediate for blocked peers. kube-apiserver does not automatically inject allow-all exceptions for any Pod with a ServiceAccount. Deny-all policies are not silently skipped for UID 0 containers.
Exam caveat: include DNS egress and management namespace peers in the staged allows. Operational check: in a non-prod HR namespace, apply allows for management and DNS first, then deny-all, and verify both security posture and admin access. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.