HashiCorp Terraform Associate (004) Question 25
Single answer2 Terraform fundamentalsA platform team maintains Terraform code for a shared AWS VPC. Before applying a change in production, an engineer runs terraform plan and sees: Plan: 2 to add, 0 to change, 1 to destroy. The engineer expected only an in-place update to an existing security group rule. They suspect Terraform's state no longer matches the real infrastructure after someone manually modified resources in AWS. Which action should the engineer take first to verify whether the proposed destroy/create action is caused by state drift rather than by the code change itself?
- A
Run
terraform refreshand then immediately apply the changes if the plan still shows the same output. - B
Run
terraform state rmon the security group resource so Terraform will stop tracking it and avoid the destroy action. - C
Review the execution plan in detail, compare it to the configuration and current AWS resource settings, and use a refresh-only plan to detect drift before changing code or state.
- D
Run
terraform tainton the security group so Terraform will intentionally recreate it and return the state to a known-good condition.
Show answer and explanation
Correct answer: C
Explanation
This question tests a core Terraform fundamental: understanding the relationship between configuration, state, remote infrastructure, and the execution plan. When Terraform proposes unexpected actions, the safest first step is to review the plan and determine whether the change is coming from configuration differences or state drift caused by out-of-band changes. In current Terraform workflows, plan-based inspection is preferred over older direct refresh workflows. A refresh-only plan lets you detect and preview state updates based on real infrastructure without proposing configuration-driven resource changes. Commands that manipulate state, such as terraform state rm, or force replacement, such as terraform taint, are not appropriate first diagnostic actions. HashiCorp documentation on the plan workflow, state, and refresh-only planning supports this best practice.
- A. Incorrect.
Incorrect. While refreshing state data is related to drift detection, using
terraform refreshas the first step is not the best answer in modern Terraform workflows. HashiCorp guidance favors plan-based workflows, including refresh-only planning, because they let you inspect proposed state updates before applying anything. Also, immediately applying after refresh does not verify whether the destroy/create is expected from configuration changes or caused by drift. - B. Incorrect.
Incorrect.
terraform state rmremoves an object from Terraform state without destroying the real infrastructure. That is a state manipulation command, not a diagnostic step. Using it here could make the situation worse by causing Terraform to think the existing resource must be created again. It does not help determine whether the current plan is due to drift. - C. Correct.
Correct. The right first step is to inspect the plan carefully and compare Terraform configuration, state, and the actual remote object. A refresh-only plan is specifically useful for reconciling state with real infrastructure and identifying out-of-band changes without proposing infrastructure changes from configuration. This helps determine whether the destroy/create action is caused by drift or by an actual code difference that requires replacement.
- D. Incorrect.
Incorrect.
terraform taintmarks a resource for forced replacement. That is the opposite of a diagnostic first step and would intentionally create the destroy/create behavior the engineer is trying to investigate. It does not help verify whether drift is the underlying cause.