Why provisioners are a last resort in Terraform - Visual Breakdown

Process Flow - Why provisioners are a last resort

Start Terraform Apply

↓

Create Resource

↓

Check if Provisioner Needed?

No→Finish

Yes↓

Run Provisioner Script

↓

Provisioner Success?

No→Error: Fail Apply

Yes↓

Finish

Terraform creates resources first, then runs provisioners only if needed. If provisioners fail, the apply fails, so they are used only as a last step.

Execution Sample

Terraform

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

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

This Terraform code creates an AWS instance and runs a local command after creation.

Process Table

Step	Action	Resource State	Provisioner Run	Result
1	Start apply	No resources	No	Begin deployment
2	Create aws_instance.example	Instance created	No	Resource ready
3	Check provisioner	Instance created	Yes	Run local-exec
4	Run provisioner command	Instance created	Yes	Command executed successfully
5	Provisioner success?	Instance created	Yes	Apply completes successfully

💡 Provisioners run only after resource creation; failure causes apply to fail, so use sparingly.

Status Tracker

Variable	Start	After Step 2	After Step 4	Final
Resource State	None	Created	Created	Created
Provisioner Status	Not run	Not run	Success	Success

Key Moments - 3 Insights

Why does Terraform run provisioners only after resource creation?

Because provisioners depend on the resource existing; as shown in execution_table step 3, provisioners run after creation to configure the resource.

What happens if a provisioner fails during apply?

Terraform stops and marks apply as failed, as seen in the flow where failure leads to error and no finish, so provisioners can cause deployment to fail.

Why should provisioners be a last resort?

Because they add risk of failure and reduce Terraform's ability to manage resources declaratively, shown by the dependency on provisioner success to complete apply.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does Terraform run the provisioner?

A Step 2

B Step 3

C Step 1

D Step 5

💡 Hint

Check the 'Provisioner Run' column in execution_table rows.

According to variable_tracker, what is the Provisioner Status after step 4?

A Success

B Not run

C Failed

D Unknown

💡 Hint

Look at the 'Provisioner Status' row and the 'After Step 4' column.

If the provisioner command fails, what happens to the apply process?

A Apply continues without error

B Apply retries automatically

C Apply fails and stops

D Provisioner is skipped

💡 Hint

Refer to concept_flow where failure leads to 'Error: Fail Apply'.

Concept Snapshot

Terraform creates resources first.
Provisioners run only after resource creation.
If provisioners fail, apply fails.
Use provisioners only as a last resort.
They add risk and reduce declarative control.

Full Transcript

Terraform first creates the resource. After creation, it checks if any provisioners need to run. If yes, it runs the provisioner scripts. If the provisioner succeeds, the apply finishes successfully. If the provisioner fails, Terraform stops and marks the apply as failed. Because provisioners can cause failures and reduce Terraform's declarative management, they should be used only as a last resort.

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