A NetworkPolicy selects only Pods with tier=api. What happens to Pods in the same namespace that lack that label?
Select an answer to reveal the explanation.
Short Explanation
NetworkPolicies are name tags, not force fields for the whole floor—only labeled (selected) Pods wear that policy. Untagged neighbors stay as they were relative to that object.
Full Explanation
A NetworkPolicy only restricts Pods it selects. If the policy selects Pods with tier=api, Pods in the same namespace that lack that label are not restricted by that policy and remain unrestricted by it. NetworkPolicies behave like name tags on selected workloads, not like a force field that automatically covers every Pod on the floor. Untagged neighbors keep their prior posture relative to that object (though other policies might still select them).
Unselected Pods do not inherit the same deny rules automatically within the namespace. The NetworkPolicy controller does not delete unlabeled Pods as non-compliant. Unselected Pods are also not limited to receiving traffic only from the Kubernetes API server merely because a sibling policy exists for api-tier Pods.
Exam caveat: when the platform goal is namespace-wide default-deny, use an empty podSelector (podSelector: {}) so every Pod in the namespace is selected. Mixing “selected isolation” with “namespace-wide isolation” is a frequent exam trap. Operational check: apply a policy that selects only tier=api with ingress isolation; curl to an api Pod (denied without allows) and to an unlabeled Pod (unaffected by this policy). Use kubectl get pods --show-labels and kubectl describe networkpolicy together so city operators can see exactly which workloads wear the policy.