A municipal team must stand up matching test and production environments without rebuilding everything through one-off portal clicks. What practice addresses that goal?
Select an answer to reveal the explanation.
Short Explanation
Want twin environments that actually match? Write the blueprint once — that is infrastructure as code — and deploy it twice. Portal memory games drift the moment someone forgets a setting.
Full Explanation
Infrastructure as code defines environments in templates or code so deployments are repeatable. The municipal team authors the desired configuration once, stores it as a definition, and deploys that definition to test and production (with appropriate parameters/environment separation). Consistency comes from the shared blueprint, not from hoping two humans click the same portal path perfectly twice.
Recreating every resource by memory in the portal maximizes configuration drift: missed SKUs, forgotten settings, and undocumented exceptions. Storing environment diagrams only as photos in a shared mailbox captures pictures, not deployable desired state. Disabling Azure Resource Manager so no deployment API can enforce consistency removes the management fabric Azure deployments rely on and works against the goal.
Exam caveat: IaC improves consistency but still needs parameter discipline, secrets handling, and environment-specific values—identical definitions with wrong parameters can still diverge. Operational check: take a small resource set (resource group, storage account, basic networking stubs as appropriate), express it in a template or other IaC form, deploy twice to separate resource groups, and diff the resulting configurations.