HashiCorp Terraform Associate (004) Question 176
Single answer6d Manage resource drift and Terraform stateYour team manages an AWS security group with Terraform. A cloud administrator manually added an extra inbound rule in the AWS console to allow temporary access from a vendor. The Terraform configuration was not updated. Later, you run terraform plan against the same workspace and state. You want Terraform to detect the manual change and show what it would do to return the real infrastructure to the declared configuration. Which action is the best choice?
- A
Run
terraform planso Terraform refreshes state from the real infrastructure and shows the drift as a proposed change - B
Run
terraform state rmon the security group so Terraform can compare the configuration directly to AWS without using state - C
Run
terraform tainton the security group so Terraform will detect the extra rule and keep it in the configuration - D
Run
terraform importfor the security group rule that was added manually so Terraform automatically updates the configuration files
Show answer and explanation
Correct answer: A
Explanation
This scenario tests understanding of drift detection and the role of Terraform state. Resource drift occurs when real infrastructure changes outside Terraform and no longer matches the declared configuration. The standard way to detect drift is to run terraform plan, which refreshes Terraform's view of remote objects and compares that refreshed state to the configuration. If a manual inbound rule was added in AWS but not declared in code, Terraform will usually show a plan to remove or otherwise reconcile that change, depending on how the resource is modeled. Commands like terraform state rm and terraform import are state management tools for specific use cases, but they are not the normal mechanism for detecting drift in already managed resources. HashiCorp documentation for terraform plan, state management, and resource import all reinforce that state tracks object bindings, while the plan step is the primary workflow for identifying differences between configuration and actual infrastructure.
- A. Correct.
Correct.
terraform plancompares the configuration, the current state, and the real remote object. As part of normal planning behavior, Terraform refreshes state from the provider unless refresh is disabled, so a manual change in AWS is detected as drift. Terraform then shows a proposed action to reconcile the resource back to the configuration, such as removing the unexpected rule if it is managed in that resource definition. - B. Incorrect.
Incorrect.
terraform state rmremoves the resource binding from Terraform state. It does not help Terraform detect drift; instead, it makes Terraform forget that it manages the object. On the next plan, Terraform will usually propose creating a new resource because the configuration still exists but the state entry is gone. This is a state-manipulation command, not a drift-detection workflow. - C. Incorrect.
Incorrect.
terraform taintmarks a resource for forced replacement on the next apply. It does not specifically detect drift, and it does not preserve the manual change. In newer Terraform workflows, forced replacement is typically done with planning/apply options rather than relying on taint. Choosing this reflects the misconception that taint is a drift inspection tool. - D. Incorrect.
Incorrect.
terraform importadds an existing remote object to Terraform state, but it does not generate or update configuration automatically. In this scenario, the security group is already managed by Terraform, so importing is unnecessary. Import is used when Terraform is not yet tracking an existing object, not when you want to detect out-of-band changes to a managed resource.