Managing Resource Behavior

In this lesson you’ll learn how to manage resource behavior using Terraform’s lifecycle meta-argument. The lifecycle block lets you control how Terraform creates, updates, and destroys resources. Instead of accepting default behavior, lifecycle gives you fine-grained options to protect critical infrastructure, avoid downtime during replacements, and limit churn caused by external changes. Place a lifecycle block inside a resource and use options such as prevent_destroy, create_before_destroy, ignore_changes, replace_triggered_by, and validation guards like precondition / postcondition. The examples below show common scenarios and best practices.

Use lifecycle to make Terraform safer and more predictable for sensitive resources—examples include production databases, stateful servers, and any resource where accidental deletion or downtime would be costly.

Example: protect a resource and ignore external changes

This example shows two frequent lifecycle uses:

Prevent accidental deletion with prevent_destroy = true.
Ignore external modifications to a particular attribute (vm_size) using ignore_changes.

resource "azurerm_resource_group" "example" {
  name     = "my-resource-group"
  location = "East US"

  lifecycle {
    prevent_destroy = true
  }
}

resource "azurerm_virtual_machine" "example" {
  name                = "my-vm"
  location            = "East US"
  resource_group_name = azurerm_resource_group.example.name
  vm_size             = "Standard_D2s_v3"

  lifecycle {
    ignore_changes = ["vm_size"]
  }
}

prevent_destroy = true causes Terraform to error if a plan attempts to destroy the resource; you must remove the flag to allow deletion intentionally.
ignore_changes = ["vm_size"] tells Terraform to ignore external changes to the vm_size attribute; Terraform will not attempt to revert those external modifications.

Use ignore_changes sparingly. Overuse can hide real configuration drift and make troubleshooting harder. Prefer narrow ignores (specific attributes) instead of ignore_changes = ["*"].

Lifecycle options at a glance

Understanding the main lifecycle options helps you answer common operational and exam-focused questions quickly.

Option	Purpose	When to use
`create_before_destroy`	Create replacement before destroying old resource	Avoid downtime when replacing servers or resources behind load balancers
`prevent_destroy`	Prevent Terraform from destroying the resource	Protect critical production resources (databases, storage)
`ignore_changes`	Ignore external changes to specified attributes	When external systems manage certain attributes and you don’t want Terraform to revert them
`replace_triggered_by`	Force replacement of a resource when a referenced resource changes	When one resource’s change requires another to be replaced
`precondition` / `postcondition`	Plan / apply-time validation checks with custom error messages	Validate inputs or outputs to prevent unsafe/unsupported operations

Detailed options and examples

create_before_destroy

By default, Terraform may destroy the old resource before creating the new one during replacement, which can cause downtime. create_before_destroy = true flips the order so Terraform brings up the replacement first and then destroys the previous instance.

resource "aws_instance" "web" {
  ami           = "ami-12345"
  instance_type = "t2.micro"

  lifecycle {
    create_before_destroy = true
  }
}

Use this when replacing servers that must stay available (e.g., instances behind a load balancer).

prevent_destroy

prevent_destroy = true blocks Terraform from destroying the resource; any plan that includes a destroy will fail until you remove this safeguard.

resource "aws_db_instance" "prod" {
  identifier = "production-db"
  # other required arguments ...

  lifecycle {
    prevent_destroy = true
  }
}

Remove the flag intentionally when you truly want to delete the resource; it prevents accidental destructive operations.

ignore_changes

ignore_changes tells Terraform to disregard drift for specific attributes so external changes do not trigger an update.

resource "aws_instance" "app" {
  ami = "ami-12345"

  tags = {
    Name = "app-server"
  }

  lifecycle {
    ignore_changes = ["tags"]
  }
}

Note: prefer explicit attribute lists to avoid masking important configuration drift.

replace_triggered_by

replace_triggered_by forces a resource replacement when a referenced resource (or specific attributes) change, even if Terraform would not automatically detect the need for replacement.

resource "aws_instance" "web" {
  ami = "ami-12345"

  lifecycle {
    replace_triggered_by = [
      aws_security_group.web
    ]
  }
}

Use when changes to one resource require a full recreation of another (e.g., when a security group modification requires instance recreation to take effect).

precondition and postcondition

Preconditions and postconditions are plan/apply-time validation guards to ensure operations are safe and results meet expectations.

precondition runs during planning before resource creation/modification. If false, Terraform aborts with the provided message.
postcondition runs after creation/modification to validate the final state.

Example preventing a deprecated VM size:

resource "azurerm_virtual_machine" "web" {
  name     = "web-vm"
  location = var.location
  vm_size  = var.vm_size

  lifecycle {
    precondition {
      condition     = var.vm_size != "Basic_A0"
      error_message = "Basic_A0 is deprecated"
    }
  }
}

Use preconditions to stop unsafe launches, and postconditions to verify that the change produced the expected state.

Exam and operational tips

If a question mentions preventing downtime during replacement, create_before_destroy is usually the correct choice.
For protecting critical resources from accidental deletion, look for prevent_destroy.
If external systems modify resources (and you want Terraform to ignore those modifications), ignore_changes is the relevant option.
replace_triggered_by is less common but important when one resource must be recreated due to changes in another.
Be aware that precondition and postcondition exist and are used for validation during plan/apply.

That’s the lifecycle meta-argument at a high level. It’s a small set of controls but a powerful tool to make Terraform safer and more predictable for sensitive or production infrastructure.

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules