Public-health API Pods should accept ingress from any Pod running in namespaces labeled team=intake. Which NetworkPolicy peer selector expresses that?
Select an answer to reveal the explanation.
Short Explanation
Need a whole labeled neighborhood to reach the API? Use namespaceSelector on that label — not nodeSelector or topology tricks.
Full Explanation
Public-health API Pods that should accept ingress from any Pod running in namespaces labeled team=intake need an ingress from rule using namespaceSelector matching team=intake, optionally combined with podSelector. namespaceSelector is the NetworkPolicy peer mechanism for allowing entire labeled namespaces—here intake—into the API without enumerating every client Pod name across municipal intake systems.
A nodeSelector on the API Deployment that lists intake worker node names as peers is scheduling, not NetworkPolicy ingress peering. A topologySpreadConstraint with topologyKey set to team=intake does not implement NetworkPolicy allow rules. An ExternalName Service whose CNAME equals the intake namespace label is DNS aliasing, not L3/L4 policy.
Exam caveat: namespaces must actually carry the team=intake label for namespaceSelector to match. Operational check: label intake namespaces, apply the ingress policy on the API Pods, and verify only Pods from those namespaces can connect while others are denied under a default-deny baseline. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.