Why provisioners run scripts on resources in Terraform - Performance Analysis
We want to understand how the time to run scripts on resources grows as we add more resources.
How does running scripts on many resources affect the total time?
Analyze the time complexity of running provisioner scripts on multiple resources.
resource "aws_instance" "example" {
count = var.instance_count
ami = "ami-123456"
instance_type = "t2.micro"
provisioner "remote-exec" {
inline = ["sudo apt-get update", "sudo apt-get install -y nginx"]
}
}
This code creates multiple instances and runs setup scripts on each one after creation.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Running the provisioner script on each instance after it is created.
- How many times: Once per instance, so equal to the number of instances.
Each new instance adds one more script run, so the total time grows directly with the number of instances.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | 10 script runs |
| 100 | 100 script runs |
| 1000 | 1000 script runs |
Pattern observation: The total work increases evenly as you add more instances.
Time Complexity: O(n)
This means the time to run all scripts grows in direct proportion to the number of resources.
[X] Wrong: "Running scripts on multiple resources happens all at once, so time stays the same no matter how many resources."
[OK] Correct: Each script runs on its own resource, usually one after another or in limited parallel, so total time adds up with more resources.
Understanding how script runs scale helps you plan deployments and explain delays clearly in real projects.
"What if the provisioner scripts ran in parallel on all resources? How would the time complexity change?"
Practice
Solution
Step 1: Understand provisioners' purpose
Provisioners run scripts to configure resources after Terraform creates them.Step 2: Identify correct use case
They help install software or run commands Terraform cannot manage directly.Final Answer:
To configure resources after they are created -> Option CQuick Check:
Provisioners configure resources post-creation = D [OK]
- Thinking provisioners delete resources
- Assuming provisioners monitor resources
- Believing provisioners backup data
Solution
Step 1: Recall correct provisioner block syntax
Terraform uses provisioner blocks with type in quotes and a command attribute.Step 2: Match syntax to options
provisioner "local-exec" { command = "echo Hello" } matches the correct syntax: provisioner "local-exec" { command = "echo Hello" }.Final Answer:
provisioner "local-exec" { command = "echo Hello" } -> Option AQuick Check:
Correct provisioner syntax uses quotes and command attribute = A [OK]
- Omitting quotes around provisioner type
- Using wrong attribute names like run or execute
- Using parentheses instead of braces
resource "null_resource" "example" {
provisioner "local-exec" {
command = "echo Resource created"
}
}Solution
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.Step 2: Analyze command execution timing
The command 'echo Resource created' runs after the resource is created, printing the message.Final Answer:
Terraform will print 'Resource created' after creating the resource -> Option BQuick Check:
local-exec runs command post-creation = A [OK]
- Thinking null_resource disallows provisioners
- Assuming commands run before resource creation
- Believing commands won't run at all
provisioner "remote-exec" {
command = "sudo apt-get update"
}
What is the likely cause of the error?Solution
Step 1: Check remote-exec requirements
remote-exec provisioner needs a connection block to connect to the resource (SSH or WinRM).Step 2: Identify missing connection block
The snippet lacks a connection block, causing Terraform to error because it cannot connect to run the command.Final Answer:
Missing connection block to specify how to connect to the resource -> Option DQuick Check:
remote-exec needs connection block = C [OK]
- Assuming command attribute is invalid
- Thinking sudo commands are disallowed
- Believing remote-exec runs local scripts only
Solution
Step 1: Identify provisioner type for remote VM configuration
remote-exec provisioner runs commands on the remote VM after creation using a connection block.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.Final Answer:
Use a remote-exec provisioner with a connection block to run installation commands after creation -> Option AQuick Check:
remote-exec + connection block = reliable remote config [OK]
- Using local-exec for remote installs
- Skipping connection block for remote-exec
- Relying on manual post-creation steps
Ready to prove it?
Pass the test and this pattern moves unknown
