A sanitation cluster wants to stop unrelated apps from talking east-west inside the same namespace without adopting CKS-only tooling. Which CKA-depth control fits?
Select an answer to reveal the explanation.
Short Explanation
For hallway isolation between apps, NetworkPolicy labels are the CKA-friendly fence — not headless Services or token automount flags.
Full Explanation
A sanitation cluster that wants to stop unrelated apps from talking east-west inside the same namespace without adopting CKS-only tooling should use NetworkPolicies with podSelectors so only intended app labels may communicate, isolating unrelated Pods at L3/L4. NetworkPolicy is in CKA scope for basic isolation and fits hallway isolation between municipal apps without requiring advanced security specialist tooling.
Enabling PodSecurity admission restricted mode does not drop all TCP packets between namespaces automatically; Pod Security admits Pod specs, it is not a network filter. Converting every Service to headless does not make kube-proxy refuse cross-app connections. Setting automountServiceAccountToken to false blocks token mounting, not east-west IP traffic.
Exam caveat: combine default-deny with explicit allow policies between labeled tiers for real isolation. Operational check: label sanitation apps, apply NetworkPolicies for intended pairs, and verify unrelated Pods can no longer connect on the monitored ports. 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.