HashiCorp Terraform Associate (004) Question 43
Single answer2d Explain how Terraform uses and manages stateA team manages shared AWS infrastructure with Terraform. They recently moved from local state to an S3 backend with DynamoDB state locking because multiple engineers were accidentally overwriting each other's changes. During a deployment, one engineer runs terraform apply and sees that Terraform refreshes resource information and then proposes only the differences between the configuration and the current infrastructure. Another engineer asks why the state file matters so much if Terraform can query the provider directly. Which statement best explains Terraform's use of state in this scenario?
- A
Terraform state is Terraform's authoritative mapping between resources in configuration and real-world remote objects, which allows Terraform to track, refresh, and plan changes efficiently; the remote backend stores that state centrally and locking helps prevent concurrent writes.
- B
Terraform state is only a local execution cache for provider credentials, so moving it to S3 mainly improves authentication consistency across team members.
- C
Terraform does not rely on state when creating plans because it compares configuration directly to the provider API on every run; the S3 backend is used only to store plan files for later review.
- D
Terraform state contains only outputs and variable values, while resource relationships are recalculated from configuration each time; DynamoDB locking is used to prevent two users from downloading providers at the same time.
Show answer and explanation
Correct answer: A
Explanation
Terraform state is a core part of how Terraform manages infrastructure. It stores the mapping between resource addresses in configuration and the real remote objects Terraform created or imported. When Terraform runs plan or apply, it uses the state to understand what it currently manages, refreshes that information from the provider when appropriate, and computes the delta between the desired configuration and the known current state. In team environments, a remote backend such as S3 is a best practice because it provides a shared source of truth for state. State locking, such as with DynamoDB for the S3 backend, helps prevent concurrent operations from modifying the same state at the same time. This aligns with Terraform documentation on state, backends, and state locking, which emphasizes that state is necessary for mapping resources, tracking metadata, and improving performance for larger infrastructures.
- A. Correct.
Correct. Terraform state records bindings between resources in the configuration and the corresponding remote objects, along with metadata Terraform uses to determine what it manages. During planning, Terraform uses the state as the basis for understanding existing managed infrastructure, refreshes it with real provider data, and compares the refreshed state to the configuration to determine required actions. Using an S3 backend centralizes the state for the team, and DynamoDB locking prevents simultaneous operations from corrupting or overwriting the shared state.
- B. Incorrect.
Incorrect. State does not function as a credential cache. Provider credentials are typically sourced from environment variables, shared credential files, IAM roles, or provider configuration, not from Terraform state. While state can contain sensitive values depending on resource attributes, its primary purpose is to map Terraform-managed resources to real infrastructure objects and preserve Terraform's knowledge of prior deployments.
- C. Incorrect.
Incorrect. Terraform absolutely relies on state during planning and apply. Although it can query provider APIs during refresh to update knowledge about real infrastructure, it still needs state to know which remote objects are under Terraform management and how configuration addresses map to those objects. Also, backends like S3 store state, not plan files by default.
- D. Incorrect.
Incorrect. State contains far more than outputs and variable values. It includes resource instances, attributes, dependencies, provider associations, and metadata Terraform uses for lifecycle management. DynamoDB locking is related to protecting the shared state from concurrent modification, not provider plugin downloads. Provider plugins are handled separately in the working directory or plugin cache.