Terraform Provider Interview Questions

False. Terraform core only handles the configuration language, builds the dependency graph, and manages state. Every resource type and data source is implemented by a provider plugin, which contains the logic to call the target platform's API. Without a provider that implements the needed resource types, Terraform has no way to create, read, update, or delete that infrastructure, so a provider must be installed and initialized with terraform init.

terraform init initializes the working directory: it downloads the required provider plugins and modules and configures the backend, writing the .terraform directory and the dependency lock file. It must run before plan or apply, and it's safe to re-run when you add a provider, change a module source, or reconfigure the backend.

A Terraform provider is a plugin: a separate binary that implements the gRPC interface Terraform uses. It maps each resource type and data source to the underlying service's API, which is how Terraform creates, reads, updates, and deletes those resources declaratively. Providers are released by HashiCorp or the community and are declared in the required_providers block.

The required_providers block is a child of the terraform meta-block, which also holds settings like required_version and backend configuration. Placing required_providers at the top level of a module, outside the terraform block, would produce a validation error.

terraform init initializes a working directory by downloading and installing the provider plugins listed in required_providers, configuring the backend, and preparing the directory for other commands such as plan and apply. The question asks for the single command that performs provider installation, which is terraform init.

terraform init is an open question about behaviour, so it stays a short answer graded against a reference. The core behaviour is that init reads the required_providers declarations and version constraints, picks matching versions, and installs the provider plugins into the .terraform/ directory so that plan and apply can use them. Providers come from the Terraform Registry by default or from a mirror set in the CLI configuration, not from a local path in the provider source address. Init also writes .terraform.lock.hcl to pin the selected versions and checksums for reproducible runs.

The required_providers block lives inside the terraform block and declares, for each provider, a local name, a source address, and an optional version constraint. During terraform init, Terraform uses these entries to download the matching provider plugins and to reject versions that fall outside the constraint, which makes runs reproducible across environments. Without the block, Terraform can fall back to inferring a default provider, but declaring it explicitly pins the source address and version.

This is true. A configuration can list several providers in the required_providers block and then declare resources from each of them. Each resource type is tied to its own provider plugin, and Terraform builds one dependency graph across all of them during plan and apply. For example, one configuration can provision AWS infrastructure and create GitHub repositories together.

The statement is true. terraform plan and terraform apply do not download or change provider plugins; they use the plugins that terraform init installed in the working directory. When the version constraint changes, init must run again so Terraform selects and installs a provider version that satisfies the new constraint. Re-running init is safe because it only changes what differs from the current configuration.

A provider plugin bridges Terraform to a specific cloud or platform API, so concept 1 matches the description about bridging to an API (b). A resource block declares a single piece of infrastructure, such as a virtual machine or database, in configuration, so concept 2 matches the description about declaring one piece of infrastructure (a). A state file records the mapping between configuration and the real-world resources Terraform has provisioned, so concept 3 matches the description about that mapping (c). The only pairing that gets all three right is 1-b, 2-a, 3-c.

Providers are how Terraform stays platform-agnostic at its core while managing almost anything: each provider plugin supplies the resource/data-source schemas and does the API translation. Knowing that providers are versioned plugins downloaded at init explains why required_providers and the lock file matter for reproducible runs.

When a required_providers entry omits the hostname, Terraform assumes the default public registry at registry.terraform.io, resolving hashicorp/aws to the full address registry.terraform.io/hashicorp/aws.

The statement is true. The alias meta-argument lets you declare multiple configurations of one provider type, such as a default unaliased aws provider for us-east-1 and a second aws provider aliased as west for us-west-2. A resource targets the alternate configuration with provider = aws.west. Without an alias, a provider type has exactly one default (un-aliased) configuration, which resources use when they specify no provider argument.

Inside a required_providers entry, the source argument gives the provider's address in the form namespace/name (here hashicorp/aws), which Terraform uses to locate and download the plugin from the registry during terraform init. The version argument in the same block only constrains which released versions are acceptable; it does not say where the plugin comes from, so the blank must be source.

In Terraform, the provider meta-argument on a resource expects an unquoted reference to a provider configuration — aws.west — not a string literal like "aws.west" (Option A is wrong). There is no alias argument valid inside a resource block; the alias is declared only in the provider block and referenced via the dot syntax (Option C is wrong). The provider block's type label must be a bare type name without a dot; you cannot write provider "aws.west" (Option D is wrong). Option B correctly defines alias = "west" in the provider block and references it as provider = aws.west in the resource block.

Terraform implicitly inherits only the default provider configuration into child modules; aliased configurations are never inherited automatically. The fix is the providers meta-argument on the module block, which maps the provider name the child expects (here the default aws) to the parent's aliased configuration aws.west. A provider block written inside the child module is a new, independent configuration with its own arguments, so it does not reuse the parent's aws.west settings. The parent's alias is only usable inside the child when it is explicitly handed over through providers.

The source attribute is the registry address (namespace plus type) that determines which plugin Terraform downloads, while the local name is a module-internal shorthand for referencing that provider in configuration blocks such as provider and resource blocks. Both are required because the local name is scoped to the module and can be freely chosen, whereas the source is the global, unique identifier needed to locate the correct provider artifact.

Terraform allows several configurations of one provider by giving each provider block an alias argument, which pairs with the default configuration (which has no alias). A resource chooses a non-default configuration by setting the provider meta-argument to <provider_local_name>.<alias_value>, for example aws.west. Both names are fixed by Terraform's configuration language, so alias and provider are the only correct fills.

Terraform uses the default (non-aliased) provider configuration for any resource that omits the provider meta-argument. Here, the aws provider block with no alias (region us-east-1) is that default. The block with alias = "west" is an additional named configuration that applies only when a resource sets provider = aws.west. Declaring one un-aliased and one aliased block is valid, so no error occurs. Block order in the file has no effect on which configuration is selected.

The .terraform.lock.hcl file pins the exact provider version and checksums so that every team member who runs terraform init gets identical provider artifacts. Without -upgrade, init respects the locked version even if a newer satisfying version exists (the statement that terraform init (without -upgrade) installs the provider version recorded in the lock file even if a newer version satisfying the constraint is available is true). With -upgrade, init ignores the existing lock, selects the newest available version satisfying each constraint, and rewrites the lock file (the statement that terraform init -upgrade updates .terraform.lock.hcl to record the newest available provider version that satisfies each required_providers version constraint is true). If the lock file is deleted, init starts fresh and picks the newest satisfying version, writing a new lock file (the statement that deleting .terraform.lock.hcl and running terraform init regenerates the file, selecting the newest available version satisfying each required_providers constraint is true). The claim that terraform init records provider checksums in .terraform.lock.hcl for all supported platforms is false: terraform init only records checksums for the current platform's archive; to include additional platforms you must run terraform providers lock -platform=.... The claim that .terraform.lock.hcl also locks module versions referenced via source references in the configuration is false: .terraform.lock.hcl covers provider plugins only—module versions are pinned in the configuration itself (e.g., a Git tag or registry version in the module block), not in the lock file.

A provider block without an alias argument defines the default configuration for its provider type, and a resource that omits the provider meta-argument uses that default. Aliased configurations are never selected implicitly, because Terraform has no basis for choosing one among several. In this configuration both aws blocks have aliases, so the resource has no unambiguous configuration. The fix is either to add a non-aliased aws provider block, which becomes the default, or to add an explicit provider meta-argument such as provider = aws.east to the resource.

The source argument gives the provider's global address. Terraform prepends the default registry hostname registry.terraform.io to hashicorp/aws, producing registry.terraform.io/hashicorp/aws, and that address determines which plugin binary is downloaded and verified during terraform init. The local name aws is the key in required_providers; it is a module-scoped label used to reference the provider in provider configuration blocks and in provider meta-arguments on resources. Renaming the local name would not change which binary is fetched, only the identifier used within the module.

Terraform first calls GetProviderSchema to learn which resource types, data sources, and schemas the freshly launched provider exposes, since it cannot validate or plan anything without them. It then calls ConfigureProvider to pass the provider block's values (credentials, region, endpoints) so the plugin can make API calls. Next, the internal plan phase of apply calls PlanResourceChange for the new resource to compute the proposed new state and resolve unknown values. Only after the plan is produced and the change is confirmed does Terraform call ApplyResourceChange, which performs the actual create operation through the provider's API and returns the final state. Each call depends on the one before it, so the order is fixed.

Terraform Core compares the integer schema version stored in each resource instance's state against the version the provider advertises for that resource type in its GetProviderSchema response. When the stored version is lower, Core calls UpgradeResourceState, passing the stored version, and the provider walks its registered state-upgrader functions from that version forward to the current one, returning the migrated state. This is a strictly version-number-driven migration mechanism — it has nothing to do with field-level conformance, the provider source address in state, or drift detected by ReadResource. If the stored version already equals the current version, the RPC is skipped entirely; if it is higher than what the provider supports, Terraform reports an error.

A child module can only receive an aliased provider configuration if it declares that alias in configuration_aliases within required_providers. The root's providers map entry for aws.west has no matching declaration in the child, so Terraform raises a configuration error (it does not fall back to the default aws provider) and halts before planning. The child's provider = aws.west reference would also fail, since no provider configuration with that alias is known in the child's scope.