Why provisioners are a last resort in Terraform - See It in Action

Why Provisioners Are a Last Resort in Terraform

📖 Scenario: You are managing cloud infrastructure using Terraform. You want to understand how to handle tasks that Terraform does not natively support, like running scripts on a virtual machine after it is created.

🎯 Goal: Build a simple Terraform configuration that creates a virtual machine and uses a provisioner as a last resort to run a script on it.

📋 What You'll Learn

Create a Terraform resource for a virtual machine

Add a connection block to enable communication with the VM

Add a provisioner block to run a script on the VM

Understand why provisioners should be avoided when possible

💡 Why This Matters

🌍 Real World

Provisioners are sometimes needed to perform tasks that Terraform cannot do natively, like installing software or configuring a VM after creation.

💼 Career

Cloud engineers and DevOps professionals often need to understand when and how to use provisioners safely to avoid unstable infrastructure deployments.

1

Create a Terraform resource for a virtual machine

Write a Terraform resource block called aws_instance named example with the ami set to "ami-0c55b159cbfafe1f0" and instance_type set to "t2.micro".

Terraform

# Your code here to create aws_instance example with specified ami and instance_type

Hint

Use the resource keyword with aws_instance and specify the ami and instance_type exactly as given.

2

Add a connection block to enable communication with the VM

Add a connection block inside the aws_instance.example resource with type set to "ssh", user set to "ec2-user", and private_key set to file("~/.ssh/id_rsa").

Terraform

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

  # Add connection block here
}

Hint

The connection block tells Terraform how to connect to the VM for running commands.

3

Add a provisioner block to run a script on the VM

Inside the aws_instance.example resource, add a provisioner block of type remote-exec that runs the command "echo Hello, Terraform! > /tmp/hello.txt".

Terraform

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

  connection {
    type        = "ssh"
    user        = "ec2-user"
    private_key = file("~/.ssh/id_rsa")
  }

  # Add provisioner block here
}

Hint

The provisioner runs commands on the VM after it is created. Use remote-exec with an inline command.

4

Add a comment explaining why provisioners are a last resort

Add a comment at the top of the Terraform file explaining: "Provisioners are a last resort because they can cause unpredictable failures and make infrastructure harder to manage."

Terraform

# Your comment here explaining why provisioners are a last resort
resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  connection {
    type        = "ssh"
    user        = "ec2-user"
    private_key = file("~/.ssh/id_rsa")
  }

  provisioner "remote-exec" {
    inline = ["echo Hello, Terraform! > /tmp/hello.txt"]
  }
}

Hint

Write a clear comment at the top of the file explaining the risks of using provisioners.

Practice

1. Why should Terraform provisioners be considered a last resort when managing infrastructure?

easy

A. Because they can cause unpredictable errors and are not idempotent

B. Because they are the fastest way to configure resources

C. Because they automatically update resources without manual input

D. Because they replace the need for Terraform state files

Solution

1. Step 1: Understand provisioner behavior

   Provisioners run commands after resource creation but can fail unpredictably and are not guaranteed to run only once.

2. Step 2: Compare with Terraform best practices

   Terraform encourages using native resource configuration or external tools to avoid errors and maintain idempotency.

3. Final Answer:

   Because they can cause unpredictable errors and are not idempotent -> Option A

4. Quick Check:

   Provisioners cause errors = A [OK]

Hint: Provisioners can fail unpredictably; prefer native config [OK]

Common Mistakes:

• Thinking provisioners are the fastest method
• Believing provisioners auto-update resources
• Assuming provisioners replace state management

2. Which of the following is the correct syntax to use a local-exec provisioner in Terraform?

easy

A. provisioner "local-exec" ( command = "echo Hello" )

B. provisioner local_exec { command: "echo Hello" }

C. provisioner "local-exec" { command = "echo Hello" }

D. provisioner "local_exec" { run = "echo Hello" }

Solution

1. Step 1: Recall Terraform provisioner syntax

   Terraform uses the block syntax with quotes for provisioner type and equals sign for attributes.

2. Step 2: Match correct syntax

   provisioner "local-exec" { command = "echo Hello" } correctly uses "local-exec" in quotes and sets command with equals sign.

3. Final Answer:

   provisioner "local-exec" { command = "echo Hello" } -> Option C

4. Quick Check:

   Correct syntax uses quotes and equals = D [OK]

Hint: Use quotes and equals sign for provisioner blocks [OK]

Common Mistakes:

• Using underscores instead of hyphens in provisioner type
• Using colons instead of equals signs
• Using parentheses instead of braces

3. Given this Terraform snippet, what will happen if the remote-exec provisioner command fails during apply?

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

  provisioner "remote-exec" {
    inline = ["sudo apt-get update", "sudo apt-get install -y nginx"]
  }
}

medium

A. Terraform will stop and roll back the resource creation

B. Terraform will mark the resource as created but report an error

C. Terraform will ignore the error and continue

D. Terraform will retry the provisioner command indefinitely

Solution

1. Step 1: Understand provisioner failure behavior

   If a provisioner command fails, Terraform treats the resource creation as failed and stops the apply process.

2. Step 2: Recognize rollback behavior

   Terraform attempts to roll back or destroy the partially created resource to keep state consistent.

3. Final Answer:

   Terraform will stop and roll back the resource creation -> Option A

4. Quick Check:

   Provisioner failure stops apply and rolls back = A [OK]

Hint: Provisioner failure stops apply and triggers rollback [OK]

Common Mistakes:

• Assuming resource is created despite failure
• Thinking Terraform ignores provisioner errors
• Believing provisioners retry automatically

4. You have this Terraform resource with a local-exec provisioner:

resource "null_resource" "example" {
  provisioner "local-exec" {
    command = "echo Hello"
  }
}

After running terraform apply, the provisioner does not run. What is the most likely cause?

medium

A. The command syntax is incorrect

B. The provisioner block must be outside the resource block

C. Terraform does not support local-exec provisioners

D. The resource has no changes, so provisioner is not triggered

Solution

1. Step 1: Understand provisioner trigger conditions

   Provisioners run only when the resource is created or replaced, not on every apply if no changes.

2. Step 2: Analyze the resource state

   If the null_resource has no changes, Terraform skips running the provisioner.

3. Final Answer:

   The resource has no changes, so provisioner is not triggered -> Option D

4. Quick Check:

   Provisioners run only on resource changes = B [OK]

Hint: Provisioners run only on resource create or replace [OK]

Common Mistakes:

• Assuming provisioners run every apply
• Thinking local-exec syntax is wrong here
• Placing provisioner block outside resource

5. You need to run a script on a VM after creation, but the script requires sensitive data and complex setup. Why is it better to avoid Terraform provisioners and what should you do instead?

hard

A. Avoid provisioners because they run before resource creation; run scripts manually instead

B. Avoid provisioners because they can leak sensitive data; use configuration management tools like Ansible

C. Use provisioners because they securely handle sensitive data automatically

D. Use provisioners because they guarantee idempotent script execution

Solution

1. Step 1: Identify risks with provisioners and sensitive data

   Provisioners can expose sensitive data in logs and are not idempotent, risking security and reliability.

2. Step 2: Choose better alternatives

   Using configuration management tools like Ansible or cloud-init handles complex setup securely and reliably outside Terraform.

3. Final Answer:

   Avoid provisioners because they can leak sensitive data; use configuration management tools like Ansible -> Option B

4. Quick Check:

   Provisioners risk data leaks; prefer config tools = C [OK]

Hint: Use config tools for sensitive setup, not provisioners [OK]

Common Mistakes:

• Assuming provisioners handle sensitive data securely
• Thinking provisioners run before resource creation
• Believing provisioners guarantee idempotency