TF-Associate-004 - Terraform fundamentals - 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.

More in this domain

Back to all Terraform fundamentals objectives, or the TF-Associate-004 cert hub.

Examworthy is not affiliated with or endorsed by HashiCorp. Original, blueprint-aligned practice material only.