An engineer wants each environment's state in a different S3 bucket and wrote bucket = var.state_bucket inside the backend block. terraform init fails with an error about variables not being allowed there. The configuration targets Terraform 1.15. What is the supported way to vary backend settings per environment?
Select an answer to reveal the explanation.
Short Explanation
The backend gets set up before Terraform has even looked at your variables, a bit like needing the front-door key before you can read the notes on the kitchen table. So don't put variables in the backend block at all; hand init the missing settings from a per-environment file instead.
Full Explanation
A backend block cannot refer to named values such as input variables, local values or data source attributes, because Terraform must configure the backend before it evaluates the rest of the configuration. The supported pattern is partial configuration: omit the arguments that differ between environments from the backend block and supply them during initialization, typically with terraform init -backend-config=PATH pointing at a per-environment file such as one for dev and one for prod, or with key=value pairs on the command line. Each environment's pipeline then initializes against its own bucket while sharing one configuration. Terraform 1.15 does let input variables declared with const = true be used in module source and version arguments, but that change does not extend to backend blocks, which still reject named values. Locals are named values too, so they hit the same restriction. Passing -var to init does not make variables available inside the backend block. Exam caveat: values given through -backend-config are stored in the .terraform directory and in plan files, so credentials should come from environment variables instead. Operational check: run init with the prod file and confirm the reported backend points at the prod bucket.