A transit team creates a NetworkPolicy whose podSelector matches only Pods with tier=backend. Unlabeled Pods in the same namespace still accept connections from anywhere. Why?
Select an answer to reveal the explanation.
Short Explanation
Policies only lock the lockers whose labels match the tag on the policy — unlabeled lockers stay wide open under that rule.
Full Explanation
A transit team creating a NetworkPolicy whose podSelector matches only Pods with tier=backend will leave unlabeled Pods in the same namespace accepting connections from anywhere because NetworkPolicies apply only to Pods that match their podSelector in that namespace; unmatched Pods remain unrestricted by that policy. Labels are the membership card for policy—without them, backend-only rules never fence the unlabeled workloads.
Unlabeled Pods do not automatically inherit every NetworkPolicy in the cluster including other namespaces. kube-proxy does not ignore NetworkPolicy unless a special annotation is set as described. Unlabeled Pods are not forced onto HostNetwork with automatic isolation by default.
Exam caveat: a namespace-wide default-deny must select all Pods (empty podSelector) to cover unlabeled ones. Operational check: label backends consistently, apply policies to those labels, and either label remaining Pods or add a select-all deny baseline for the transit namespace. 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.