The Drift Decision Tree

Scenario: A security engineer closes a public port manually during an incident, then Terraform plans to reopen it.

For each drift item ask: was the external change authorized, should configuration adopt it, should Terraform revert it, or should ownership move elsewhere? Update configuration before applying when the external fix expresses the new desired state. Refresh-only records observed reality but does not amend future intent. ignore_changes is an ownership contract, not an incident shortcut.

Analogy: Drift is a disagreement between the policy book and the building. Sometimes the building is wrong; sometimes the emergency repair proves the book is outdated.

A worked configuration

terraform plan -refresh-only
# decide and update HCL
terraform plan
terraform apply

During incidents, restore safety first, then reconcile code, state, and documentation. Record who changed what and why. Automating a revert without understanding the security context can recreate the incident.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-state-drift-recovery Terraform lab. Open /labs/terraform and choose slug tf-state-drift-recovery; the lab runs real Terraform against the offline FakeCloud provider.