Lifecycle Meta-Arguments

The lifecycle block changes how Terraform creates, replaces, and destroys a resource without changing the resource itself. It is the escape hatch for the cases where Terraform's defaults — destroy-then-create on replacement, always converge every attribute back to config — would cause an outage or fight another system that has a legitimate claim on the resource.

Four arguments do the work: create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by. Each one is small, but each rewrites a default that is otherwise unavoidable — and using the wrong one, or scoping it too broadly, causes its own class of subtle bug. They are precision tools, not knobs to turn preemptively.

create_before_destroy

When a change forces replacement, Terraform's default is destroy-then-create: it deletes the old object, then creates the new one. For anything fronting live traffic, that ordering means downtime — the resource is gone for the duration of the recreate. create_before_destroy = true flips it: build the new one first, cut over, then destroy the old. That is how you replace a resource serving requests without a gap, provided GCP allows two to exist briefly and their names do not collide.

resource "google_compute_instance_template" "processor" {
  # ... template config ...
  lifecycle {
    create_before_destroy = true
  }
}

prevent_destroy

prevent_destroy = true is a guardrail: it makes Terraform error rather than destroy the resource. Put it on anything whose deletion is catastrophic — the analytics BigQuery dataset, the Terraform state bucket, a production database — so that an accidental terraform destroy, or a change that would force a replacement, is refused instead of executed. It does not prevent changes, only deletion, and it surfaces the danger at plan time rather than after the data is gone.

The catch is that prevent_destroy also blocks a forced replacement, since replacement deletes the old object. When an unrelated change forces the dataset to be replaced, the run errors — which is the point, but it can surprise someone who did not realize their change was destructive. That surprise is the guardrail doing exactly its job.

ignore_changes

ignore_changes tells Terraform to stop reconciling specific attributes back to config. The canonical GCP use is ignore_changes = [labels] on a resource that another system stamps labels onto — a cost-allocation tool, a CI pipeline, GKE adding its own labels — so that each apply does not strip what the other system added. Without it, Terraform sees the external labels as drift and removes them on every run, and the two systems fight forever.

Scope matters enormously here. Ignoring the whole labels map stops Terraform from managing any label, including the ones you set in config — so a real label change you make never applies, silently. The right scope is the exact key the external system owns: ignore_changes = [labels["managed-by"]] ignores that one key and keeps managing the rest.

resource "google_storage_bucket" "raw" {
  name     = "hatch-events-raw"
  location = "US"
  lifecycle {
    ignore_changes = [labels["managed-by"]]   # keep managing every other label
  }
}

ignore_changes for Externally-Managed Fields

Labels are the common case, but the pattern is broader. Autoscalers adjust instance counts, GCP populates server-assigned fields you never set, and external automation mutates metadata after creation. Each produces a perpetual diff — Terraform wants to undo a change made by a system that is supposed to make it. Listing exactly those attributes in ignore_changes stops the diff without abandoning management of the rest of the resource. Ignore the autoscaled field, keep managing everything else.

replace_triggered_by

replace_triggered_by forces replacement of a resource when another referenced resource or attribute changes, even though this resource's own arguments did not. The use case is when an in-place update is not enough — you want event-processor recreated whenever a referenced config object or image revision changes, not merely updated. It is the right tool only when a fresh resource is genuinely required; reach for it when a plain reference would have caused a harmless in-place update and you have forced an unnecessary destroy/create instead.