Exercise 2: Why Low CPU Doesn't Rule Out a Real Problem — Possible Solution
====================================================================

WHY LOW CPU CAN BE MISLEADING
------------------------------
Per this chapter's warn-box, "a process stuck waiting on a slow remote
call - a database query over the network, an outbound API request -
often shows up as low CPU usage, since it genuinely isn't doing any
computation while it waits." The process isn't idle because there's no
work to do - it's idle because it's blocked, waiting for a response
from something else over the network.

WHY THE COLLEAGUE'S CONCLUSION IS WRONG
------------------------------
Per this chapter, "that can look like 'the app isn't under any
resource pressure' when what's actually happening is the app is
stuck, doing nothing, purely because something it depends on hasn't
answered yet." The colleague is reading "low CPU" as "no resource
problem exists," when in this specific case low CPU is actually
consistent with a real, active problem - the process just isn't the
kind of problem CPU metrics are designed to reveal.

WHAT LOW CPU ALONGSIDE SLOWNESS ACTUALLY SUGGESTS
------------------------------
Per this chapter, "low CPU alongside a slow response is itself a real
clue pointing toward network or dependency latency, not away from it."
Rather than concluding nothing is wrong, this specific combination
should redirect the investigation toward network/dependency causes
(this chapter's own subject), not toward assuming the app is
fundamentally broken with no explainable cause.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the specific mechanism by which a network-blocked process
produces low CPU readings, and correctly identifies that this
chapter treats the combination as evidence pointing toward network
causes rather than evidence that nothing is wrong.