Exercise 1: Monitoring vs. Observability, Using the "First Five Minutes" Habit — Possible Solution
====================================================================

Explanation:

Monitoring means watching for failure modes someone already anticipated
and built a check for -- a CPU-usage dashboard, a disk-space alert, a
"is the process still running" probe. It only ever answers questions
decided in advance, before the incident happened.

Observability is the ability to ask a genuinely NEW question about a
system's internal state, using only its already-collected external
outputs (metrics, logs, traces), without shipping new code first. This
is exactly why cloud2-4's own "first five minutes" habit matters in the
first place -- during a real, novel incident, you usually don't yet
know which specific question to ask. If the only tools available are
pre-built dashboards for problems someone already thought of, and the
current incident doesn't match any of them, monitoring alone leaves you
stuck. Observability is what lets you improvise during those first five
minutes -- exploring raw metrics, correlating logs via a request's own
trace ID, and following a slow request's actual path -- rather than
being limited to whatever panels happened to get built in advance.

Put simply: monitoring answers the questions you thought to ask ahead
of time; observability supports answering the question you're only
now, mid-incident, realizing you need to ask.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes the two terms by what kind of question each one can
answer (anticipated vs. unanticipated), then explicitly ties that
distinction back to cloud2-4's own "first five minutes" material,
showing why observability specifically matters during the earliest,
most uncertain phase of a real incident.