Strategy for large multi-team IaC projects

WHAT THIS TESTS This probes whether you can scale IaC beyond one engineer to a large organization, balancing reuse, isolation, safe promotion, and security.

A GOOD ANSWER COVERS Code structure and reuse: extract common patterns into versioned modules with clear input and output interfaces, so teams compose infrastructure from reviewed building blocks instead of copying code. Pin module versions so an environment upgrades deliberately. State management: do not use one giant state file; split state by environment and by logical component to shrink blast radius, reduce locking contention, and limit who can affect what. Use remote backends with locking and encryption. Environment promotion: deploy the same module code to dev, staging, and prod, varying only environment-specific inputs through variable files or workspaces, so what you tested is what you ship rather than maintaining divergent copies that drift. Promote by advancing a version through the environments. Secret management: never commit secrets; pull them from a dedicated secret manager at apply time, and grant pipelines least-privilege, short-lived credentials. Governance: enforce changes through CI with mandatory plan review, policy-as-code checks, and approvals on prod.

COMMON WRONG ANSWERS A single monolithic state file shared by all teams and environments, so one change can break everything and locking serializes every team. Copy-pasting an environment per stage, guaranteeing drift. Hardcoding secrets in code or variable files in Git. Letting anyone apply to prod with no review. No module versioning, so a module edit instantly hits every consumer.

LIKELY FOLLOW-UPS How do you split state effectively? Why version modules? How do workspaces compare to a directory-per-environment layout? How are secrets injected at apply time without persisting them?

ONE CONCRETE EXAMPLE A network module at version 1.4 is consumed by dev, staging, and prod, each with its own isolated state and a variables file for CIDRs and sizes. Secrets come from a vault at apply time. A change is tested in dev, the module version is bumped through staging, then promoted to prod via an approved CI pipeline, so the same reviewed code reaches every environment predictably.