Exercise 1: Why a Shared Liveness/Readiness Check Is a Real Mistake — Possible Solution
====================================================================

WHAT EACH CHECK IS SUPPOSED TO CONTROL
------------------------------
Per this chapter, liveness failure causes "the orchestrator restarts
the container," while readiness failure causes "the instance is pulled
from the load balancer's rotation - not restarted." The two checks
trigger genuinely different, non-interchangeable responses.

THE PAYMENT-PROVIDER EXAMPLE
------------------------------
Per this chapter's warn-box, "a single shared check that's too broad -
for example, one that verifies a downstream third-party dependency is
reachable - can turn an unrelated outage into needless restarts. A
temporary blip in a payment provider's API should mean 'temporarily
stop sending this instance new requests' (a readiness concern), not
'kill and restart this perfectly healthy process' (a liveness
consequence)."

WHY SHARING THE CHECK CAUSES THE WRONG RESPONSE
------------------------------
Per this chapter, "with a shared check, the orchestrator can't tell
the two apart." If the same check backs both liveness and readiness,
a failure caused by the payment provider being briefly down produces
BOTH consequences - the instance gets pulled from rotation AND
restarted, even though the instance itself was never actually broken.
The process is perfectly healthy; only its ability to reach an
unrelated external service was temporarily affected, which should have
been a readiness-only concern.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly states what each check is supposed to trigger, uses the
chapter's own specific example (a payment provider outage) to show
what should happen, and explains precisely why a shared check produces
an inappropriate response (an unnecessary restart) when only a
readiness response was actually warranted.