Frontend Pods labeled app=frontend must reach backend Pods labeled app=backend on TCP 8080. Which NetworkPolicy approach allows that ingress?
Select an answer to reveal the explanation.
Short Explanation
NetworkPolicy ingress is "who may knock on these Pods' doors." Select the backend, allow from the frontend podSelector on 8080. RBAC and HTTP Ingress objects don't replace that packet allow.
Full Explanation
NetworkPolicy ingress rules answer who may send packets to the protected Pods. To allow frontend Pods labeled app=frontend to reach backend Pods labeled app=backend on TCP 8080, select the backend Pods as policy subjects and allow ingress from podSelector app=frontend on port 8080 with protocol TCP. Put the allow on the backend doors with matching peer labels and the correct port—that is the standard east-west allow pattern for a municipal frontend/backend split.
Selecting frontend Pods and denying all egress does not create an ingress allow on backends; client egress denies are a different control plane action. An Ingress resource with path /backend does not replace NetworkPolicy for Pod-to-Pod TCP filtering. RBAC RoleBindings on ServiceAccounts authorize API verbs, not network packets, so they cannot substitute for NetworkPolicy peers.
Exam caveat: policy podSelector selects Pods being protected; from/podSelector selects peers—swapping them is a frequent mistake. Operational check: verify labels on both Deployments, apply the backend ingress allow, curl from a frontend Pod successfully, and curl from an unlabeled Pod unsuccessfully. Document the allow as part of the city’s frontend→backend connectivity contract.