Challenge 2: Why /product.aspx Can't Just Be Added to the Kernel-Mode
Cache -- Solution Walkthrough

This wouldn't work as intended, because the storefront's own product
pages are already subject to Step 5's "Friendly Product URL" rewrite
rule (mapping /product/123 internally to product.aspx?id=123), and
per Chapter 9's own warning, content that passes through an active
URL Rewrite rule is ineligible for kernel-mode caching. Kernel-mode
caching only works for content http.sys itself can safely serve
without any user-mode involvement -- and because the actual response
for a rewritten URL depends on rule logic that only runs in user
mode, IIS can't treat it as safely kernel-cacheable.

Adding product.aspx to the same kernel-mode caching profile used for
.css files (Step 8) wouldn't produce an error, but it also wouldn't
produce the intended speedup -- requests for rewritten product URLs
would still fall through to the worker process every time, exactly
as they did before, silently missing the kernel-mode cache with no
error message anywhere to explain why. The .css files in Step 8 work
as kernel-cached content specifically because they're static,
anonymous, and never touched by the rewrite rules that apply only to
the storefront's own product pages -- the two aren't equivalent
cases, even though they're served by the same site.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader applies Chapter 9's own named
kernel-mode-caching gotcha to a concrete capstone decision, correctly
identifying that Step 5's rewrite rule -- not some unrelated
configuration mistake -- is specifically what disqualifies the
rewritten product pages from the same caching treatment as the
static assets.