Challenge 3: Why web.config Is Architecturally an .htaccess, Not an nginx.conf — Solution Walkthrough

What actually determines the architectural comparison:

The comparison this chapter draws isn't about surface-level tooling —
whether the config is a GUI, XML, or plain-text directives — it's
about whether a directory-level file can override the server's
central configuration at request time without touching that central
config. That's the structural question that actually matters.

Why web.config matches Apache's model:

Like .htaccess, a web.config file lives directly inside an
application's own directory and can override settings from the
machine-wide applicationHost.config without an administrator needing
to edit that central file. This gives IIS the same practical
capability Apache's .htaccess provides: a way for someone without
access to the central configuration to still change behavior scoped
to their own directory.

Why the surface differences don't change this:

IIS Manager's GUI and the underlying XML format are just IIS's own way
of presenting and storing configuration — they don't change whether a
per-directory override capability exists. Nginx, despite using
plain-text directives that look more similar to Apache's own config
syntax on the surface, has no per-directory override mechanism at all
— making Nginx and Apache look similar in syntax but different in this
specific architectural capability, while IIS looks different in syntax
from both but shares Apache's actual override architecture.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the real basis for this chapter's own
comparison — presence or absence of a directory-level override
mechanism — is understood as separate from surface-level tooling
differences, which is exactly the point the chapter's IIS section
was making.