Bird
Raised Fist0
Terraformcloud~10 mins

Why provisioners run scripts on resources in Terraform - Test Your Understanding

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to run a script on a resource using a provisioner.

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

  provisioner "remote-exec" {
    inline = ["[1]"]
  }
}
Drag options to blanks, or click blank then click option'
Aecho Hello World
Bstart service
Cinstall package
Dcreate file
Attempts:
3 left
💡 Hint
Common Mistakes
Using commands that are not valid shell commands.
Trying to run multiple commands without proper syntax.
2fill in blank
medium

Complete the code to specify the connection details for the provisioner.

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

  connection {
    type     = "ssh"
    user     = "[1]"
    private_key = file("~/.ssh/id_rsa")
    host     = self.public_ip
  }
}
Drag options to blanks, or click blank then click option'
Aadmin
Bec2-user
Croot
Dubuntu
Attempts:
3 left
💡 Hint
Common Mistakes
Using root which is often disabled for SSH.
Using a user that does not exist on the instance.
3fill in blank
hard

Fix the error in the provisioner block to run a script file on the resource.

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

  provisioner "file" {
    source      = "./setup.sh"
    destination = "/tmp/[1]"
  }
}
Drag options to blanks, or click blank then click option'
Asetup.sh
Bsetup
Cscript.sh
Dinstall.sh
Attempts:
3 left
💡 Hint
Common Mistakes
Omitting the file extension in the destination path.
Using a different file name that does not match the source.
4fill in blank
hard

Fill both blanks to run a script after copying it to the resource.

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

  provisioner "file" {
    source      = "./install.sh"
    destination = "/tmp/[1]"
  }

  provisioner "remote-exec" {
    inline = ["chmod +x /tmp/[2]", "/tmp/install.sh"]
  }
}
Drag options to blanks, or click blank then click option'
Ainstall.sh
Bsetup.sh
Cdeploy.sh
Drun.sh
Attempts:
3 left
💡 Hint
Common Mistakes
Using different file names in the copy and execute steps.
Forgetting to make the script executable before running.
5fill in blank
hard

Fill all three blanks to provision a resource, copy a script, and run it with correct connection details.

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

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

  provisioner "file" {
    source      = "./setup.sh"
    destination = "/tmp/[2]"
  }

  provisioner "remote-exec" {
    inline = ["chmod +x /tmp/[3]", "/tmp/setup.sh"]
  }
}
Drag options to blanks, or click blank then click option'
Aec2-user
Bsetup.sh
Dubuntu
Attempts:
3 left
💡 Hint
Common Mistakes
Using wrong SSH user names.
Mismatching script file names between provisioners.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard