First NetworkPolicy flips a pod to default-deny

WHAT THIS TESTS This checks understanding of the single most surprising NetworkPolicy behavior: applying a policy is not purely additive; it switches the selected pod into default-deny for the covered direction.

A GOOD ANSWER COVERS By default Kubernetes networking is flat and allow-all: any pod can reach any other. NetworkPolicies are namespaced objects with a podSelector. As soon as the first policy selects a given pod and specifies a policyType, that direction becomes default-deny. If the policy lists ingress rules, only traffic matching those rules is allowed in; everything else is dropped. If it lists policyTypes Ingress but with no rules, all ingress is denied. Egress behaves the same way independently. Crucially, directions the policy does not mention remain unaffected and open, and any pod that no policy selects keeps full allow-all connectivity. Policies are additive across multiple policies selecting the same pod: the union of all their allow rules is permitted.

COMMON WRONG ANSWERS Saying the pod keeps talking to everyone after a policy is applied misses the implicit deny. Thinking an empty-rule policy is a no-op is wrong; it locks the pod down. Forgetting that enforcement depends on a policy-aware CNI like Calico or Cilium; with a non-supporting CNI policies are silently ignored.

LIKELY FOLLOW-UPS How to write an explicit default-deny-all policy. How multiple policies combine (union of allows). Why egress to DNS often breaks first.

ONE CONCRETE EXAMPLE Apply a policy selecting app=db with one ingress rule allowing app=api on 5432. Instantly the db pod rejects all other ingress; only api pods on 5432 connect, while the db's egress stays open because the policy did not mention it.