Why does Terraform reject an input variable inside a backend block, and how do you point the same configuration at a different state bucket per environment given that restriction?

## Why the restriction exists Terraform's evaluation has a bootstrap problem. Variables can come from `.tfvars` files, `TF_VAR_` environment variables, or the CLI; locals derive from variables; data sources require a configured provider; provider configuration can itself reference variables. All of that evaluation happens *within a run*, and a run begins by loading state. So the backend cannot depend on anything Terraform computes, because nothing has been computed yet — the backend is how Terraform finds out what already exists. Concretely, this fails: ```hcl terraform { backend "s3" { bucket = var.state_bucket # Error: Variables not allowed key = "${var.env}/terraform.tfstate" } } ``` The same restriction covers `local.`, `data.`, `path.module`, and function calls. Literals only. ## Partial configuration The designed escape hatch is to omit arguments and supply them at `terraform init`. Any subset can be omitted — including all of them, leaving `backend "s3" {}`. ```hcl terraform { backend "s3" { region = "eu-west-1" # same everywhere encrypt = true } } ``` Then per environment: ``` # envs/prod.s3.tfbackend bucket = "acme-tfstate-prod" key = "platform/network/terraform.tfstate" ``` and `terraform init -backend-config=envs/prod.s3.tfbackend`. The `.tfbackend` extension is a convention, not a requirement — the file is HCL key/value pairs with no surrounding block. You can also pass individual settings as `-backend-config="bucket=acme-tfstate-prod"`, repeated as needed, and mix files with flags where later values win. Credentials should not go in these files: the AWS, Google and Azure backends all pick up the normal provider credential chains and environment variables, so the checked-in file carries only location, never secrets. Because typing the flag every time is error-prone, teams usually wrap it — a `make init ENV=prod` target, a shell wrapper, or the `TF_CLI_ARGS_init` environment variable, which appends arguments to every `init` invocation in that shell. ## Re-pointing an existing working directory Terraform caches the backend configuration it last initialised in `.terraform/terraform.tfstate`. If you re-run `init` with different backend settings, it notices the change and refuses to continue silently. Two flags resolve it, and confusing them is the classic accident: - `-reconfigure` — forget the recorded backend configuration and initialise against the new one, **without** copying any state. This is what you want when switching a working directory from dev to prod, because prod's state already exists and must not be overwritten. - `-migrate-state` — copy the state from the old location to the new one. Correct when genuinely relocating a single state; catastrophic when "switching environments", because it copies dev's state over prod's object. A safer habit than flag discipline is to not share a working directory between environments at all. ## The alternative that avoids the problem Many teams sidestep partial configuration by giving each environment its own root module directory, each with a fully literal backend block: ``` envs/dev/main.tf # backend "s3" { bucket = "...-dev" ... } envs/prod/main.tf # backend "s3" { bucket = "...-prod" ... } modules/network/ # the shared, reusable code ``` The duplication is a few literal lines per environment; the payoff is that `cd envs/prod && terraform init` cannot possibly be pointed at the wrong state, and a plan for prod is unambiguously a plan for prod. Which shape you pick is a real tradeoff — one directory plus backend-config files is DRYer, separate root modules are harder to get wrong — but the constraint driving both is the same: the backend is resolved before the language is. HCP Terraform uses a `cloud` block instead of a `backend` block; it is subject to the same literal-only rule, and the same `-backend-config` mechanism applies to it. ## How to say it in an interview "The backend is read before variables exist, so it takes literals only. You use partial configuration — omit the varying arguments and pass a per-environment `.tfbackend` file to init — and if you reuse one working directory across environments you re-init with `-reconfigure`, never `-migrate-state`."