Exercise 1: Why "500 Error" Alone Doesn't Say Which Course Applies — Possible Solution
====================================================================

THE SIX CAUSES, PER THIS CHAPTER'S TABLE
------------------------------
A firewall blocking the app's database connection (netdiag1), the
server OOM-killed from genuine memory exhaustion (perfdiag1), an
unhandled exception only visible in the application's own stack trace
(log1), a slow query exhausting the connection pool, a stale cache
entry serving corrupted data, and a half-rolled-out deployment mixing
old and new code (all three: this course).

WHY THE SAME SYMPTOM MAPS TO SO MANY DIFFERENT CAUSES
------------------------------
Per this chapter, "the API returned a 500' is one symptom that
genuinely could be caused by something in any of this subject's four
courses." A 500 status code only communicates that something failed
somewhere in the request's handling - it carries no information about
which layer (network, OS resource, general application error, or the
specific application-layer categories this course covers) actually
produced that failure.

WHY THIS MEANS THE SYMPTOM ALONE ISN'T ENOUGH
------------------------------
Since a single symptom (a 500 response) is consistent with six
genuinely different underlying causes spread across four different
diagnostic domains, knowing only "it returned a 500" gives no basis for
deciding which course's own techniques to reach for first. Per this
chapter, "knowing which of the four courses actually owns a given cause
is most of the battle" - implying the symptom itself doesn't answer
that question; further investigation is required to narrow it down.

WHY THIS WORKS AS AN ANSWER
------------------------------
It reproduces the six causes accurately, explains that a 500 status
code by itself carries no information distinguishing between them, and
connects that to the chapter's own point that identifying which course
applies takes real diagnostic work, not just noting the symptom.