Why Provisioners Are a Last Resort

Scenario: Terraform creates a server, then a 200-line remote-exec script partially configures it and fails halfway through.

Provisioners run imperative actions during resource creation or destruction, but Terraform cannot model their internal steps, idempotency, or resulting configuration. Failures can taint resources and retries may repeat non-idempotent work. Prefer purpose-built provider resources, prebuilt images, cloud-init/user data, configuration management, or application deployment systems.

Analogy: Terraform can track a delivered package, but it cannot know whether every instruction inside an unstructured handwritten note was completed.

A worked configuration

resource "fakecloud_server" "api" {
  name = "api"
  # Prefer image_id/user_data when the provider supports them.
}

Provisioners entangle infrastructure availability with network reachability, SSH credentials, package mirrors, and script behavior. They turn a deterministic graph into a distributed shell script during the riskiest moment of creation.

Warning: A successful provisioner is not recorded as a separately managed object. Future plans may never notice configuration drift inside the machine.

Goal: Reinforce this lesson in the tf-terraform-data-triggers Terraform lab. Open /labs/terraform and choose slug tf-terraform-data-triggers; the lab runs real Terraform against the offline FakeCloud provider.