HashiCorp Terraform Associate (004) Question 174
Single answer6c Configure remote state using the backend blockA team is migrating a Terraform configuration from local state to a shared remote state stored in Amazon S3 so multiple engineers can safely collaborate. The repository currently has no backend configured. A junior engineer adds the following block to the root module:
terraform { backend "s3" { bucket = "networking-tf-state" key = "prod/networking.tfstate" region = "us-east-1" } }
When another engineer runs terraform plan, Terraform still reports that initialization is required before the backend can be used. The team wants to move the existing local state into the new remote backend with the least manual risk. Which action should they take next?
- A
Run
terraform init -migrate-statein the working directory to initialize the S3 backend and copy the existing local state into it. - B
Run
terraform applyfirst so Terraform creates the S3 backend configuration in state, then runterraform initafterward. - C
Run
terraform state pushto send the localterraform.tfstatefile to S3, because backend migration is handled by state subcommands rather than initialization. - D
Add the S3 bucket settings to a
provider "aws"block and runterraform refreshso Terraform can connect to the remote state location.
Show answer and explanation
Correct answer: A
Explanation
This question tests the practical workflow for configuring remote state using the backend block. In Terraform, backend settings are defined in the root module's terraform block and take effect only after running terraform init. When changing an existing configuration from local state to a remote backend, the correct operational step is to reinitialize and migrate the state, commonly with terraform init -migrate-state. This allows Terraform to copy the current local state to the new backend safely.
Key best-practice points:
- Backends are initialized with
terraform init. - Backend configuration is separate from provider configuration.
terraform planandterraform applydepend on initialization having already succeeded.- For an existing workspace with local state, migration should be performed through Terraform's backend initialization workflow rather than manual state file manipulation.
These behaviors are documented in HashiCorp Terraform documentation for backend configuration, backend initialization, and state migration.
- A. Correct.
Correct. Backend configuration is initialized through
terraform init, not throughplanorapply. When changing from local state to a remote backend such as S3,terraform init -migrate-stateis the appropriate workflow to reinitialize the working directory and move the existing state into the configured backend. This is the standard, low-risk approach because Terraform handles the migration process directly. - B. Incorrect.
Incorrect. Backends are configured and initialized before planning or applying.
terraform applydoes not create or activate backend settings in state. Terraform must successfully initialize the backend first, otherwise planning and applying cannot use that backend. - C. Incorrect.
Incorrect.
terraform state pushis not the normal or recommended mechanism for backend migration in this scenario. It is a more specialized command and can be risky if used incorrectly. For moving from local state to a newly configured backend, HashiCorp recommends reinitializing with backend migration viaterraform init. - D. Incorrect.
Incorrect. Backend configuration is separate from provider configuration. The
backend "s3"block tells Terraform where to store state, while the AWS provider configures how Terraform manages AWS resources. Adding bucket settings to the provider block does not configure remote state, andterraform refreshdoes not initialize or migrate backends.