Challenge 1: Why Kernel-Mode Caching Is Cheaper Than User-Mode
Caching -- Solution Walkthrough

A user-mode output cache hit still requires the IIS worker process
(w3wp.exe) to be running and to handle the request -- it skips the
actual content-generation step (running the ASP.NET page, querying a
database, etc.), but the request still travels all the way from
http.sys up into user mode, into the worker process, gets matched
against the cache, and the cached content is returned from there. The
worker process is still very much involved, even though the most
expensive part (generating the content fresh) is avoided.

A kernel-mode cache hit is fundamentally different: http.sys, the
kernel driver that receives every incoming HTTP request before
anything reaches user mode at all, can serve a cached response
directly from within the kernel itself. The IIS worker process never
even wakes up for that request -- there's no user-mode/kernel-mode
transition, no worker process involvement, and no application code
execution of any kind. Because kernel-mode code runs with far less
overhead than a full round trip into a user-mode process, a
kernel-mode cache hit is dramatically cheaper in both CPU and latency
terms than even a fast user-mode cache hit.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader understands the distinction
isn't just "different cache storage location" but a genuine
difference in which layer of the system actually handles the
request -- kernel-only vs. still requiring the full user-mode worker
process -- which is exactly why the chapter frames kernel-mode
caching as "dramatically cheaper," not just "somewhat faster."