HashiCorp Terraform Associate (004) Question 42
Single answer2d Explain how Terraform uses and manages stateA platform team stores Terraform state for a shared AWS environment in an S3 backend with state locking enabled through DynamoDB. One engineer manually deletes an EC2 instance in the AWS console, but the resource is still present in the Terraform configuration. Later, another engineer runs terraform plan from the same workspace. What is the most likely outcome, and why?
- A
Terraform will detect that the EC2 instance is missing during refresh and propose recreating it to match the configuration.
- B
Terraform will fail immediately because the state file is stored remotely, and remote state prevents drift detection until terraform state pull is run.
- C
Terraform will remove the EC2 instance from the configuration automatically because the remote backend is the source of truth.
- D
Terraform will ignore the missing EC2 instance because state locking only protects against concurrent writes, not against manual changes in the provider.
Show answer and explanation
Correct answer: A
Explanation
Terraform uses state to map resources in configuration to real infrastructure objects and to store metadata about those objects. The backend location, whether local or remote, changes where state is stored, not the core behavior of planning. In this scenario, the remote S3 backend stores the authoritative state snapshot for the workspace, while DynamoDB locking helps prevent simultaneous operations from corrupting state. When terraform plan runs, Terraform refreshes its understanding of real infrastructure by querying the provider, detects that the EC2 instance no longer exists, and proposes an action to bring reality back in line with configuration. This is a common example of drift detection. HashiCorp documentation on state and backends explains that state is used to track real resources, remote backends centralize state storage, and locking protects state consistency during operations.
- A. Correct.
Correct. Terraform state records the last known mapping between configuration and real infrastructure, but Terraform also refreshes state from the provider during planning unless refresh is disabled. Because the EC2 instance was manually deleted outside Terraform, Terraform detects that the object no longer exists and proposes creating it again so actual infrastructure matches the configuration.
- B. Incorrect.
Incorrect. Using a remote backend such as S3 does not prevent drift detection. Terraform can still read the remote state and query the provider during planning. Running terraform state pull is not required for normal drift detection; that command is mainly for manually retrieving the current state snapshot.
- C. Incorrect.
Incorrect. Terraform does not automatically edit configuration based on state or backend contents. Configuration remains what is defined in the .tf files. The backend stores state, not desired configuration, so Terraform would not remove the resource block from code automatically.
- D. Incorrect.
Incorrect. It is true that state locking helps prevent concurrent state modifications, but Terraform does not ignore infrastructure drift. During plan, Terraform compares configuration, state, and real-world provider data. If a managed resource is gone but still declared in configuration, Terraform typically plans to recreate it.