Challenge 3: Unexpected Compression With No Local Configuration --
Solution Walkthrough

The most likely cause: compression in IIS is implemented as a module
that hooks the pipeline (working alongside output caching's own
ResolveRequestCache/UpdateRequestCache events), and modules are
frequently registered globally in applicationHost.config's
<globalModules>/<modules> sections at the machine level rather than
in any individual site or application's own web.config. A module
registered that way runs against every applicable request on the
server -- including this site's -- without that site ever needing to
mention it at all. Since the chapter's own warning box makes exactly
this point, the absence of any compression-related setting in this
site's own web.config doesn't mean compression isn't happening; it
means the module was very likely enabled at a level above this site,
where this site's own configuration was never consulted.

Where to look to confirm it: applicationHost.config's own
<globalModules> and <system.webServer>/<httpCompression> sections at
the machine level, rather than continuing to search this specific
site's web.config or application code for an explanation that isn't
there.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader applies the chapter's own
warning-box lesson to a concrete troubleshooting scenario -- that
"not configured here" doesn't mean "not running here," since a
globally-registered module applies regardless of what a specific
site's own web.config does or doesn't mention.