Why provisioners run scripts on resources in Terraform - Why It Works

Introduction

Sometimes after creating a resource like a server, you need to run extra setup steps on it. Provisioners let you run scripts or commands on those resources automatically to finish configuration.

When you want to install software on a new virtual machine right after it is created

When you need to copy configuration files to a server after provisioning

When you want to run a script to initialize a database on a cloud instance

When you must set up user accounts or permissions on a resource after creation

When you want to automate manual setup steps that happen after resource creation

Config File - main.tf

main.tf

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

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

    connection {
      type        = "ssh"
      user        = "ubuntu"
      private_key = file("~/.ssh/id_rsa")
      host        = self.public_ip
    }
  }
}

This Terraform file creates an AWS EC2 instance using a specific AMI and instance type.

The provisioner "remote-exec" block runs commands on the instance after it is created. Here it updates the package list and installs nginx.

The connection block tells Terraform how to connect to the instance via SSH to run the commands.

Commands

This command initializes the Terraform working directory and downloads necessary provider plugins.

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!

This command creates the AWS instance and runs the provisioner scripts automatically without asking for confirmation.

Terminal

terraform apply -auto-approve

Expected Output

aws_instance.example: Creating...

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

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



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



Running provisioner: remote-exec on aws_instance.example

→

-auto-approve - Skip interactive approval prompt

This command shows the current state of the infrastructure including the created instance.

Terminal

terraform show

Expected Output

# aws_instance.example:

resource "aws_instance" "example" {

    ami                          = "ami-0c55b159cbfafe1f0"

    arn                          = "arn:aws:ec2:us-east-1:123456789012:instance/i-0abcd1234efgh5678"

    associate_public_ip_address  = true

    availability_zone            = "us-east-1a"

    instance_type                = "t2.micro"

    key_name                     = "my-key"

    private_ip                  = "10.0.0.123"

    public_ip                   = "54.123.45.67"

    subnet_id                   = "subnet-0abc1234def56789"

    tags                        = {

        "Name" = "example"

    }

}

Key Concept

Provisioners let Terraform run setup scripts on resources right after creating them to automate configuration steps.

Common Mistakes

Not specifying the connection details for remote-exec provisioner

Terraform cannot connect to the resource to run the script, so the provisioner fails.

Always provide correct connection info like user, host, and authentication method.

Using provisioners for complex or long-running configuration tasks

Provisioners can cause apply to fail or hang if scripts take too long or have errors.

Use configuration management tools or cloud-init for complex setups instead of provisioners.

Ignoring provisioner failures and continuing apply

Provisioner errors mean the resource is not fully configured, causing runtime problems.

Fix script errors and rerun apply until provisioners succeed.

Summary

Initialize Terraform with 'terraform init' to prepare the environment.

Create resources and run provisioner scripts with 'terraform apply'.

Verify resource creation and state with 'terraform show'.

Practice

1. Why do Terraform provisioners run scripts on resources?

easy

A. To backup resource data before creation

B. To delete resources automatically

C. To configure resources after they are created

D. To monitor resource usage continuously

Solution

1. Step 1: Understand provisioners' purpose

   Provisioners run scripts to configure resources after Terraform creates them.

2. Step 2: Identify correct use case

   They help install software or run commands Terraform cannot manage directly.

3. Final Answer:

   To configure resources after they are created -> Option C

4. Quick Check:

   Provisioners configure resources post-creation = D [OK]

Hint: Provisioners run scripts after resource creation [OK]

Common Mistakes:

• Thinking provisioners delete resources
• Assuming provisioners monitor resources
• Believing provisioners backup data

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 { run = "echo Hello" }

C. provisioner "local-exec" (command: "echo Hello")

D. provisioner local-exec { execute = "echo Hello" }

Solution

1. Step 1: Recall correct provisioner block syntax

   Terraform uses provisioner blocks with type in quotes and a command attribute.

2. Step 2: Match syntax to options

   provisioner "local-exec" { command = "echo Hello" } matches the correct syntax: provisioner "local-exec" { command = "echo Hello" }.

3. Final Answer:

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

4. Quick Check:

   Correct provisioner syntax uses quotes and command attribute = A [OK]

Hint: Use quotes and command attribute for local-exec provisioner [OK]

Common Mistakes:

• Omitting quotes around provisioner type
• Using wrong attribute names like run or execute
• Using parentheses instead of braces

3. Given this Terraform snippet, what will happen when the resource is created?

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

medium

A. Terraform will fail because null_resource cannot have provisioners

B. Terraform will print 'Resource created' after creating the resource

C. Terraform will create the resource but not run the command

D. Terraform will run the command before creating the resource

Solution

1. Step 1: Understand null_resource and local-exec provisioner

   null_resource supports provisioners; local-exec runs commands on the machine running Terraform after resource creation.

2. Step 2: Analyze command execution timing

   The command 'echo Resource created' runs after the resource is created, printing the message.

3. Final Answer:

   Terraform will print 'Resource created' after creating the resource -> Option B

4. Quick Check:

   local-exec runs command post-creation = A [OK]

Hint: local-exec runs commands after resource creation [OK]

Common Mistakes:

• Thinking null_resource disallows provisioners
• Assuming commands run before resource creation
• Believing commands won't run at all

4. You wrote this provisioner block but Terraform shows an error:

provisioner "remote-exec" {
  command = "sudo apt-get update"
}

What is the likely cause of the error?

medium

A. Provisioners cannot run sudo commands

B. The command attribute is invalid for remote-exec

C. remote-exec provisioner requires a local script file

D. Missing connection block to specify how to connect to the resource

Solution

1. Step 1: Check remote-exec requirements

   remote-exec provisioner needs a connection block to connect to the resource (SSH or WinRM).

2. Step 2: Identify missing connection block

   The snippet lacks a connection block, causing Terraform to error because it cannot connect to run the command.

3. Final Answer:

   Missing connection block to specify how to connect to the resource -> Option D

4. Quick Check:

   remote-exec needs connection block = C [OK]

Hint: Always add connection block for remote-exec provisioners [OK]

Common Mistakes:

• Assuming command attribute is invalid
• Thinking sudo commands are disallowed
• Believing remote-exec runs local scripts only

5. You want to install software on a new VM after Terraform creates it. Which approach best uses provisioners to do this reliably?

hard

A. Use a remote-exec provisioner with a connection block to run installation commands after creation

B. Use a local-exec provisioner to run installation commands on your local machine

C. Run installation commands manually after Terraform finishes

D. Use a provisioner without connection block to run commands remotely

Solution

1. Step 1: Identify provisioner type for remote VM configuration

   remote-exec provisioner runs commands on the remote VM after creation using a connection block.

2. Step 2: Evaluate options for reliability

   Using remote-exec with connection block automates installation reliably; local-exec runs locally, manual runs are error-prone, and missing connection causes failure.

3. Final Answer:

   Use a remote-exec provisioner with a connection block to run installation commands after creation -> Option A

4. Quick Check:

   remote-exec + connection block = reliable remote config [OK]

Hint: Use remote-exec with connection block for remote installs [OK]

Common Mistakes:

• Using local-exec for remote installs
• Skipping connection block for remote-exec
• Relying on manual post-creation steps