Across a Terraform estate with many root modules, how do you decide which variable values are committed as tfvars files and which are injected at run time, and what goes wrong when a laptop and CI disagree?

## The question behind the question Terraform will take a value from six different places. That flexibility is fine for one root module and corrosive across thirty, because "where does this value come from" stops having a single answer and starts having a per-repository archaeology. The decision worth making explicitly is a *policy* about which tier each class of value is allowed to occupy. ## A workable default policy **Committed, in a per-environment file passed with `-var-file`:** environment and account names, region, CIDR blocks, instance sizes and counts, retention periods, feature toggles. These are configuration decisions. They belong in a file because they should be diffed in a pull request, blamed in `git log`, and identical whoever runs the command. **Injected at run time:** secrets, from the pipeline's secret store into `TF_VAR_<name>`; and identifiers the pipeline produces, such as a build or image version. Both are genuinely per-run, and neither can be reviewed in advance because neither exists until the run starts. **Nothing else.** In particular, no standing configuration in an engineer's shell profile, and no ad-hoc `-var` in a job definition that quietly redefines what an environment is. ## Why the environment tier is the dangerous one `TF_VAR_` ranks below every tfvars file, above only the default. That has two consequences worth designing around. First, a committed `*.auto.tfvars` silently overrides anything the pipeline exports, so injected variable names must never appear in a committed file — worth enforcing with a small repository check, because the failure is a green run with the wrong value rather than an error. Second, an exported value that exists on one machine and not another produces plans that differ with no visible cause; the diff is real, both runs succeed, and the disagreement surfaces later as drift or as an apply that undoes someone else's change. ## Making machines agree The practical mechanism is that nobody types a raw `terraform` command. A wrapper — a `Makefile` target, a small script — assembles the same invocation for humans and for CI: ```bash # make plan ENV=prod terraform -chdir=envs/$(ENV) plan \ -input=false \ -var-file=$(ENV).tfvars \ -out=tfplan ``` Everything the run depends on is now visible in one place and version-controlled. A developer who wants a different value edits the file and opens a pull request, which is exactly the behaviour you want. Combined with `-input=false` and required variables that carry no default, an incomplete invocation fails loudly instead of falling back to something plausible. ## Auditability: explaining an apply after the fact A month later someone asks why production got a particular value. You want the answer to come from the repository plus the job log, not from reconstructing a shell. That means: log the full Terraform command line, log the *names* of injected variables (never the values of secrets), and use a saved plan file so the apply consumes exactly what the plan computed rather than re-resolving variables at apply time. If a `-var` override was used during an incident, it should be visible in the log and followed by a pull request that makes it permanent or removes it. ## The tradeoff you are actually making Committing more values buys reviewability, reproducibility and a single answer to "what will this deploy". It costs a pull request for every change, including trivial ones, and it means values must be safe to store in the repository. Injecting more buys flexibility and keeps secrets out of version control, at the price of runs that cannot be explained by reading the code and of laptop-versus-CI divergence. Most estates should sit far towards the committed end and treat every exception as something that has to be justified and named. The clearest signal that a repository has drifted the other way is a `README` explaining which environment variables you must export before running `terraform plan` — at that point the configuration lives in a wiki, not in the code. ## What an interviewer is listening for Not the tier list — that is the middle-tier answer. They want to hear that you have a rule, that the rule is enforced by something other than discipline, and that you can name the specific failure each part of it prevents: the silent override, the machine-dependent plan, the unexplainable apply.