Exercise 3: Backend Pods Can't Resolve DNS After a NetworkPolicy — What's Missing — Possible Solution
====================================================================

What's likely missing: an explicit rule allowing outbound (egress)
DNS traffic -- typically to `kube-system`, on port 53 -- was never
added to the policy.

Why this causes the observed symptom:

Per this chapter's own tip-box, the moment a NetworkPolicy selects the
backend pods, ALL of their traffic switches to deny-by-default except
for what's explicitly allowed -- not just the specific traffic
category the team was trying to restrict. The team's policy only
specified an INGRESS rule (incoming traffic from frontend pods, per
the exercise's own description) -- it said nothing at all about
EGRESS (outbound traffic FROM the backend pods).

DNS resolution -- which is what makes Service names from `k8s1-6`
actually resolve to IP addresses -- requires the backend pod to send
OUTBOUND DNS queries to the cluster's internal DNS service (running in
`kube-system`, on port 53). Once the backend pods became
deny-by-default for ALL traffic (not just ingress), that outbound DNS
traffic -- never having been explicitly allowed -- is now silently
blocked along with everything else that wasn't listed.

This produces exactly the confusing symptom described: the backend
pods can't resolve ANY Service DNS name, even though the policy itself
never mentioned DNS or name resolution at all -- because the policy's
restriction wasn't scoped to only the traffic it explicitly discussed;
it restricted EVERYTHING for those pods, and DNS traffic simply wasn't
on the allowed list.

The fix, per this chapter's own warn-box: add an explicit egress rule
permitting DNS traffic (typically UDP/TCP port 53) to `kube-system`,
alongside whatever ingress rule already allows frontend traffic in.

WHY THIS WORKS AS AN ANSWER
------------------------------
This applies the chapter's own deny-by-default-once-selected mechanism
(Exercise 1's own point) to explain WHY an ingress-only policy also
silently breaks unrelated outbound traffic, and specifically names DNS
as the category of egress traffic that was never explicitly allowed --
directly matching the chapter's own warn-box scenario and its stated
fix.