Challenge 2: Why Converting /support Into Its Own Application Fixes
the Cross-Impact Problem -- Solution Walkthrough

While /shop and /support were both plain subfolders sharing the
site's single Application Pool, they also shared one worker process
(w3wp.exe) and one Rapid-Fail Protection circuit breaker. When
/support's own crash-looping bug caused its worker process to crash
repeatedly, Rapid-Fail Protection's default threshold (5 crashes in 5
minutes, per Chapter 2) tripped for the entire pool -- not just for
/support -- taking the whole pool offline and returning 503 to every
request against it, including requests for /shop, which had nothing
wrong with it at all. The isolation Rapid-Fail Protection provides
only applies at the granularity of a single Application Pool; it has
no way to distinguish which path within that pool actually caused the
crashes.

Converting /support into its own application with its own dedicated
Application Pool changes this entirely: /support's worker process
and its own Rapid-Fail Protection circuit breaker are now completely
separate from /shop's. If /support keeps crashing, its own pool goes
offline and its own 503s are scoped to /support alone -- /shop's pool
is a different process with its own crash count, unaffected by
whatever is happening in /support's pool. The blast radius of a
crash in /support is now contained to /support specifically, rather
than extending to every other feature that happened to share the
same pool.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader can connect Chapter 2's
Rapid-Fail Protection mechanism (a pool-wide circuit breaker) to this
chapter's own application-boundary isolation concept, recognizing
that the cross-impact happened specifically because Rapid-Fail
Protection operates per-pool, and that giving /support its own pool
is what actually breaks that shared fate.