Lifecycle Meta-Arguments

The lifecycle block overrides Terraform's default create/update/destroy behavior on a single resource. Its four settings — create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by — are the tools for zero-downtime replacements, hard guardrails on critical resources, and making peace with values that other systems change behind Terraform's back.

Every one of these hides Terraform's default from the next person who reads the config, so each is a deliberate override that earns a comment, not a default to reach for. The three that get confused with each other solve genuinely different problems, which the comparison box below pulls apart.

create_before_destroy

By default, when a resource must be replaced, Terraform destroys the old object first and then creates the new one — a gap during which the resource does not exist. create_before_destroy = true inverts that: the replacement is built first, then the old one is destroyed once the new one is healthy. This is the key to replacing an instance behind a load balancer without an outage — the new instance comes up and registers before the old one leaves.

resource "aws_instance" "web" {
  ami           = data.aws_ami.al2023.id
  instance_type = "t3.micro"

  lifecycle {
    create_before_destroy = true
  }
}

prevent_destroy

prevent_destroy = true is a hard stop: any plan that would destroy this resource fails outright, before apply. It is a guardrail for databases and stateful stores — the thing standing between a careless -target or a stray config change and a deleted production RDS instance. Its one blind spot is important: it protects the resource only while the block is in your configuration. Delete the resource block entirely and Terraform plans a destroy with nothing left to object — which is why you pair it with the cloud's own deletion protection.

resource "aws_db_instance" "main" {
  identifier          = "prod-db"
  deletion_protection = true   # the cloud-side backstop

  lifecycle {
    prevent_destroy = true          # the Terraform-side guardrail
  }
}

ignore_changes

ignore_changes tells Terraform to stop fighting an attribute that something else legitimately changes — an autoscaler that adjusts desired_count, a deployment system that updates a tag, a process that rotates a value out of band. Without it, every plan wants to revert the external change and every apply undoes someone else's work. Scope it to the specific attributes that actually change externally; the temptation to write ignore_changes = all silences real drift along with the noise and is almost never right.

resource "aws_autoscaling_group" "app" {
  desired_capacity = 2
  min_size         = 2
  max_size         = 10

  lifecycle {
    # a scaling policy owns desired_capacity at runtime
    ignore_changes = [desired_capacity]
  }
}

replace_triggered_by

replace_triggered_by forces a resource to be replaced when a referenced resource or attribute changes, even when none of its own arguments changed. The use case is a resource that should be rebuilt whenever its dependency is — replacing an instance whenever a new launch configuration is created, for example. It takes a list of references to other resources or their attributes, and any change to one triggers the replacement.

Interactions and Ordering

create_before_destroy does not stay contained to one resource. If a resource set to create-before-destroy is depended on by others, Terraform must apply the same ordering up the chain so the dependents can attach to the new object before the old one is gone — which can force create-before-destroy onto resources you did not annotate, producing replacements you did not expect. The other interaction worth knowing: create-before-destroy collides with any resource that must have a unique name, like a fixed S3 bucket name, because the new object cannot be created while the old one still holds the name.