Multiple city departments need the same VPC networking pattern in IaC. Copy-pasting the networking code into each department repo has caused drift. What IaC approach should they adopt?
Select an answer to reveal the explanation.
Short Explanation
A shared IaC module is the city’s standard curb-cut template — every department pours the same pattern with parameters, instead of freehanding concrete and wondering why the gutters never match.
Full Explanation
When multiple city departments need the same VPC networking pattern, copy-pasting IaC into each repo causes drift: one team patches a security-group rule while others remain vulnerable or incompatible. Publishing a reusable, parameterized module that each department consumes for the shared VPC pattern centralizes fixes, enforces a common baseline, and still allows parameters for CIDR ranges, tags, or environment-specific values.
Encouraging each department to rewrite networking from memory during outages maximizes inconsistency and outage duration. Storing networking only as screenshots in a shared drive is not executable infrastructure and cannot be planned or applied. Disabling version control for network definitions to speed edits removes audit trails and peer review for critical municipal connectivity.
Exam caveat: modules must be version-pinned by consumers so a breaking module release does not surprise every department simultaneously. Operational check: publish module vX.Y.Z, consume it from two department stacks with different parameters, apply in non-prod, and confirm both converge to the shared pattern without forked copies. Version the shared VPC module semver-style and announce breaking parameter changes as MAJOR so departments can upgrade deliberately rather than discovering broken plans during a change window.