A regional library system needs twenty nearly identical Azure environments for branch sites and finds portal-only builds too slow and inconsistent. What approach matches the scale need?
Select an answer to reveal the explanation.
Short Explanation
Twenty lookalike branch stacks are a stamp-and-repeat problem, and infrastructure as code is the stamp. Portal-clicking twenty times invites twenty different mistakes.
Full Explanation
Using infrastructure as code to deploy repeatable environments from a shared definition matches a regional library system that needs twenty nearly identical Azure environments. Scale and consistency favor stamp-and-repeat from one reviewed blueprint over twenty independent click tours through the portal.
Hiring twenty separate operators to click the same portal path with no shared definition invites twenty subtle differences and slow delivery. Creating each branch by photographing another branch’s portal screen captures appearance, not deployable state. Avoiding templates because identical environments are “impossible” in Azure is false: Azure deployments are designed to be driven repeatedly through Resource Manager from definitions, with parameters for the few values that should differ.
Exam caveat: identical does not mean zero parameters—names, address spaces, and secrets usually differ per branch while the structural definition stays shared. Operational check: parameterize branch-specific values, deploy the shared definition to two pilot branch resource groups, compare inventories, then proceed to broader rollout only after drift checks pass. Prefer a pilot of two or three branches before mass rollout so parameter mistakes are cheap to correct.