HashiCorp Terraform Associate (004) Question 178
Single answer6d Manage resource drift and Terraform stateA team manages an AWS security group with Terraform. During an incident, an engineer manually added an ingress rule in the AWS console to allow temporary SSH access. A week later, you run terraform plan against the same workspace and see that Terraform wants to remove that ingress rule. The team confirms the manual change is no longer needed and wants Terraform to bring the real infrastructure back in line with the configuration without modifying the configuration files. What is the best action to take?
- A
Run
terraform applyto reconcile the real infrastructure with the configuration in state and code - B
Run
terraform refreshto update the configuration so Terraform keeps the manually added rule - C
Run
terraform state rmon the security group so Terraform stops tracking the drifted rule - D
Run
terraform importfor the security group ingress rule so Terraform adds the manual change to the configuration automatically
Show answer and explanation
Correct answer: A
Explanation
This scenario tests understanding of drift detection and reconciliation. Drift occurs when a managed resource is changed outside Terraform, causing the real infrastructure to differ from the Terraform configuration and state expectations. When terraform plan shows that Terraform wants to remove an out-of-band change and the team agrees that the manual change should not persist, the correct next step is terraform apply. That makes the remote object match the declared configuration again.
Key best practices:
- Use
terraform planto detect drift before making changes. - If the manual change should be preserved, update the Terraform configuration to declare it, then apply.
- If the manual change should be removed, apply the existing configuration.
- Avoid manipulating state with commands like
terraform state rmunless you intentionally want Terraform to stop managing a resource. terraform importbrings existing resources under Terraform state management, but it does not write configuration for you.
This aligns with Terraform's workflow and HashiCorp guidance that configuration is the source of truth, while state maps configuration to real infrastructure.
- A. Correct.
Correct. This is a classic case of resource drift: the real infrastructure was changed outside Terraform, but the Terraform configuration did not change. Because the manual ingress rule is no longer desired, the correct action is to apply the existing configuration.
terraform planhas already detected the drift and shown that Terraform intends to remove the unmanaged change from the real resource to match the declared configuration. - B. Incorrect.
Incorrect.
terraform refreshupdates Terraform state with real infrastructure attributes, but it does not update Terraform configuration files. It is not used to 'keep' a manual change unless the configuration already declares that change. Also, in modern Terraform workflows, refresh behavior is integrated intoplanandapply, so using refresh here would not solve the requirement to revert the infrastructure to the declared configuration. - C. Incorrect.
Incorrect.
terraform state rmremoves a resource from Terraform state, meaning Terraform will stop managing the entire tracked resource until it is re-imported. That is not appropriate when the team still wants Terraform to manage the security group. It also does not selectively remove a single drifted attribute from management. - D. Incorrect.
Incorrect.
terraform importassociates an existing real-world resource with a Terraform resource address in state; it does not automatically generate or update Terraform configuration. In this scenario, the security group is already managed by Terraform, so import is unnecessary. Importing would not be the right way to handle a temporary, undesired manual rule.