How Providers Work

Scenario: Terraform understands a resource address but cannot create it until the matching provider plugin starts and negotiates a protocol.

Terraform Core parses configuration, builds the graph, plans, and coordinates state. Provider plugins own resource schemas, validation, API authentication, CRUD behavior, imports, and refresh. A resource type prefix conventionally identifies its provider, but explicit required_providers source addresses are authoritative. Provider configuration belongs in the root; reusable child modules declare requirements and receive configurations.

Analogy: Terraform Core is an operating system kernel and providers are device drivers. The kernel coordinates; the driver knows the hardware-specific protocol.

A worked configuration

terraform {
  required_providers {
    fakecloud = { source = "shellgenius/fakecloud" }
  }
}
provider "fakecloud" {}

Provider errors require separating layers: configuration/type error, plugin installation or checksum error, authentication/authorization failure, transport failure, API rejection, or inconsistent provider behavior. TF_LOG helps, but logs can expose secrets.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

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