Why provisioners are a last resort in Terraform - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a null_resource with a local-exec provisioner.

Terraform

resource "null_resource" "example" {
  provisioner "local-exec" {
    command = [1]
  }
}

Drag options to blanks, or click blank then click option'

Aecho Hello World

B"run echo Hello World"

C"echo Hello World"

Drun echo Hello World

Attempts:

3 left

💡 Hint

Common Mistakes

Forgetting to put quotes around the command string.

The command must be a string, so it needs quotes around it.

2fill in blank

medium

Complete the code to add a remote-exec provisioner that runs a shell command.

Terraform

resource "null_resource" "example" {
  provisioner "remote-exec" {
    inline = [1]
  }
}

Drag options to blanks, or click blank then click option'

Asudo apt-get update

B"sudo apt-get update"

C"[sudo apt-get update]"

D["sudo apt-get update"]

Attempts:

3 left

💡 Hint

Common Mistakes

Using a plain string instead of a list for inline commands.

The inline argument expects a list of strings, so it must be wrapped in square brackets and quotes.

3fill in blank

hard

Fix the error in the provisioner block by completing the missing argument.

Terraform

resource "null_resource" "example" {
  provisioner "remote-exec" {
    connection {
      type     = [1]
      user     = "ubuntu"
      host     = self.private_ip
    }
    inline = ["echo Hello"]
  }
}

Drag options to blanks, or click blank then click option'

Assh

Bhttp

Clocal

Dwinrm

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'http' or 'local' as connection type causes errors.

The connection type for remote-exec on Linux machines is usually SSH.

4fill in blank

hard

Fill both blanks to correctly configure a null_resource with triggers and a local-exec provisioner.

Terraform

resource "null_resource" "example" {
  triggers = {
    always_run = [1]
  }
  provisioner "local-exec" {
    command = [2]
  }
}

Drag options to blanks, or click blank then click option'

Atimestamp()

B"echo Running provisioner"

Ctrue

D"run provisioner"

Attempts:

3 left

💡 Hint

Common Mistakes

Using boolean true instead of timestamp() in triggers.

Not quoting the command string.

Using timestamp() in triggers forces the resource to run every time. The command must be a quoted string.

5fill in blank

hard

Fill all three blanks to create a remote-exec provisioner with SSH connection and inline commands.

Terraform

resource "null_resource" "example" {
  connection {
    type     = [1]
    user     = [2]
    host     = self.public_ip
  }
  provisioner "remote-exec" {
    inline = [[3]]
  }
}

Drag options to blanks, or click blank then click option'

Assh

B"ubuntu"

C"sudo systemctl restart nginx"

D"admin"

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong connection type.

Not quoting the username or commands.

SSH is the connection type, 'ubuntu' is the user, and the inline command must be a quoted string inside a list.

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