Local-exec provisioner in Terraform - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of the local-exec provisioner in Terraform?

The local-exec provisioner runs a command on the machine where Terraform is executed, allowing you to perform local actions during resource creation or destruction.

beginner

How does local-exec differ from remote-exec provisioner?

local-exec runs commands on the local machine where Terraform runs, while remote-exec runs commands on the remote resource (like a VM) after it is created.

beginner

Which argument is required inside a local-exec provisioner block to specify the command to run?

The command argument specifies the shell command or script to execute locally.

intermediate

Can local-exec provisioner access Terraform resource attributes?

Yes, you can use Terraform interpolation syntax to pass resource attributes as part of the command string to local-exec.

beginner

What is a common use case for local-exec provisioner?

A common use case is to run local scripts for configuration, notify external systems, or trigger local automation after resource creation.

Where does the local-exec provisioner run its commands?

A On the remote resource created

B On the machine running Terraform

C On the Terraform cloud server

D On a separate management server

The local-exec provisioner runs commands on the local machine where Terraform is executed.

Which argument must you include in a local-exec provisioner block?

A inline

B script_path

C command

D remote_command

The command argument specifies the command to run locally.

Can local-exec provisioner run after a resource is destroyed?

A No, it only runs on creation

B Only on resource update

C Only if manually triggered

D Yes, using the <code>when = destroy</code> setting

You can configure local-exec to run during resource destruction by setting when = destroy.

Which of these is NOT a recommended use of local-exec?

A Running commands on the remote VM

B Triggering local notifications

C Running local scripts after resource creation

D Calling local automation tools

Running commands on the remote VM should use remote-exec, not local-exec.

How can you pass resource data to a local-exec command?

A Using Terraform interpolation syntax inside the command string

B Using environment variables only

C You cannot pass resource data

D By writing to a remote file first

Terraform interpolation allows embedding resource attributes directly in the command string.

Explain what the local-exec provisioner does in Terraform and give an example of when you might use it.

Think about actions you want to perform on your own computer after creating cloud resources.

Describe how you would configure a local-exec provisioner to run a shell command that uses an attribute from a created resource.

Remember Terraform lets you insert resource data inside strings with ${}.

Practice

1. What does the local-exec provisioner do in Terraform?

easy

A. Runs commands inside the cloud resource

B. Executes Terraform plan without applying changes

C. Creates a local copy of the Terraform state file

D. Runs commands on your local machine after resource creation

Solution

1. Step 1: Understand provisioner types

   Terraform provisioners run scripts or commands either locally or remotely after resource creation.

2. Step 2: Identify local-exec purpose

   The local-exec provisioner specifically runs commands on your local machine, not inside the cloud resource.

3. Final Answer:

   Runs commands on your local machine after resource creation -> Option D

4. Quick Check:

   local-exec runs commands locally [OK]

Hint: Local-exec runs commands on your own computer [OK]

Common Mistakes:

• Confusing local-exec with remote-exec
• Thinking it runs inside the cloud resource
• Assuming it manages Terraform state files

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

easy

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

B. provisioner local-exec { run = "echo Hello" }

C. local_exec { command = "echo Hello" }

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

Solution

1. Step 1: Recall Terraform provisioner syntax

   Provisioners use the keyword provisioner followed by the provisioner type in quotes.

2. Step 2: Check correct attribute names

   The local-exec provisioner uses command to specify the shell command to run.

3. Final Answer:

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

4. Quick Check:

   Correct syntax uses provisioner "local-exec" and command [OK]

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

Common Mistakes:

• Omitting quotes around local-exec
• Using wrong attribute names like run or execute
• Using underscore instead of dash in local-exec

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' inside the cloud resource

C. Terraform will print 'Resource created' on your local machine

D. Terraform will ignore the provisioner and create the resource silently

Solution

1. Step 1: Understand null_resource and local-exec

   The null_resource is a Terraform resource that supports provisioners for running commands.

2. Step 2: Analyze the command execution

   The local-exec provisioner runs the command on your local machine, so it will print the message locally.

3. Final Answer:

   Terraform will print 'Resource created' on your local machine -> Option C

4. Quick Check:

   local-exec runs commands locally, so output appears locally [OK]

Hint: local-exec runs commands locally, not remotely [OK]

Common Mistakes:

• Thinking output appears inside cloud resource
• Believing null_resource disallows provisioners
• Assuming provisioners are ignored silently

4. You wrote this Terraform code but get an error when applying:

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

What is the cause of the error?

medium

A. Missing quotes around the command string

B. local-exec provisioner cannot be used with null_resource

C. The command attribute should be named run

D. Terraform does not support echo commands

Solution

1. Step 1: Check command syntax

   The command value must be a string enclosed in quotes in Terraform configuration.

2. Step 2: Identify missing quotes

   Here, command = echo "Hello" lacks quotes around the entire command string, causing a syntax error.

3. Final Answer:

   Missing quotes around the command string -> Option A

4. Quick Check:

   Command must be a quoted string [OK]

Hint: Always quote command strings in local-exec [OK]

Common Mistakes:

• Forgetting quotes around command
• Using wrong attribute names
• Assuming null_resource disallows provisioners

5. You want to run a local script setup.sh after creating an AWS EC2 instance using Terraform. Which is the best way to use local-exec provisioner to achieve this safely?

hard

A. Run setup.sh manually after Terraform apply

B. Use remote-exec provisioner to run setup.sh on the EC2 instance

C. Use local-exec with command = "./setup.sh" inside the EC2 resource without dependencies

D. Use local-exec with command = "./setup.sh" inside the EC2 resource and add depends_on for the instance

Solution

1. Step 1: Understand local-exec vs remote-exec

   The local-exec provisioner runs commands on your local machine, which is not suitable for running scripts on the EC2 instance itself.

2. Step 2: Use remote-exec for remote commands

   To run a script on the EC2 instance, use the remote-exec provisioner which executes commands on the remote resource.

3. Final Answer:

   Use remote-exec provisioner to run setup.sh on the EC2 instance -> Option B

4. Quick Check:

   remote-exec runs commands on the remote resource [OK]

Hint: Use remote-exec to run scripts on remote instances [OK]

Common Mistakes:

• Using remote-exec for a local script
• Running scripts manually instead of automating
• Adding unnecessary depends_on inside the resource