TF-Associate-004 - Terraform fundamentals (11% of the exam) - Section 2a

Install and version Terraform providers.

The required_providers block inside terraform declares each provider's source address and version constraint; terraform init installs them and records exact selected versions in the dependency lock file. Candidates should reason about version constraint operators and why the lock file pins a provider across machines and runs.

required_providersprovider source addressversion constraintsdependency lock file

Practice question for this objective

Free sampleTerraform fundamentalsmedium

A practitioner has written a configuration that manages resources from the official AWS provider, but the terraform block contains no required_providers block and no version constraint anywhere. They run 'terraform init' in a fresh directory. What does Terraform do about the provider?

terraform {
}
resource "aws_s3_bucket" "data" {
  bucket = "team-analytics-store"
}

AIt fails immediately because a required_providers block is mandatory before any provider can be installed.
BIt infers the provider from the resource type, downloads the latest matching version from the public registry, and records that exact version in the dependency lock file. Correct
CIt downloads the provider but refuses to record it in the lock file until an explicit version constraint is added to the configuration.
DIt skips provider installation entirely and defers downloading until the first 'terraform apply' is run.

Terraform infers a hashicorp-namespace provider from a resource prefix and records the installed version in the lock file during init. When no explicit source is given, Terraform assumes the registry.terraform.io/hashicorp namespace based on the resource type prefix, downloads the newest release satisfying any constraints, and writes the selected version and hashes into .terraform.lock.hcl for reproducibility.

Why A is wrong: A required_providers block is recommended and needed to pin non-default sources or versions, but Terraform can still infer a hashicorp namespace provider from the resource prefix, so init does not fail here.

Why B is correct: Terraform maps the aws_ resource prefix to hashicorp/aws, installs the newest available release, and writes it to .terraform.lock.hcl so later runs are reproducible.

Why C is wrong: The lock file is written during init regardless of whether a version constraint exists; the constraint and the lock entry are separate mechanisms, so this misstates the behaviour.

Why D is wrong: Provider installation is an init-time step, not an apply-time one; this confuses provider download with resource provisioning, so init would in fact fetch the plugin now.

See more TF-Associate-004 practice questions, answers explained.

Exam traps in Terraform fundamentals

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.

It stores the current values of resource attributes so that later plans can detect drift against real infrastructure.
Why it is wrong: Tempting because tracking real infrastructure is a genuine Terraform concern, but that is the job of the state file, not the dependency lock file.
terraform init -upgrade, so Terraform re-resolves the constraints and rewrites the whole lock file for every platform.
Why it is wrong: The -upgrade flag can change the selected versions by re-evaluating constraints, which the question rules out; it also does not target adding platform checksums specifically.
Add a provider "acme" {} block at the root of the configuration and set its region argument.
Why it is wrong: A provider configuration block passes settings to an already-installed provider; it does not tell Terraform where to download a non-hashicorp provider, so init would still fail to locate it.

Install and version Terraform providers.

Practice question for this objective

Exam traps in Terraform fundamentals

More in this domain