A public-works team must rebuild the same multi-resource VPC, security groups, and load balancer stack the same way every quarter. Which approach best supports that repeatable provisioning?
Select an answer to reveal the explanation.
Short Explanation
If you have to rebuild the same city block of resources every quarter, write the blueprint once—infrastructure as code like CloudFormation—rather than clicking through the console from memory.
Full Explanation
A public-works team that must rebuild the same multi-resource VPC, security groups, and load balancer stack the same way every quarter should use infrastructure as code such as AWS CloudFormation (or an equivalent IaC tool). IaC templates declare the desired resources and relationships so each deployment creates a consistent environment, supports change sets, and reduces configuration drift between quarterly rebuilds or between lab and production accounts.
Relying only on console clicking for every identical multi-account rebuild invites human error and undocumented drift. Manual screenshot runbooks are fragile sources of truth: they age quickly and cannot be diffed or validated like template code. Amazon SES email templates send email; they do not invent VPC subnet CIDRs or provision network infrastructure.
Exam caveat: IaC questions emphasize repeatability, multi-resource consistency, and reducing manual console variance. CloudFormation is the native AWS example most often named at Cloud Practitioner level; the concept also covers tools that call the same APIs.
Operational check: encode the public-works baseline VPC, security groups, and load balancer in a CloudFormation template stored in git; parameterize CIDRs and tags per environment; run change sets before production applies; and use stack policies or pipeline approvals so quarterly rebuilds are auditable. After deploy, compare stack outputs against the city’s network diagram before attaching workloads.