Challenge 3: Why a Rewrite Pointed at a Backend Server Is ARR's
Territory, Not URL Rewrite's -- Solution Walkthrough

The rule syntax genuinely does look almost identical either way --
an action of type="Rewrite" with a url attribute is the same
mechanism whether that url points at a local resource
(article.aspx?slug={R:1}) or at an entirely different server
(http://backend-server/{R:1}). The syntax alone doesn't distinguish
them. What distinguishes them is what actually has to happen
underneath: rewriting to a local resource still involves exactly one
IIS installation serving exactly one request from its own handlers.
Rewriting to a different backend server's URL means this IIS
installation now has to forward the request to that other server,
receive its response, and return that response back to the original
client -- which is proxying, not rewriting, regardless of which
module's configuration syntax was used to set it up.

Chapter 1 named this exact distinction as this course's deliberate
scope boundary: URL Rewrite's own job is redirecting or rewriting
requests within a single IIS installation, and it can be paired with
ARR specifically to add the actual reverse-proxying capability (ARR
provides the proxying mechanism; URL Rewrite provides the rule
language deciding when and where to proxy to). Since ARR itself is a
genuinely optional add-on most IIS installations never install --
unlike Apache's mod_proxy or Nginx's proxy_pass, which are built in
-- Chapter 1 chose not to give reverse proxying a dedicated chapter
in this course, even though the specific rule syntax enabling it
technically lives inside URL Rewrite's own configuration.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader distinguishes syntax from
underlying mechanism -- recognizing that the same action type and
url attribute can express two behaviorally different things (local
rewrite vs. reverse proxy), and connecting that specifically to why
this course's own scope boundary from Chapter 1 excludes the
proxying case despite it appearing inside the same module's
configuration.