HashiCorp Terraform Associate (004) Question 171
Single answer6c Configure remote state using the backend blockA platform team is migrating a Terraform configuration from local state to a shared remote state stored in Amazon S3 so multiple engineers can safely collaborate. They add a backend block to the root module:
terraform { backend "s3" { bucket = "company-tf-state" key = "networking/prod/terraform.tfstate" region = "us-east-1" } }
When an engineer runs terraform plan, Terraform still reports that the working directory has not been initialized for the changed backend configuration. The team wants to preserve the existing local state and move it into the new remote backend correctly.
What should the engineer do next?
- A
Run terraform init -migrate-state to reinitialize the working directory and migrate the existing local state into the configured S3 backend.
- B
Run terraform apply first so Terraform creates the S3 backend automatically, then run terraform init to upload state.
- C
Run terraform refresh to update local metadata, because backend changes are picked up automatically during the next plan.
- D
Move the backend block into a terraform.tfvars file and rerun terraform plan so the backend settings are loaded as input variables.
Show answer and explanation
Correct answer: A
Explanation
This question tests practical knowledge of configuring remote state with the backend block. In Terraform, backend settings are evaluated during terraform init, not during plan or apply. When a configuration changes from the default local backend to a remote backend such as S3, Terraform requires reinitialization. If existing state must be preserved, terraform init -migrate-state is the correct workflow because it copies the current state to the new backend. This aligns with HashiCorp documentation on backend initialization and state migration. It is also a best practice to provision backend infrastructure, such as the S3 bucket, separately before using it in the backend block, because Terraform cannot rely on a backend that does not yet exist.
- A. Correct.
Correct. Changing or adding a backend configuration requires reinitializing the working directory with terraform init. When existing state must be moved from the current backend (in this case local state) to the new backend, terraform init -migrate-state is the appropriate command. Terraform will prompt to copy the existing state to the new S3 backend so future operations use the shared remote state.
- B. Incorrect.
Incorrect. Terraform does not create or manage its backend storage through terraform apply. The backend must already exist and be reachable before initialization. For an S3 backend, the S3 bucket must be created separately, and then terraform init is used to configure Terraform to use it. apply is not the mechanism for backend initialization or state migration.
- C. Incorrect.
Incorrect. terraform refresh does not reinitialize backend configuration and does not migrate state. Backend changes are not automatically adopted during plan. Terraform explicitly requires terraform init whenever the backend configuration changes so it can validate and configure the backend before any planning or apply operations.
- D. Incorrect.
Incorrect. Backend configuration is not supplied through input variables in tfvars files. The backend block belongs in Terraform configuration and is processed during initialization, before normal variable evaluation for resources. While some backend settings can be partially supplied via -backend-config during init, moving the whole backend definition into terraform.tfvars is not valid.