Challenge 2: "Actively Monitored for Health" via max_fails Alone — Solution Walkthrough

What's actually true:

max_fails/fail_timeout does provide real, useful protection — a
server that starts failing real requests will genuinely get
temporarily routed around once it crosses the configured failure
threshold within the configured time window. This part of the team's
understanding is correct.

What's missing from the claim:

Per this chapter's own warning box, this mechanism is entirely
reactive: it only responds after real client requests have already
failed against that backend. It does not proactively probe or check
backend health ahead of time the way a genuine active health-check
system does. This means at least one real request has to fail and be
sent to a client before Nginx notices anything is wrong — there's no
background probing catching the problem before it affects real
traffic.

The correct framing:

"Actively monitored for health" overstates what open-source Nginx's
built-in mechanism actually does. A more accurate description would be
"protected by reactive failure tracking that limits how many real
requests hit a failing backend before it's temporarily excluded" —
useful, but not the same guarantee as proactive health checking, which
would require either a separate dedicated health-check tool or
Nginx Plus's own paid active health-check feature.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise directly applies this chapter's own warning box to a
realistic team misunderstanding, correctly separating what's genuinely
true (real protection exists) from what's overstated (calling it
"active" or "monitoring" when it's fundamentally reactive).