Exercise 3: A Ready Pod Unreachable via Its Service Name — Two Categories of Cause — Possible Solution
====================================================================

Since the pod is confirmed Running and 1/1 Ready (ruling out
CrashLoopBackOff, ImagePullBackOff, and readiness-probe-related
causes entirely, per this chapter's own decision tree), the problem
lies in this chapter's "Running, Ready, but still unreachable" branch.
Two genuinely different categories of cause, per that section:

1. DNS RESOLUTION FAILURE, TIED TO A NETWORKPOLICY (Chapter 5). Per
   this chapter's own DNS section, "check whether a NetworkPolicy is
   blocking egress DNS traffic first." If the CALLING pod (the one
   trying to reach the Service, not necessarily the target pod itself)
   is selected by a NetworkPolicy that doesn't explicitly allow
   outbound DNS traffic, it may be entirely unable to RESOLVE the
   Service's name to an IP address in the first place -- meaning the
   request never even gets far enough to reach the target pod,
   regardless of that target pod's own healthy Ready status. This ties
   to Chapter 5's own exact warn-box scenario.

2. MISSING OR MISMATCHED SERVICE ENDPOINTS (Chapter 6). Per this
   chapter's own DNS section, also "confirm the target Service
   actually exists and has matching Endpoints in the first place."
   Even with DNS resolving correctly, if the Service's label selector
   (Chapter 6) doesn't actually match this specific pod's own labels
   (a typo, or a label that was changed after the Service was created),
   the pod would never appear in that Service's Endpoints list at all
   -- meaning the Service, even though it exists and resolves via DNS,
   has NOTHING to actually route traffic to, producing exactly the
   "no response at all" symptom despite the pod itself being perfectly
   healthy and Ready.

Both categories produce the SAME observable symptom (no response) from
a genuinely healthy, Ready pod -- which is exactly why this chapter
places this failure mode in its own distinct branch of the decision
tree, separate from the readiness-probe branch: the pod being healthy
and Ready doesn't rule out either of these two, entirely different,
networking-layer explanations.

WHY THIS WORKS AS AN ANSWER
------------------------------
This names two DIFFERENT chapters (5 and 6) as the source of two
genuinely distinct failure categories that both produce the identical
"pod is fine but unreachable" symptom, matching the chapter's own
explicit two-part DNS section rather than collapsing both possibilities
into one vague "check networking" answer.