A backend "s3" block sets bucket = var.state_bucket so each environment can use its own bucket, and terraform init fails. How should the team supply a different bucket per environment?
Select an answer to reveal the explanation.
Short Explanation
The backend is set up before Terraform even reads your variables, like a mailbox address that has to be painted on before anyone moves in. You can't paint it with a variable, but you can leave it blank and fill it in at init with -backend-config. The trap is trying a local, which runs into the same wall.
Full Explanation
Terraform initializes the backend before it evaluates the rest of the configuration, so backend blocks cannot reference input variables, locals or data source attributes; the documentation states that arguments in the terraform block cannot refer to named objects. Partial configuration is the supported pattern: leave the environment-specific arguments out of the block and provide them when running init with -backend-config, either as a path to a file containing the settings, such as a per-environment backend file, or as individual key=value pairs. Terraform merges these with the block's contents and stores the result in its working directory for later commands. Locals are named values evaluated as part of the configuration, so they hit the same restriction as variables. A TF_VAR_ environment variable sets an input variable, and the backend block still cannot read it. Passing -var to init does not make variable references valid inside a backend block; the restriction is about what backend configuration can reference, not about how the value is supplied. Exam caveat: credentials supplied through -backend-config may be stored in the .terraform directory and plan files, so prefer environment variables for secrets. Operational check: run terraform init -backend-config with the prod file and confirm the initialization output names the expected bucket.