How would you lay out an infrastructure-as-code repository so the same infrastructure can be deployed to dev, staging and production?

## The property you are actually protecting The reason this question is asked in nearly every infrastructure interview is that it has one right answer at the level of principle and several defensible answers at the level of layout. The principle: **the same code must produce every environment, and environments must differ only by input values.** If staging and production are two hand-edited copies of the same directory, they start identical and diverge by a small amount every month, and by the time you need staging to rehearse a production change it no longer resembles production. A change you validated in one environment must be the *same change* you then apply in the next. ## Layer 1: reusable components Underneath any layout is a set of components — network, data store, cluster, service — each defined once with a declared input interface (region, size, replica count, retention, tags) and a declared set of outputs other pieces consume. These are environment-agnostic on purpose. They should not contain the string `prod` anywhere. The moment a component knows which environment it is in, you have lost the ability to test it anywhere except the environment it was written for. ## Layer 2: the environment layout Three shapes are common. **One top-level configuration plus a values file per environment.** The repository holds a single root that composes the components, and a values file for each environment supplying sizes, counts, CIDRs and names. You pick the file at run time. ``` components/network/ components/database/ root/ <- one composition values/dev.vars values/staging.vars values/prod.vars ``` Maximally DRY, minimal duplication, and the diff between two environments is literally the diff between two small files — which is a genuinely useful property in a review. The cost: every environment must be *structurally* identical, because there is only one composition. The first time production needs a resource that dev does not have, teams start adding conditionals to the shared root, and it decays. **A directory per environment, each with its own thin root.** Each environment owns a small composition file that calls the shared components with its own values. ``` components/... environments/dev/ environments/staging/ environments/prod/ ``` Slightly repetitive, and that is the point: the repetition is confined to a handful of wiring lines, while the substance still lives in the shared components. Production may add a component the others lack, or set a stricter deletion guard, without a conditional anywhere. The risk is neglect — if nobody diffs the environment roots against each other, they drift structurally. Many teams add a review habit or a lint check that compares them. **One configuration with a switchable named environment.** Some tools offer a built-in per-environment selector over a single configuration, keeping a separate recorded state per name. It is the fastest to set up and the easiest to misfire: one working directory, one code path, and often one set of credentials, so "apply to the wrong environment" is a single mistyped selector away. It suits short-lived or throwaway environments far better than it suits production. ## Isolation is not optional Whatever the layout, these must be per-environment: **the recorded state** (so a destroy plan computed against dev can never enumerate production resources), **the credentials** (so the dev pipeline holds no production authority), and ideally **the account or subscription boundary** itself. A shared credential defeats every layout choice above; the directory structure is documentation, but the credential is the actual control. ## Non-production is never identical A good answer admits the tension. Production is bigger and more expensive; a faithful copy would cost as much. So you keep the *shape* identical — same components, same wiring, same topology — and let scalar values differ: fewer replicas, smaller instance classes, shorter retention, no multi-region replica. Where the shape must differ, prefer expressing it as "this environment composes one extra component" rather than "the shared component behaves differently in prod". ## Promotion falls out of the layout When the layout is right, promoting a change is boring: bump the version of a shared component in the dev root, apply, exercise it, then make the identical bump in staging, then in prod. Each step is a reviewed change with its own preview. When the layout is wrong — three hand-maintained copies — promotion is re-implementation, and every re-implementation is a chance to differ. ## Answering in an interview State the invariant first, then pick a layout and defend it, then name the isolation requirements. Interviewers are listening for whether you understand that the folder structure is a means to an end, and that the end is: what ran in staging is what runs in prod.