Challenge 1: Why /api Was Made Its Own Application -- Solution
Walkthrough

If /api had been left as a plain subfolder (a virtual directory at
most) under the storefront's own application, it would have shared
the storefront's own Application Pool entirely -- per Chapter 5, a
virtual directory always inherits its parent's pool and has no
Application Pool assignment of its own. That means both applications
would also share one worker process and, critically, one Rapid-Fail
Protection circuit breaker (Chapter 2). If the reporting API's own
code crash-looped -- entirely plausible for an internal, less
heavily-tested reporting tool -- Rapid-Fail Protection's default
threshold (5 crashes in 5 minutes) would trip for the shared pool as
a whole, taking the entire pool offline and returning 503 to every
request against it, including the customer-facing storefront, which
had nothing wrong with it at all.

Making /api its own application, per Chapter 5, gives it its own
Application Pool assignment (Step 1) and its own isolated .NET
AppDomain -- a completely separate worker process from the
storefront's own StorefrontPool. If /api's own pool crash-loops and
goes offline, only ReportingApiPool is affected; StorefrontPool is a
different process entirely, with its own separate crash count, and
keeps serving customer traffic normally. This is exactly the
deliberate blast-radius control Chapter 5 named as the real reason
production deployments often split a site into multiple small
applications rather than one large one.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader can connect Chapter 2's
Rapid-Fail Protection (a pool-wide circuit breaker) and Chapter 5's
application-boundary isolation together, in the same way Chapter 5's
own exercise 2 did -- recognizing that the isolation benefit here
specifically protects the storefront from a crash in an unrelated,
lower-quality-bar internal tool sharing the same site.