TF-Associate-004 - Terraform fundamentals (11% of the exam) - Section 2b
Describe how Terraform uses providers.
A provider is a plugin that maps Terraform resource and data types onto a platform's API, handling authentication and CRUD operations. Candidates should understand that resources and data sources belong to a provider, and that provider configuration supplies credentials and region-style settings.
provider pluginprovider configurationresource and data source ownershipprovider authentication
Practice question for this objective
lock_openFree sampleTerraform fundamentalseasy
In Terraform's architecture, what is the primary role of a provider plugin?
AIt translates Terraform resource declarations into API calls against a specific platform such as AWS, Azure, or GitHub.check_circle Correct
BIt stores the mapping between resource addresses and real infrastructure identifiers so plans can be calculated.
CIt defines reusable groups of resources that can be called with input variables from the root module.
DIt locks the state file during an apply so that two runs cannot write to it at the same time.
A provider is a plugin that implements resource types and translates Terraform operations into API calls for a specific platform. Terraform Core is platform agnostic; every interaction with a real API is delegated to a provider plugin, which implements the resource and data source schemas and performs the create, read, update, and delete calls for its target service.
Why A is correct: Correct: a provider is a plugin that implements resource and data source types and turns Terraform's create, read, update, and delete requests into concrete API calls against its target platform.
Why B is wrong: This describes the state file, not a provider. State tracks the resource-to-real-world mapping, whereas providers are the executable plugins that make the API calls; it is a tempting swap because both are central to how apply works.
Why C is wrong: This describes a module. Modules package configuration for reuse, but they still rely on providers to actually talk to an API; candidates conflate the two because both extend a configuration's capability.
Why D is wrong: State locking is a function of the backend, not the provider. It is a plausible distractor because both providers and backends are configured near the terraform block, but locking is unrelated to a provider's job.
Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.
The resource uses whichever provider block appears last in the file, because later configurations override earlier ones during evaluation.
errorWhy it is wrong: Tempting because some settings do favour later definitions, but provider selection is not positional; the unaliased block is the default regardless of ordering.
It fails init immediately because every provider must be pinned in a required_providers block before any plugin can be installed.
errorWhy it is wrong: Pinning in required_providers is best practice for version control, but its absence does not stop init; Terraform can still infer and install the provider, so this overstates the requirement.
The Terraform CLI core makes the cloud API calls directly, and the provider only validates the HCL syntax.
errorWhy it is wrong: Core handles the graph, plan, and state, but it does not talk to remote APIs itself; delegating API work to the provider is the whole point of the plugin model, so this reverses their roles.