How Terraform uses providers

You write resource "aws_instance" "web" { ... }, run terraform apply, and a virtual machine appears in your cloud account. Nothing in the terraform binary itself knows what an EC2 instance is or how to call Amazon's API; that knowledge lives in a provider. This section pins down the three-part relationship a provider sits in, so that by the end you can say which component holds the API logic, which one builds the plan, and how the two talk to each other.

A provider is a plugin that Terraform uses to interact with one target platform. Terraform relies on plugins called providers to interact with cloud platforms, SaaS providers, and other APIs^[1], and it is the provider, not Terraform itself, that carries the platform-specific logic. The piece you invoke on the command line is Terraform Core, the terraform binary: it parses your configuration, builds the dependency graph and the plan, and manages state, but it holds no API logic for any particular platform. Because Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs)^[2], and Core has none of that API code, a provider is required for Core to reach any real infrastructure.

Terraform Core and a provider are separate programs. Terraform Core uses remote procedure calls (RPC) to communicate with Terraform Plugins^[3], and each plugin is executed as a separate process that communicates with the main Terraform binary over that RPC interface. This clean split is what lets providers be built and shipped on their own: one side, Core, is the same for everyone, and the other side, the provider, is swapped in per platform. The figure shows the path a request travels, from Terraform Core, over RPC, to the provider plugin, which then calls the platform's API.

A provider's job is to add resource types and turn them into API calls. Each provider adds a set of resource types and/or data sources that Terraform can manage^[1], and every resource type is implemented by a provider; without providers, Terraform can't manage any kind of infrastructure^[1]. Terraform Core therefore ships with no built-in resource types of its own: an aws_instance, a google_storage_bucket, and a kubernetes_deployment all exist only because some provider defines them.

A provider exposes two kinds of things. A resource type describes an object whose lifecycle Terraform manages, and a data source is a read-only lookup: data sources fetch data from the provider, but do not create or modify resources^[4], they only read existing information for the rest of your configuration to use. Both come from the provider, so the difference is ownership, not origin. Reach for a data source when you need to read something you do not manage, such as an existing image ID or a network another team owns.

When Terraform applies a change, the provider is what actually contacts the platform. It translates each declared resource into the underlying create, read, update, and delete (CRUD) calls of that platform's API, so a single resource block can become several API requests over its life: a create on first apply, reads to detect drift, updates when arguments change, and a delete on destroy. Core never calls the platform API directly; it hands the intent to the provider, and the provider issues the CRUD API calls. The figure traces one resource from your configuration, through its provider, to the create, read, update, and delete requests the platform API executes.

Terraform figures out which provider to use from your resource types, then installs the matching plugins. If a resource doesn't specify which provider configuration to use, Terraform interprets the first word of the resource type as a local provider name^[5]: aws_instance selects the aws provider because aws is the type prefix, not because of the resource's second label (web, db, or whatever you named it). It is the type prefix that picks the provider; the name you give the resource is only an address label and never chooses a provider. Nearly every provider has a preferred local name, which it uses as a prefix for all of its resource types^[5], which is why the prefix is a reliable signal. A resource can override the default by setting the provider meta-argument explicitly, but absent that, the prefix decides.

To install a provider, Terraform needs more than a local name; it needs a source address and any version constraints. These live in a required_providers block^[5] nested in the top-level terraform block, where each entry maps a local name to a source address such as hashicorp/aws plus an optional version constraint. The Terraform Registry is the main directory of publicly available Terraform providers^[1] and is the default location Terraform downloads them from.

terraform init ties this together. During init, Terraform searches the configuration for both direct and indirect references to providers and attempts to install the plugins for those providers^[6]. By default it downloads plugins into a subdirectory of the working directory^[7], the .terraform directory, so each working directory is self-contained, and after successful installation, Terraform writes information about the selected providers to the dependency lock file^[6] (.terraform.lock.hcl) so later runs reuse the same versions. The figure follows that pipeline, from the configuration's provider requirements, through terraform init, which finds the referenced providers, to a download from the Registry and an install into .terraform with the lock file recording the versions.

TA-004 items on this objective test whether you can describe the division of labor between Terraform and its providers. No provider-specific resource knowledge is required; the questions turn on the relationship, not on any one cloud's arguments.

A frequent stem asks whether Terraform has built-in support for a cloud service, or what a provider actually is. The right answer is that a provider is a plugin and that Terraform Core has no built-in resource types, so a provider is required for every platform; reject any option claiming Terraform manages a cloud natively without one. A close variant asks whether Terraform Core calls the platform API directly. It does not: Core hands intent to the provider over RPC, and the provider makes the create, read, update, and delete calls. Choose the option that keeps the API logic in the provider.

Another stem asks why a provider's version differs from the Terraform CLI version, or why you pin the two separately. The answer is that providers are distributed separately from Terraform itself, and each provider has its own release cadence and version numbers^[1]; a provider version does not track the Terraform version. A related item asks which provider manages aws_instance. Answer from the type prefix, aws, and do not be tempted by the resource's name label, which never selects a provider.

A fourth pattern asks what terraform init does for providers, or where the plugins go. Safe answers: init reads the configuration, downloads the required providers (by default from the Terraform Registry), installs them under the .terraform directory, and records the chosen versions in the dependency lock file. Distractors place the plugins in a global-only location or claim the resource block alone, without init, installs them; both miss the init step. Finally, if an item contrasts a resource with a data source, remember both come from a provider, but only a resource type has a managed CRUD lifecycle, while a data source is read-only.