Exercise 2: Why Not Assume Every 500 Is Application-Layer — Possible Solution
====================================================================

THE WARNING, PER THIS CHAPTER
------------------------------
Per this chapter's warn-box, "it's just as easy to over-correct the
other direction - assuming every 500 error is automatically an
application-layer problem and diving straight into connection pools or
caching, skipping the network and resource checks entirely."

WHY THIS IS A REAL RISK, GIVEN THIS CHAPTER'S OWN TABLE
------------------------------
Per this chapter's own six-cause table, half of the listed causes of
"the API returned a 500" actually belong to the other three courses -
a firewall issue (netdiag1), OOM exhaustion (perfdiag1), or an
unhandled exception better diagnosed through logs (log1). Jumping
straight to this course's own territory would miss those causes
entirely, even though this course's content is real and relevant to
the other half of the table.

WHY THE SAME DISCIPLINE APPLIES IN BOTH DIRECTIONS
------------------------------
Per this chapter, "the discipline this whole subject shares - check
first, in the right order, rather than guessing which layer feels most
likely - still applies here." The mistake of assuming a cause without
checking is the same mistake whether it points at the network, a
resource, or the application layer - none of the four courses is a
safe default to skip straight to.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the chapter's own explicit warning, explains why the risk is
real by pointing back to the chapter's own six-cause table, and
connects it to the shared cross-course principle of checking rather
than guessing, applied symmetrically in both directions.