HashiCorp Terraform Associate (004) Question 179
Single answer7 Maintain infrastructure with TerraformA team uses Terraform to manage an AWS VPC and several subnets. One subnet was deleted manually in the AWS console during troubleshooting, but the Terraform configuration was not changed. The team wants Terraform to recreate only the missing subnet while leaving the rest of the infrastructure unchanged. Which action should they take first to safely update Terraform's view of the infrastructure before making changes?
- A
Run terraform refresh to update the state, then run terraform plan and terraform apply
- B
Run terraform taint on the VPC so Terraform recreates all dependent resources
- C
Delete the entire state file so Terraform can rebuild state from the configuration
- D
Run terraform import for the missing subnet so Terraform can track it again
Show answer and explanation
Correct answer: A
Explanation
This question tests drift detection and safe maintenance workflows in Terraform. When infrastructure is changed outside Terraform, the correct approach is to refresh Terraform's understanding of remote objects and then review a plan. In modern Terraform usage, terraform plan automatically refreshes state unless disabled, and terraform plan -refresh-only or terraform apply -refresh-only can be used to update state without proposing configuration-driven changes. Older materials may refer to terraform refresh, but the maintenance concept remains the same: reconcile state with actual infrastructure before applying changes. Once Terraform recognizes that the subnet is missing while it is still declared in configuration, the next plan should show that subnet to be created. HashiCorp documentation on state, drift detection, planning behavior, and refresh-only operations supports this best practice.
- A. Correct.
Correct. When a real-world object has drifted from Terraform state, the first safe step is to reconcile state with reality so Terraform can detect that the subnet no longer exists. Historically, terraform refresh updated state from remote objects; in current workflows, drift is typically detected through terraform plan or with the -refresh-only planning mode. The key concept being tested is that Terraform must refresh its understanding of remote infrastructure before planning recreation. After state is updated and Terraform sees the subnet is missing, terraform plan/apply can propose recreating just that subnet if the configuration still defines it.
- B. Incorrect.
Incorrect. terraform taint marks a managed resource for forced recreation, but tainting the VPC is unnecessary and potentially disruptive because the VPC still exists and recreating it could affect many dependent resources. This option reflects the misconception that taint is a general drift-repair tool. It is more targeted than deleting state, but still the wrong resource and not the first step for this scenario.
- C. Incorrect.
Incorrect. Deleting the state file is a dangerous and unnecessary action. Terraform state is required to map configuration to real infrastructure. Removing it would cause Terraform to lose track of all managed resources and could lead to large-scale unintended recreation or errors. This is a common but serious misconception when dealing with drift.
- D. Incorrect.
Incorrect. terraform import is used to bring an existing remote object under Terraform management. In this scenario, the subnet was deleted manually and no longer exists in AWS, so there is nothing to import. A candidate might choose this if they confuse 'resource missing from state' with 'resource missing from infrastructure.' Here, the problem is the opposite: the resource is still in state/config but gone from the provider.