Exercise 2: Why Debugging the Application First Is Risky — Possible Solution
====================================================================

WHAT THE COLLEAGUE'S APPROACH SKIPS
------------------------------
Opening the app directly and reading its logs starts at the very top of
this chapter's practical ladder - the application layer - without
first confirming any of the four rungs below it (local connectivity,
DNS, network reachability, port/service reachability) are actually fine.

WHY THAT'S RISKY, PER THIS CHAPTER
------------------------------
Per the chapter's warn-box, "if DNS or network reachability was the
actual problem, none of that time was wasted on the real cause, because
the application was never going to work regardless of what's inside
it." Time spent reading application logs or debugging application code
is wasted if the real fault sits in a lower layer the application has
no visibility into or control over.

WHAT TO CHECK FIRST INSTEAD
------------------------------
Per this chapter, work the ladder bottom-up and stop at the first
failing rung: confirm local connectivity, then DNS resolution, then
raw network reachability (e.g. via ping), then port/service
reachability - only moving on to the application layer once everything
below it has been confirmed fine. The chapter notes this usually takes
less time than one detour into the wrong codebase.

WHY THIS WORKS AS AN ANSWER
------------------------------
It identifies exactly which layer the colleague's approach skips to,
explains the chapter's own stated reasoning for why that's wasteful
when the fault is actually lower down, and names the correct
lower-to-higher checking order instead of just asserting "check the
network first" without justification.