A city cluster must isolate Pods in the finance namespace so that, by default, no other Pods can reach them until explicit allow rules are added. Which NetworkPolicy approach achieves that default-deny posture for selected Pods?
Select an answer to reveal the explanation.
Short Explanation
Default-deny is like locking every office door first, then handing out keys with allow rules — empty/deny ingress on a NetworkPolicy selects who starts locked.
Full Explanation
A city cluster that must isolate Pods in the finance namespace so that by default no other Pods can reach them until explicit allow rules are added should apply a NetworkPolicy that selects the finance Pods and defines an empty ingress rule set or equivalent deny-all ingress so only later allow rules reopen traffic. Selecting the Pods and denying ingress by default establishes the posture; subsequent policies add allowed peers for payroll and treasury paths.
Creating a ClusterRole with no verbs affects API authorization, not east-west TCP packet filtering. Setting every Service type to ExternalName does not implement default-deny Pod networking. Deleting CoreDNS ConfigMaps so unresolved names act as a network deny-all breaks discovery without enforcing L3/L4 isolation.
Exam caveat: default-deny has a wide blast radius—stage allow rules for required peers including DNS if egress is also restricted. Operational check: apply deny-all ingress to finance Pods, verify others cannot connect, then add explicit allow policies for approved clients and retest. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.