Challenge 2: A 500.19 From a Locked Section -- Solution Walkthrough

What's happening: the system.webServer/authentication section ships
with overrideModeDefault="Deny" in applicationHost.config by default,
specifically because it's security-sensitive. A web.config attempting
to set a Deny-mode section isn't silently ignored -- IIS refuses to
serve the request at all and returns HTTP 500.19, a configuration
error, naming the specific section and config source responsible.
This is exactly why a developer without machine-level access can't
quietly re-enable or change authentication behavior from their own
application's web.config: the lock exists precisely to stop that.

The one legitimate way to still grant that specific application a
different authentication setting: an administrator with access to
applicationHost.config itself adds a <location path="..."> block
there, scoped to that site or subdirectory's path, containing the
desired <authentication> settings. The override still lives entirely
inside applicationHost.config -- it is machine-level configuration
written by someone with the necessary access, not a change the
application's own web.config can make. This grants the one path a
different value without unlocking the authentication section for
every other application on the server.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader distinguishes "locked" from
"fixed forever" -- a Deny-mode section can still be varied per site,
but only from the machine level via a <location> tag, never from a
lower-level web.config, which is the precise distinction the chapter
draws between application-level and machine-level configuration
access.