In Terraform, which variable-definition files does the CLI load automatically, and how do you supply values from a file it does not auto-load, such as prod.tfvars?

## What "auto-loaded" means A `.tfvars` file is just a set of `name = value` assignments for the input variables declared in the root module. Terraform reads some of these files without being told to, purely because of their filename. Everything else is an ordinary file that has no effect until you point at it. Knowing which is which is the difference between "my value is being ignored" and "where did that value come from?". ## The exact list From the current working directory, Terraform loads: - `terraform.tfvars` - `terraform.tfvars.json` - any file matching `*.auto.tfvars` or `*.auto.tfvars.json`, processed in lexical order of their filenames That is the whole list. `prod.tfvars`, `eu-west-1.tfvars`, `vars/common.tfvars` and `values.tf` (a `.tf` file cannot assign variable values at all — it declares them) are not in it. ## Everything else needs -var-file ```bash terraform plan -var-file=envs/prod.tfvars terraform plan -var-file=common.tfvars -var-file=envs/prod.tfvars ``` `-var-file` may be given more than once and accepts both HCL and JSON files. The options are processed in the order they appear, so a later file overrides an earlier one for variables both of them set. Command-line file options also sit above every auto-loaded file in Terraform's precedence order, so a `-var-file` value wins over the same variable set in `terraform.tfvars`. Importantly, `-var-file` **adds** a source; it does not switch auto-loading off. If `terraform.tfvars` is present it is still read, and any variable set only there still applies. That is a frequent source of "but I passed prod.tfvars" confusion in a repo that also carries a committed `terraform.tfvars` full of developer defaults. ## Order among the auto files Lexical order means string order, not numeric order and not the order you would like. `10-network.auto.tfvars` sorts *before* `2-network.auto.tfvars`, because `1` precedes `2` character by character. Since later files override earlier ones, `2-network.auto.tfvars` wins. Zero-padding (`02-`, `10-`) restores the intuitive result. Relying on this ordering at all is fragile; prefer one file per concern with no overlapping variables. ## The working directory, not the repository root Auto-loading looks in the directory Terraform treats as current. With `terraform -chdir=envs/prod plan`, Terraform switches to `envs/prod` first, so the `terraform.tfvars` inside that directory is the one loaded — not the one at the repository root. A `.tfvars` file two directories up is never found automatically; if you want shared values, pass them explicitly with `-var-file=../common.tfvars` or generate them. ## Two common repository layouts **Directory per environment.** `envs/dev/`, `envs/prod/`, each its own root module with its own `terraform.tfvars`. Auto-loading is safe here, because being in the directory *is* choosing the environment, and the backend configuration in that directory pins the state too. **One root module, a file per environment.** `prod.tfvars`, `dev.tfvars` next to a single configuration. Here the files deliberately do **not** end in `.auto.tfvars`, so every run must name one. The cost is that forgetting `-var-file` gives you a run with defaults instead of a loud failure — which is why variables that must never be guessed are declared with no default, so an omitted file becomes an error rather than a surprise. ## Failure modes worth recognising - A committed `terraform.tfvars` in a shared root module quietly seeds everyone's plan, including CI's. - Renaming `dev.tfvars` to `dev.auto.tfvars` makes it apply everywhere, including production runs from that directory. - A value for a variable the root module does not declare produces a warning about a value for an undeclared variable and is ignored, so a typo'd name in a `.tfvars` file silently does nothing. - Terraform does not look inside subdirectories, so `vars/prod.auto.tfvars` is not auto-loaded even though the name matches. ## The mental model Auto-loading is a convenience for "values that always apply in this directory". Anything that varies per run — the environment, a release version, a secret — should be named explicitly on the command line, where a reader of the CI job log can see exactly what went in.