HashiCorp Terraform Associate (004) Question 173
Single answer6c Configure remote state using the backend blockA platform team is migrating a Terraform configuration from local state to a shared Amazon S3 backend so multiple engineers can collaborate safely. The team wants Terraform state stored remotely, but they do not want AWS access keys hardcoded in the configuration. They add a backend block to the root module and run terraform init. Which action best completes the migration while following Terraform backend best practices?
- A
Define the S3 bucket, key, and region in the backend block, provide AWS credentials through the normal AWS credential chain (for example environment variables or a shared credentials file), and run terraform init -migrate-state
- B
Store the AWS access_key and secret_key directly inside the backend block so terraform init can authenticate and automatically move the state
- C
Add an s3 remote_state data source to the configuration and run terraform apply so Terraform copies the local state into S3
- D
Keep the backend block empty, pass the bucket and key as input variables, and run terraform apply because backend settings are loaded after planning
Show answer and explanation
Correct answer: A
Explanation
To configure remote state, Terraform uses a backend block in the root module, such as terraform { backend "s3" { ... } }. Backend initialization occurs during terraform init. When migrating existing local state to a remote backend, the correct operational step is terraform init -migrate-state so Terraform can copy the local state to the newly configured backend. A key exam point is that backend configuration is separate from normal resource configuration: it is processed earlier, so standard input variables are not used for backend settings. Another common exam trap is confusing the terraform_remote_state data source with backend configuration; the data source only reads outputs from another state and does not control where the current state is stored. HashiCorp documentation and backend best practices also emphasize avoiding hardcoded secrets and using the provider or platform's standard credential mechanisms instead.
- A. Correct.
Correct. The backend block is where you configure the remote backend type and its required settings, such as bucket, key, and region for an S3 backend. Terraform backends are initialized during terraform init, not apply. To move existing local state into the configured remote backend, terraform init -migrate-state is the appropriate workflow. Supplying AWS credentials via the standard AWS credential chain is the recommended practice instead of hardcoding secrets in configuration.
- B. Incorrect.
Incorrect. Although some backends support authentication settings, hardcoding cloud credentials in Terraform configuration is not a best practice and creates security and maintenance risks. Backend credentials should typically come from environment variables, shared credentials/config files, IAM roles, or other external mechanisms supported by the platform. The scenario specifically says the team does not want credentials hardcoded.
- C. Incorrect.
Incorrect. The terraform_remote_state data source is used to read outputs from another Terraform state file; it does not configure where the current working directory stores its own state and it does not migrate local state to a backend. This is a common confusion between state storage configuration and state consumption.
- D. Incorrect.
Incorrect. Backend configuration is not provided through normal input variables because backend initialization happens before Terraform loads and evaluates the rest of the configuration in the usual way. You can partially configure a backend using backend configuration files or CLI flags with terraform init, but not standard input variables passed to terraform apply. Also, apply does not perform backend initialization.