HashiCorp's documentation calls Terraform provisioners a last resort. What are the concrete reasons for that advice, and what should you reach for instead?

## The model provisioners break Terraform's whole value proposition is a three-way comparison: what the configuration says, what the state file recorded, and what the provider reports the real resource looks like. From those it computes a plan, you approve it, and it applies. A provisioner sits outside that loop entirely. It is an imperative shell-out bolted onto a resource's create step, and Terraform has no idea what it did. That single fact generates all five concrete objections. ## 1. Nothing lands in state If your `remote-exec` installs nginx, Terraform records no attribute saying "nginx is installed". The state file only knows the instance exists. If somebody SSHes in and uninstalls nginx, the next `terraform plan` says `No changes` — Terraform cannot detect drift in something it never tracked. ## 2. No plan visibility The plan shows `aws_instance.web will be created` plus its attributes. It does not show the commands the provisioner will run. A reviewer approving a plan in a pull request is approving a script they cannot see the effect of. For teams whose control story is "every prod change is a reviewed plan", that is a real hole. ## 3. Not idempotent, and only run on create Provisioners run when the resource is created and, for `when = destroy`, when it is destroyed. They do not run on subsequent applies. So changing the script body is a no-op for every existing instance — the fleet silently splits into machines built with the old script and machines built with the new one. Worse, the script itself usually isn't idempotent (`apt-get install` twice is fine; `echo >> file` twice is not), so any workaround that does force a re-run can corrupt the box. ## 4. Connectivity and credentials `remote-exec` and `file` need the Terraform host to reach the resource. On a laptop with a public-IP instance that is easy. In CI it is often impossible: the runner sits in a different network, the instance is in a private subnet, and the SSH private key would have to be handed to the pipeline. You end up widening a security group or shipping a key just so a provisioner can run — infrastructure changed to accommodate the tool, which is backwards. ## 5. Failure semantics are harsh A failed creation-time provisioner marks the resource **tainted**: the object exists in the cloud, but Terraform records it as unusable and plans to destroy and recreate it on the next apply. A transient network blip during bootstrap therefore costs you a full instance replacement. ## The sanctioned alternatives **Bake the image.** Build an AMI or machine image ahead of time with an image builder such as Packer, then have Terraform reference the finished image. Boot time drops, the content is versioned and testable, and every instance is identical by construction. This is the immutable-infrastructure answer. **Use the platform's own bootstrap channel.** Almost every compute service accepts a startup script — on EC2 that is `user_data`, consumed by cloud-init. The script becomes an *attribute of the resource*: it is in the plan diff, in state, and rendering it with `templatefile` keeps it in the repo. The AWS provider even exposes `user_data_replace_on_change`, so editing the script can force a replacement instead of silently diverging. ```hcl resource "aws_instance" "web" { ami = data.aws_ami.base.id instance_type = "t3.micro" user_data = templatefile("${path.module}/init.tftpl", { port = 8080 }) user_data_replace_on_change = true } ``` **Hand off to config management.** Let Terraform create infrastructure and stop there; a separate config-management run (Ansible, for example) converges the machine's software state afterwards, on its own schedule and with its own idempotency guarantees. Terraform's job ends at the resource boundary. **Use a provider resource instead of a shell command.** A surprising share of `local-exec` calls to a CLI have a real resource or data source available. If a provider models the thing, use it — you get state, diff and drift detection for free. ## What provisioners are still fine for HashiCorp's own carve-out is glue that genuinely has no declarative equivalent and no consequence if it drifts: writing a local file for another tool, triggering an external process, running a one-off command on a resource the platform gives you no other way to configure. `local-exec` on `terraform_data` for a single build step is a legitimate use. The rule of thumb interviewers want to hear: if the provisioner is configuring the *inside* of a machine, it is the wrong tool; if it is gluing Terraform to something outside its world, it may be the only tool.