Would you keep every environment's infrastructure code in one repository or give each environment its own repository, and how does that choice affect who can approve production changes?

## Framing the question correctly The question sounds like repository layout, but the thing being decided is **where the approval and privilege boundary sits**. Repository split is one implementation of that boundary; there are cheaper ones. A candidate who answers only in terms of folders is answering a smaller question than the one asked. ## The case for one repository **Promotion stays a diff.** With every environment in one place, promoting a change is a one-line pin bump reviewed against the environment that already runs it. Across repositories, promotion means copying content between histories, which is re-implementation by another name, and re-implementation is where environments diverge. **Drift is visible.** Anyone can diff the production configuration against staging in one command. This sounds minor and is not: teams with split repositories routinely cannot answer "how does prod differ from staging?" without a manual audit. **One review culture, one set of tooling.** Formatting, linting, policy checks and pre-commit hooks are configured once. In N repositories they are configured N times and are stale in at least one of them. **Atomic cross-cutting change.** Renaming a shared convention or adding a required tag everywhere is one reviewable change, not a coordinated set of pull requests that half-lands. ## The case for repository-per-environment **A hard access boundary.** Repository permissions are a coarse, well-understood, auditable control. If a regulator or a customer contract requires that a named group of people cannot even propose changes to production, a separate repository with a separate access list is easy to demonstrate. **Blast radius of tooling.** A bad shared workflow, hook or lint rule affects everything in the repository at once. Splitting limits that. **Scale.** At very large estates a single repository accumulates history, ownership ambiguity and slow tooling. This is a real problem — and it is usually solved by splitting along *service or team* lines, not along environment lines, because that is where ownership actually differs. ## The costs of splitting, honestly Three environments means three sets of tooling, three review configurations and three histories that answer the same question differently. The shared components must become versioned external artifacts anyway — which is a good practice regardless — so the split buys nothing there. And every cross-environment operation, from "apply this fix everywhere" to "show me the difference", becomes manual. The predictable end state is that dev's repository is well maintained and production's is the one nobody dares refactor. ## The cheaper way to get the same boundary Most of what teams want from a repository split is available inside one repository: - **Path-based ownership rules**, so changes touching the production paths require review from a named group and cannot merge without it. - **Branch protection on the default branch**, so nothing reaches production paths without that review. - **Distinct credentials per environment**, scoped so the production credential exists only in the production pipeline context and is unusable elsewhere. - **Separate accounts or subscriptions**, so even a stolen credential is bounded. The crucial point: **the repository does not grant privilege — the credential does.** A team that splits repositories but keeps one powerful shared credential available to every pipeline has built a boundary that is documentation, not enforcement. Conversely, a single repository with strict path ownership and a production credential nobody can reach outside the protected path is genuinely locked down. When you argue this in an interview, argue it from where the privilege actually lives. ## The layout I would actually propose ``` components repo shared components, published as immutable versions infrastructure environments/dev, environments/staging, environments/prod path ownership: prod requires platform-team review credentials: one per environment, per account ``` Two repositories, not four: one for the reusable library where versioning discipline lives, one for the environment compositions where promotion is a visible diff. Beyond that, split by team or service when a single repository stops fitting the organisation — never merely to express that production is important. ## Where this becomes a genuine judgement call Separate repositories start to win when the people allowed to *see* production configuration are a strict subset of everyone else — a real situation in some regulated or multi-tenant contexts, since a configuration file reveals topology, naming and sometimes hostnames. Access control on reading, not on approving, is the argument that survives scrutiny. If reading is not restricted, prefer one repository and spend the saved effort on ownership rules and credential scoping.