A city parking API listens on TCP 8080, but a NetworkPolicy allow rule lists protocol UDP and port 8080 for the same Pods. What happens to legitimate client traffic?
Select an answer to reveal the explanation.
Short Explanation
Think of protocol like the language on a shipping label—same street number, wrong language, and the package never gets delivered. NetworkPolicy port rules match both port and protocol, so a UDP allow does not open TCP. Your parking clients speaking TCP stay blocked until the rule says TCP.
Full Explanation
NetworkPolicy port rules match both port and protocol. If a city parking API listens on TCP 8080 but a NetworkPolicy allow rule lists protocol UDP and port 8080 for the same Pods, legitimate TCP client traffic does not match that allow and is denied under an isolating policy. Protocol is like the language on a shipping label—same street number, wrong language, and the package never gets delivered. Candidates must treat protocol as a first-class match field, not an optional decoration.
Kubernetes does not rewrite UDP allows into TCP when containerPort is 8080. The policy does not allow TCP merely because the port number matches regardless of protocol. The mismatch is not limited to somehow blocking only kube-proxy health checks while application clients remain unaffected; application TCP clients miss the allow and fail.
Exam caveat: when writing NetworkPolicy ports, always set protocol explicitly to match the application (usually TCP for HTTP APIs). Operational check: correct the allow to TCP 8080, curl the parking API successfully from an allowed peer, and keep a lab example with UDP-only to show TCP denial. During review, kubectl describe networkpolicy and read the ports section carefully to catch protocol typos before production rollout for civic services.