Challenge 2: Nginx's No-Override Model and a Version-Controlled Workflow — Solution Walkthrough

Why the lack of a .htaccess-style mechanism fits this team well:

This team already manages every configuration change through version
control and an automation tool — meaning every change to the server's
behavior is expected to go through a deploy step, get reviewed, and
leave a record in the config's own history. Nginx's model assumes
exactly this: there is no separate, informal path for changing
behavior outside the central config files, so every single
configuration change this team makes necessarily goes through their
existing deploy pipeline, with nothing able to bypass it.

Why this isn't a missing feature here:

A .htaccess-style override would actually work against this team's own
workflow — it would create a second way to change server behavior that
doesn't go through version control or their deployment tool at all,
undermining the very discipline the team has already built around
config-as-code. Nginx's centralized-only model isn't lacking a
capability this team needs; it enforces the same discipline the team
has already chosen for itself.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own warning box to a concrete
team whose existing workflow specifically benefits from Nginx's
design choice — correctly identifying that "no override mechanism"
and "an infrastructure-as-code workflow" reinforce each other, rather
than treating the absence of a feature as automatically a downside.