Forced Replacement and Refactoring

Scenario: A server is corrupted but its configuration is unchanged, so a normal plan proposes nothing.

terraform apply -replace=ADDRESS requests replacement through a reviewed plan and supersedes the older taint workflow. terraform taint marks an instance for replacement in state but creates ambient, less visible intent. For address refactors, use moved blocks or state mv, not replacement. terraform_data can represent lifecycle triggers without an external provider resource.

Analogy: Replacement is swapping a damaged appliance; refactoring is relabeling the circuit breaker. Confusing them creates needless demolition.

A worked configuration

terraform plan -replace=fakecloud_server.api -out=recovery.tfplan
terraform apply recovery.tfplan

resource "terraform_data" "release" {
  triggers_replace = [var.release_id]
}

Always inspect downstream replacement and availability impact. In automation, record why replacement was requested and remove temporary triggers after the incident so the next run stays predictable.

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-terraform-data-triggers Terraform lab. Open /labs/terraform and choose slug tf-terraform-data-triggers; the lab runs real Terraform against the offline FakeCloud provider.