HashiCorp Terraform Associate (004) Question 172
Single answer6c Configure remote state using the backend blockA team is migrating a Terraform configuration from local state to an S3 remote backend so multiple engineers can safely collaborate. They add the following to the root module:
terraform { backend "s3" { bucket = "company-tf-state" key = "network/prod/terraform.tfstate" region = "us-east-1" } }
When an engineer runs terraform init, Terraform reports that backend initialization is required and asks whether to copy the existing state. The team wants to preserve the current infrastructure state and begin using the remote backend with minimal risk. What is the best action to take?
- A
Run
terraform init -migrate-stateand confirm copying the existing local state to the configured S3 backend. - B
Run
terraform applyfirst so Terraform recreates the resources in S3-backed state automatically during the next init. - C
Delete the local
terraform.tfstatefile, then runterraform initso Terraform forces a clean backend initialization. - D
Move the
backend "s3"block into a child module that manages networking, then runterraform initfrom the root module.
Show answer and explanation
Correct answer: A
Explanation
This question tests practical use of the backend block when moving from local state to remote state. In Terraform, backend configuration is initialized during terraform init, and changing backend settings triggers a reinitialization workflow. When an existing local state file should be preserved, the recommended approach is to migrate it to the remote backend using terraform init -migrate-state or by confirming the interactive migration prompt. For collaboration, the S3 backend is commonly used, often together with a locking mechanism such as DynamoDB in older patterns or native locking support where applicable per current backend capabilities and Terraform version. A key best practice is that backend blocks belong in the root module, and state files should never be deleted as part of migration unless there is a verified backup and a deliberate recovery plan. See HashiCorp Terraform documentation for backend configuration, terraform init, and state migration behavior.
- A. Correct.
Correct. When changing from local state to a remote backend, the appropriate workflow is to reinitialize Terraform and migrate the existing state to the new backend.
terraform init -migrate-stateis specifically designed for this purpose. It preserves the current resource bindings and avoids accidental recreation or orphaning of infrastructure. This is the safest and standard way to transition to an S3 backend. - B. Incorrect.
Incorrect.
terraform applydoes not automatically migrate backend state. Backend configuration is handled duringterraform init, notapply. Attempting to apply before properly initializing and migrating state can lead to confusion and risk, especially if Terraform is not using the expected state location. - C. Incorrect.
Incorrect. Deleting the local state before migration is dangerous because the state file contains Terraform's mapping of real infrastructure to configuration. If removed before migration, Terraform may no longer know what it manages, which can result in plans that try to recreate existing resources or lose management of infrastructure.
- D. Incorrect.
Incorrect. Backend configuration must be defined in the root module, not in child modules. Terraform ignores backend blocks in child modules for backend initialization. This option reflects a common misunderstanding about where backend configuration belongs.