Immutable infrastructure concept in Terraform - Step-by-Step Execution

Process Flow - Immutable infrastructure concept

Write new config

↓

Create new infrastructure

↓

Switch traffic to new infra

↓

Destroy old infrastructure

↓

End

Immutable infrastructure means creating new resources for changes instead of modifying existing ones, then switching traffic and removing old resources.

Execution Sample

Terraform

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  lifecycle {
    create_before_destroy = true
  }
}

# Change instance_type to t2.small

This Terraform code creates an AWS instance. Changing instance_type triggers creation of a new instance instead of modifying the old one.

Process Table

Step	Action	Terraform Plan Result	Infrastructure State
1	Initial apply	Create aws_instance.web with t2.micro	One instance running t2.micro
2	Change instance_type to t2.small	Plan to create new aws_instance.web and destroy old one	Old instance running t2.micro, new instance pending
3	Apply changes	New instance created, traffic switched	One instance running t2.small, old instance terminated
4	Final state	No changes	One instance running t2.small

💡 No further changes, infrastructure matches desired state

Status Tracker

Variable	Start	After Change	After Apply	Final
instance_type	t2.micro	t2.small	t2.small	t2.small
instance_id	i-abc123	i-abc123 (old), i-def456 (new)	i-def456	i-def456

Key Moments - 2 Insights

Why does Terraform create a new instance instead of updating the existing one?

Terraform treats changes to instance_type as requiring replacement, so it plans to create a new instance and destroy the old one (see execution_table step 2).

What happens to the old instance during the update?

The old instance stays running until the new one is created and traffic is switched, then Terraform destroys the old instance (see execution_table step 3).

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what does Terraform plan to do?

A Update the existing instance in place

B Do nothing

C Create a new instance and destroy the old one

D Destroy the instance without replacement

💡 Hint

See execution_table row 2 under 'Terraform Plan Result'

According to variable_tracker, what is the instance_type after applying changes?

A t2.micro

B t2.small

C t2.medium

D unchanged

💡 Hint

Check variable_tracker row for instance_type after apply

When does the old instance get terminated?

A After the new instance is created and traffic switched

B At the same time as creating the new instance

C Before creating the new instance

D It never gets terminated

💡 Hint

See execution_table step 3 for infrastructure state changes

Concept Snapshot

Immutable infrastructure means no in-place changes.
Change triggers new resource creation.
Switch traffic to new resource.
Destroy old resource after switch.
Ensures stable, repeatable deployments.

Full Transcript

Immutable infrastructure is a way to manage cloud resources where you never change existing resources directly. Instead, when you want to update something, you create a new resource with the new settings. Then you switch your traffic or usage to the new resource. Finally, you remove the old resource. This approach avoids unexpected changes and makes deployments safer and easier to track. For example, in Terraform, changing the instance type of a server causes Terraform to plan creating a new server and destroying the old one. The old server stays running until the new one is ready, then traffic switches, and the old server is removed. This process ensures your infrastructure is always in a known good state.

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