Challenge 3: Why ARR's Separate-Module Requirement Is a Real Architectural Difference — Solution Walkthrough

What the difference actually is:

Apache's mod_proxy and Nginx's proxy_pass are both part of each
server's own normal way of working — Apache's module system commonly
includes mod_proxy as a module you enable, and Nginx treats reverse
proxying as such a core use case that proxy_pass is one of its single
most common real-world directives. IIS, by contrast, has no reverse
proxy capability out of the box at all — Application Request Routing
has to be downloaded and installed as a separate component, along
with the URL Rewrite module it depends on, before any reverse-proxy
configuration is even possible.

Why this isn't just a naming difference:

A naming difference would mean all three servers can do the same
thing out of the box, just calling it something different. That's not
the case here — a fresh IIS install genuinely cannot reverse-proxy
anything until an administrator deliberately installs additional
software on top of it, while a fresh Apache or Nginx install already
has the necessary module available or built in. This changes what's
actually possible immediately after installation, not just what a
capability is called.

Why this matters practically:

Anyone planning an IIS-based reverse-proxy deployment needs to budget
for this extra installation and dependency step from the start — it's
not simply a matter of writing different configuration syntax for an
equivalent built-in feature, the way, say, Apache's ProxyPass and
Nginx's proxy_pass differ only in syntax for functionally the same
built-in capability.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that "built-in vs. add-on" is understood as a
genuine capability difference with real deployment consequences,
distinct from the syntax-only differences (like ProxyPass vs.
proxy_pass) that separate Apache and Nginx from each other elsewhere
in this chapter.