An infrastructure team finds the same 200 lines defining a VPC, subnets and route tables copy-pasted into five root configurations, and the copies have started to drift as fixes land in only some of them. What is the best next step?
Select an answer to reveal the explanation.
Short Explanation
Copy-paste is a module crying out to be born. Pull the pattern into one versioned module, publish it, and you give every team the same fix, on their own upgrade schedule, instead of five slowly diverging copies.
Full Explanation
Repetition of the same resource pattern across configurations is the classic signal to extract a module. A single module captures the VPC, subnet and routing logic once, exposes the genuinely variable parts as input variables and the useful IDs as outputs, and is published with semantic versions to the private registry. Each root configuration then calls the module with its own inputs and version constraint, so a fix lands once and consumers adopt it deliberately by bumping the version. Merging five roots into one state removes duplication by enlarging the blast radius, putting unrelated environments into a single plan and apply. Sharing a .tfvars file aligns input values, but the duplicated code itself still diverges, which is the actual problem. Symbolic links share files without versioning, so every consumer receives every edit immediately with no review or controlled rollout, and links do not travel reliably through VCS-driven workspaces. Exam caveat: moving existing resources into the module changes their addresses, so pair the adoption with moved blocks to avoid destroy and recreate. Operational check: after adopting the module in one root, run a plan and confirm it shows only moved addresses and no additions or destructions before repeating for the others.