A municipal API gateway Pod is protected by a strict NetworkPolicy. Product still asks whether that alone authenticates callers. What should you tell them?
Select an answer to reveal the explanation.
Short Explanation
A NetworkPolicy is a street gate, not a photo ID check at the counter. It can stop packets from the wrong CIDR or Pod labels, but it does not log anyone in. Keep tokens, mTLS, or API keys in the app—or a proper auth layer—alongside the policy.
Full Explanation
NetworkPolicy filters L3/L4 traffic using pod/namespace selectors, ports, protocols, and CIDRs. It does not authenticate callers. When a municipal API gateway Pod is protected by a strict NetworkPolicy and product asks whether that alone authenticates callers, tell them NetworkPolicy only filters traffic; application authentication remains a separate concern—ServiceAccount tokens and RBAC for API access, application-level authn/authz, mTLS at the service mesh or app layer, API keys, and so on.
NetworkPolicy does not replace ServiceAccount tokens for in-cluster callers once ingress is deny-by-default. It does not perform mutual TLS identity checks at L7 before packets reach the Pod as its built-in job. It also does not authenticate clients using Service selector labels as credentials—Service selectors only determine Endpoints membership for routing.
Exam caveat: scenario questions often conflate network isolation with identity; keep the planes separate. Operational check: show that a peer allowed by NetworkPolicy can still reach the TCP port without presenting application credentials if the app does not authenticate, and that city security reviews for public civic APIs must require both packet policy and application authentication. Document the split in architecture diagrams so product expectations stay accurate.