Write a frontend-to-backend NetworkPolicy

WHAT THIS TESTS This is a write-the-YAML exercise that reveals whether you understand the structure of ingress rules and the implicit default-deny.

A GOOD ANSWER COVERS The policy is a networking.k8s.io/v1 NetworkPolicy. spec.podSelector uses matchLabels app: backend to target the protected pods. spec.policyTypes lists Ingress. Under spec.ingress you add one rule object. Its from list contains one peer with a podSelector matchLabels app: frontend, restricting the source. Its ports list contains one entry with protocol: TCP and port: 8080. Because the moment any policy selects the backend pods for Ingress the direction becomes default-deny, you do not write any explicit deny; all traffic not matching the single allow rule is dropped automatically. The from and ports within a single ingress rule are ANDed, so only frontend pods AND port 8080 are permitted. The policy must live in the same namespace as the backend pods, since podSelector is namespace-scoped.

COMMON WRONG ANSWERS Adding a second rule to deny everything else is redundant and shows misunderstanding of implicit deny. Placing the podSelector for frontend under ports rather than under from breaks the source match. Omitting policyTypes can leave intent ambiguous. Forgetting protocol defaults to TCP but being explicit is clearer.

LIKELY FOLLOW-UPS How to also allow from a specific namespace using namespaceSelector. Why egress is untouched here. What happens if frontend is in another namespace.

ONE CONCRETE EXAMPLE The resulting policy: podSelector app: backend, policyTypes Ingress, ingress with from podSelector app: frontend and ports TCP 8080. A frontend pod hitting backend on 8080 succeeds; the same pod on 9090, or any other pod on 8080, is dropped.