Exercise 1: Why Connect via a Service's DNS Name, Not a Pod IP — Possible Solution
====================================================================

Per Chapter 3, a pod's IP address is NOT stable -- pods are treated as
disposable "cattle," and when a pod fails, is replaced during a
rolling update (Chapter 5), or is recreated for any reason at all, it
typically comes back with a brand new IP address. Chapter 3 explicitly
warned that "an application that hardcodes a specific pod IP will
break the first time that pod is recreated."

A Service solves this specific problem directly: per this chapter, it
provides "a single, stable IP address and DNS name that automatically
routes to a dynamic, changing set of pods." The Service's own address
NEVER changes, even as the individual pods behind it are constantly
being replaced -- because the Service tracks WHICH pods currently
match its label selector via its Endpoints list, updated automatically
and near-instantly every time a pod is created or destroyed.

Connecting to a Service's DNS name means the application never needs
to know or track any individual pod's IP at all -- it simply asks for
"web-service" (or whatever the Service is named), and Kubernetes'
in-cluster DNS and the Service's own routing transparently handle
directing that request to whichever specific pod happens to be
healthy and available AT THAT MOMENT, without the application code
ever needing to be aware that the underlying pod population is
constantly changing underneath it.

If the application instead hardcoded a specific pod's IP, it would
work only until that specific pod was inevitably replaced (which, per
Chapter 3, "could happen at literally any time, unpredictably") -- at
which point the hardcoded address would point at nothing, and the
connection would break, exactly the scenario Chapter 3's warn-box
described.

WHY THIS WORKS AS AN ANSWER
------------------------------
This connects Chapter 3's pod-disposability warning directly to this
chapter's own Service mechanism, showing specifically HOW the Service
solves the exact problem Chapter 3 only flagged without yet resolving
-- a stable address abstracted over a genuinely unstable, constantly-
changing set of individual pod IPs.