Immutable infrastructure concept in Terraform - Commands & Configuration

Introduction

Immutable infrastructure means you never change servers or resources after they are created. Instead, you replace them with new ones when you need updates. This approach helps avoid unexpected problems and keeps your system stable.

When you want to update your application without downtime by replacing old servers with new ones.

When you want to avoid configuration drift caused by manual changes on servers.

When you want to roll back easily by switching to a previous version of infrastructure.

When you want to improve security by deploying fresh servers with updated patches.

When you want to automate infrastructure updates safely and predictably.

Config File - main.tf

main.tf

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "app_server" {
  ami           = "ami-0c94855ba95c71c99"
  instance_type = "t2.micro"

  tags = {
    Name = "immutable-app-server"
  }
}

This Terraform file defines a simple AWS EC2 instance.

The provider block sets the AWS region.

The aws_instance resource creates a new server with a specific Amazon Machine Image (AMI) and instance type.

When you want to update this server, you change the AMI or instance type and apply again, which replaces the old server with a new one instead of modifying it.

Commands

This command initializes the Terraform working directory. It downloads the AWS provider plugin needed to create resources.

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 before making any changes. It helps you verify that the new server will be created as expected.

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.app_server will be created

  + resource "aws_instance" "app_server" {

      + ami                          = "ami-0c94855ba95c71c99"

      + instance_type                = "t2.micro"

      + tags                        = {

          + "Name" = "immutable-app-server"

        }

    }



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

This command creates the new server as defined in the configuration. The -auto-approve flag skips manual confirmation to speed up deployment.

Terminal

terraform apply -auto-approve

Expected Output

aws_instance.app_server: Creating...

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

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



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

→

-auto-approve - Automatically approve the apply action without prompting

This command removes the server created by Terraform. It is used to clean up resources when they are no longer needed.

Terminal

terraform destroy -auto-approve

Expected Output

aws_instance.app_server: Refreshing state... [id=i-0abcd1234efgh5678]



An execution plan has been generated and is shown below.



Terraform will perform the following actions:



  # aws_instance.app_server will be destroyed

  - resource "aws_instance" "app_server" {

      - ami                          = "ami-0c94855ba95c71c99" -> null

      - instance_type                = "t2.micro" -> null

      - tags                        = {

          - "Name" = "immutable-app-server"

        } -> null

    }



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



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

aws_instance.app_server: Destruction complete after 10s



Destroy complete! Resources: 1 destroyed.

→

-auto-approve - Automatically approve the destroy action without prompting

Key Concept

If you remember nothing else from this pattern, remember: never change servers in place, always replace them with new ones to keep infrastructure stable and predictable.

Common Mistakes

Manually logging into servers to change configuration instead of updating Terraform code.

This causes configuration drift and breaks the immutable infrastructure principle.

Make all changes in Terraform code and redeploy to replace servers cleanly.

Modifying Terraform resources in place without replacing them when updates are needed.

This can cause unexpected side effects and unstable infrastructure.

Change resource parameters that force replacement, then apply to create new resources.

Summary

Initialize Terraform to prepare the working directory and download providers.

Use terraform plan to preview changes before applying them.

Apply changes with terraform apply to create new immutable servers.

Destroy resources with terraform destroy when cleaning up.

Practice

1. What does the term immutable infrastructure mean in Terraform?

easy

A. Replacing resources instead of modifying them in place

B. Changing resources directly without replacement

C. Manually updating resources outside Terraform

D. Using mutable variables to configure resources

Solution

1. Step 1: Understand the definition of immutable infrastructure

   Immutable infrastructure means you do not change existing resources but replace them entirely when updates are needed.

2. Step 2: Compare options with this definition

   Only Replacing resources instead of modifying them in place describes replacing resources instead of modifying them, which matches the concept.

3. Final Answer:

   Replacing resources instead of modifying them in place -> Option A

4. Quick Check:

   Immutable infrastructure = Replace, not modify [OK]

Hint: Immutable means replace, not change existing resources [OK]

Common Mistakes:

• Thinking mutable means immutable
• Confusing manual updates with Terraform-managed changes
• Assuming resources are changed in place

2. Which Terraform lifecycle argument helps implement immutable infrastructure by creating new resources before destroying old ones?

easy

A. ignore_changes

B. prevent_destroy

C. create_before_destroy

D. replace_triggered_by

Solution

1. Step 1: Identify lifecycle arguments related to resource replacement

   Terraform lifecycle has arguments like create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by.

2. Step 2: Match argument to immutable infrastructure behavior

   Create_before_destroy ensures new resource is created before old one is destroyed, supporting immutable infrastructure.

3. Final Answer:

   create_before_destroy -> Option C

4. Quick Check:

   Lifecycle create_before_destroy = create new before delete old [OK]

Hint: Use create_before_destroy to replace safely [OK]

Common Mistakes:

• Confusing prevent_destroy with create_before_destroy
• Using ignore_changes which skips updates but doesn't replace
• Misunderstanding replace_triggered_by purpose

3. Given this Terraform resource snippet with lifecycle:

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

  lifecycle {
    create_before_destroy = true
  }
}

What happens when you change instance_type from t2.micro to t2.small?

medium

A. Terraform creates a new instance first, then destroys the old one

B. Terraform ignores the change due to lifecycle rules

C. Terraform destroys the old instance first, then creates a new one

D. Terraform updates the existing instance in place

Solution

1. Step 1: Understand create_before_destroy lifecycle effect

   This setting tells Terraform to create the new resource before destroying the old one to avoid downtime.

2. Step 2: Apply this to instance_type change

   Changing instance_type requires replacement, so Terraform creates new instance first, then destroys old.

3. Final Answer:

   Terraform creates a new instance first, then destroys the old one -> Option A

4. Quick Check:

   create_before_destroy means create new before destroy old [OK]

Hint: create_before_destroy means new resource first [OK]

Common Mistakes:

• Assuming in-place update happens
• Thinking old resource is destroyed before new is ready
• Believing lifecycle ignores changes

4. You wrote this Terraform lifecycle block:

lifecycle {
  create_before_destroy = false
}

But you want to implement immutable infrastructure with zero downtime. What is the problem?

medium

A. Terraform will create duplicate resources without destroying old ones

B. Terraform will not replace resources at all

C. Terraform will ignore lifecycle block and update in place

D. Resources will be destroyed before new ones are created, causing downtime

Solution

1. Step 1: Analyze create_before_destroy false effect

   When false, Terraform destroys old resource before creating new one, causing downtime.

2. Step 2: Match with immutable infrastructure goal

   Immutable infrastructure aims for zero downtime by creating new resource first, so false breaks this goal.

3. Final Answer:

   Resources will be destroyed before new ones are created, causing downtime -> Option D

4. Quick Check:

   False create_before_destroy = destroy first, downtime risk [OK]

Hint: False create_before_destroy causes downtime risk [OK]

Common Mistakes:

• Thinking false means no replacement
• Assuming lifecycle block is ignored
• Believing duplicates are created without destroy

5. You want to deploy a web server with immutable infrastructure using Terraform. Which combination of lifecycle settings and resource management best supports this goal?

hard

A. Use ignore_changes on all attributes to prevent updates

B. Use create_before_destroy = true and avoid manual changes outside Terraform

C. Use prevent_destroy = true to stop any resource replacement

D. Manually update resources and disable Terraform lifecycle rules

Solution

1. Step 1: Identify lifecycle settings that enable immutable infrastructure

   Create_before_destroy = true ensures new resource is ready before old is removed, supporting immutable infrastructure.

2. Step 2: Consider resource management best practices

   Avoid manual changes outside Terraform to keep infrastructure consistent and manageable.

3. Final Answer:

   Use create_before_destroy = true and avoid manual changes outside Terraform -> Option B

4. Quick Check:

   Immutable infrastructure = create_before_destroy + Terraform-only changes [OK]

Hint: Combine create_before_destroy with Terraform-only changes [OK]

Common Mistakes:

• Using prevent_destroy which blocks replacement
• Ignoring changes disables updates, not replacement
• Manual changes cause drift and errors