Create_before_destroy lifecycle rule in Terraform - Commands & Configuration

Introduction

Sometimes when you update infrastructure, you want the new resource ready before the old one is removed. This avoids downtime or service interruption. The create_before_destroy rule in Terraform helps by making sure the new resource is created first, then the old one is deleted.

When updating a server or database and you want to avoid downtime during replacement.

When changing a resource that cannot be updated in place and would cause service interruption if destroyed first.

When managing load balancers and you want to keep traffic flowing while replacing backend instances.

When updating DNS records that need to be available continuously without gaps.

When deploying cloud resources that require a smooth transition from old to new versions.

Config File - main.tf

main.tf

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  lifecycle {
    create_before_destroy = true
  }

  tags = {
    Name = "example-instance"
  }
}

This Terraform file creates an AWS EC2 instance.

The lifecycle block with create_before_destroy = true tells Terraform to create the new instance before destroying the old one during updates.

This helps avoid downtime by ensuring the new instance is ready first.

Commands

This command initializes the Terraform working directory. It downloads necessary provider plugins and prepares Terraform to run.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/aws...

- Installing hashicorp/aws v4.0.0...

- Installed hashicorp/aws v4.0.0 (signed by HashiCorp)



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure.

This command shows what Terraform will do when applying the configuration. It previews the creation of the AWS instance.

Terminal

terraform plan

Expected Output

An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Terraform will perform the following actions:



  # aws_instance.example will be created

  + resource "aws_instance" "example" {

      + ami                          = "ami-0c55b159cbfafe1f0"

      + arn                          = (known after apply)

      + instance_type                = "t2.micro"

      + tags                         = {

          + "Name" = "example-instance"

        }

    }



Plan: 1 to add, 0 to change, 0 to destroy.



─────────────────────────────────────────────────────────────────────────────



Note: You didn't specify an "-out" parameter to save this plan, so Terraform

can't guarantee to take exactly these actions if you run "terraform apply" now.

This command applies the Terraform configuration, creating the AWS instance. The -auto-approve flag skips manual approval.

Terminal

terraform apply -auto-approve

Expected Output

aws_instance.example: Creating...

aws_instance.example: Still creating... [10s elapsed]

aws_instance.example: Creation complete after 15s [id=i-0abcd1234efgh5678]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approve the apply without prompting

If you change the instance_type in the config and run this again, Terraform will create the new instance before destroying the old one because of create_before_destroy.

Terminal

terraform apply -auto-approve

Expected Output

aws_instance.example: Creating...

aws_instance.example: Still creating... [10s elapsed]

aws_instance.example: Creation complete after 15s [id=i-0wxyz9876mnop4321]

aws_instance.example: Destroying... [id=i-0abcd1234efgh5678]

aws_instance.example: Destruction complete after 10s



Apply complete! Resources: 1 added, 0 changed, 1 destroyed.

→

-auto-approve - Automatically approve the apply without prompting

Key Concept

If you remember nothing else from this pattern, remember: create_before_destroy makes Terraform build the new resource first to avoid downtime before removing the old one.

Common Mistakes

Not adding the lifecycle block with create_before_destroy when replacing critical resources.

Terraform will destroy the old resource before creating the new one, causing downtime or service interruption.

Always add lifecycle { create_before_destroy = true } to resources that must stay available during updates.

Using create_before_destroy on resources that cannot have two instances simultaneously.

This causes Terraform to fail because the cloud provider disallows duplicate resources.

Use create_before_destroy only when the resource supports having both old and new instances at the same time.

Summary

Initialize Terraform with terraform init to prepare the environment.

Use terraform plan to preview changes before applying.

Apply changes with terraform apply -auto-approve to create or update resources.

Add lifecycle { create_before_destroy = true } to ensure new resources are created before old ones are destroyed, avoiding downtime.

Practice

1. What is the main purpose of the create_before_destroy lifecycle rule in Terraform?

easy

A. To create a new resource before deleting the old one to avoid downtime

B. To destroy resources before creating new ones to save costs

C. To prevent any resource from being created or destroyed

D. To automatically backup resources before deletion

Solution

1. Step 1: Understand lifecycle behavior

   The create_before_destroy rule tells Terraform to create the replacement resource first.

2. Step 2: Avoid downtime during updates

   This ensures the old resource is only destroyed after the new one is ready, preventing service interruption.

3. Final Answer:

   To create a new resource before deleting the old one to avoid downtime -> Option A

4. Quick Check:

   create_before_destroy = avoid downtime [OK]

Hint: Remember: create new first, then delete old [OK]

Common Mistakes:

• Thinking it deletes old resource before creating new
• Confusing with prevent_destroy lifecycle rule
• Assuming it backs up resources automatically

2. Which of the following is the correct syntax to enable create_before_destroy in a Terraform resource?

easy

A. lifecycle { create_before_destroy = true }

B. lifecycle { create_before_destroy: true }

C. lifecycle = { create_before_destroy = true }

D. lifecycle { create_before_destroy = "true" }

Solution

1. Step 1: Review Terraform lifecycle block syntax

   The lifecycle block uses curly braces with key-value pairs using = and booleans without quotes.

2. Step 2: Identify correct boolean assignment

   Boolean values are unquoted, so true is correct, not "true" as string.

3. Final Answer:

   lifecycle { create_before_destroy = true } -> Option A

4. Quick Check:

   Correct syntax uses = and unquoted booleans [OK]

Hint: Use = and true without quotes in lifecycle block [OK]

Common Mistakes:

• Using colon : instead of equals =
• Putting boolean true in quotes
• Assigning lifecycle block with = instead of braces

3. Given this Terraform resource snippet, what will happen during an update?

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"

  lifecycle {
    create_before_destroy = true
  }
}

medium

A. Terraform will destroy the old instance before creating the new one

B. Terraform will fail because create_before_destroy is not supported

C. Terraform will update the instance in place without replacement

D. Terraform will create the new instance before destroying the old one

Solution

1. Step 1: Check lifecycle rule effect

   The create_before_destroy = true means Terraform creates the new resource first.

2. Step 2: Understand resource replacement

   Since the instance requires replacement, Terraform creates new instance before destroying old one.

3. Final Answer:

   Terraform will create the new instance before destroying the old one -> Option D

4. Quick Check:

   create_before_destroy = new before old [OK]

Hint: If replacement needed, new resource comes first [OK]

Common Mistakes:

• Assuming old resource is destroyed first
• Thinking update happens in place always
• Believing create_before_destroy is unsupported

4. You added create_before_destroy = true to a resource but Terraform still destroys the old resource before creating the new one. What is the likely cause?

medium

A. You used quotes around true in lifecycle block

B. The resource does not support create_before_destroy lifecycle rule

C. You forgot to run terraform init

D. Terraform always destroys before creating regardless of lifecycle

Solution

1. Step 1: Understand resource support

   Not all Terraform resources support create_before_destroy. If unsupported, Terraform ignores it.

2. Step 2: Check lifecycle behavior fallback

   If unsupported, Terraform defaults to destroying old resource before creating new one.

3. Final Answer:

   The resource does not support create_before_destroy lifecycle rule -> Option B

4. Quick Check:

   Unsupported resource ignores create_before_destroy [OK]

Hint: Check resource docs for create_before_destroy support [OK]

Common Mistakes:

• Assuming terraform init fixes lifecycle issues
• Using quotes around boolean true
• Believing lifecycle rules always override resource behavior

5. You manage a critical database server resource that must never be unavailable during updates. How should you configure Terraform to ensure zero downtime using create_before_destroy?

hard

A. Remove lifecycle block and rely on default behavior

B. Use prevent_destroy = true to stop any deletion

C. Add lifecycle { create_before_destroy = true } and verify the resource supports it

D. Manually delete old resource before applying changes

Solution

1. Step 1: Use create_before_destroy for zero downtime

   Setting create_before_destroy = true ensures new resource is ready before old is removed.

2. Step 2: Confirm resource supports lifecycle rule

   Check documentation to ensure the database resource supports this lifecycle feature to avoid unexpected downtime.

3. Final Answer:

   Add lifecycle { create_before_destroy = true } and verify the resource supports it -> Option C

4. Quick Check:

   Use create_before_destroy with support check [OK]

Hint: Always verify resource supports create_before_destroy [OK]

Common Mistakes:

• Using prevent_destroy which blocks updates
• Relying on default lifecycle risking downtime
• Manually deleting resources causing downtime