HashiCorp Terraform Associate (004) Question 34
Single answer2b Describe how Terraform uses providersA platform team maintains Terraform code that provisions resources in AWS and GitHub for multiple application teams. During a review, a teammate removes the required_providers block because "Terraform can infer providers from the resource types anyway." On the next run in a new CI environment, terraform init installs unexpected provider versions and the plan fails due to behavior changes in one provider release. Which action is the best way to make provider installation predictable across environments while still allowing Terraform to use the correct plugins for AWS and GitHub resources?
- A
Add a
required_providersblock in theterraformconfiguration that specifies the source addresses and version constraints for the AWS and GitHub providers, then runterraform init. - B
Add provider version numbers directly inside each
resourceblock so Terraform can lock the correct plugin version per resource type. - C
Rely on Terraform to infer the provider from resource prefixes like
aws_andgithub_; provider inference also guarantees consistent provider versions across machines. - D
Configure backend settings for the remote state to pin provider plugin versions centrally for all users and CI jobs.
Show answer and explanation
Correct answer: A
Explanation
Terraform uses providers as external plugins to interact with APIs and manage resources and data sources. Resource type names such as aws_instance and github_repository indicate which provider Terraform should use, but best practice is to explicitly declare provider requirements in the terraform block with required_providers. This includes the provider source address and version constraints so terraform init can install appropriate versions consistently. In modern Terraform workflows, this explicit declaration is important for reproducibility and supply-chain clarity, especially when more than one provider offers similarly named resources or when using non-HashiCorp providers. HashiCorp documentation recommends constraining provider versions and allowing terraform init to install the selected provider plugins. Teams commonly combine required_providers with the dependency lock file .terraform.lock.hcl to make installs even more predictable across developer workstations and CI systems.
- A. Correct.
Correct. Terraform uses providers as plugins that implement resource types and data sources. The
required_providersblock is the correct place to declare each provider's source address and version constraints, such ashashicorp/awsorintegrations/github. This makes provider selection explicit and predictable duringterraform init, especially in new environments. Terraform can often infer that a resource likeaws_instanceneeds the AWS provider, but inference does not replace explicit version constraints for safe, repeatable installation. - B. Incorrect.
Incorrect. Terraform does not support setting provider versions inside individual
resourceblocks. Resources reference provider types, but provider installation and version selection are configured at the module level in theterraformblock usingrequired_providers. Someone might choose this option because resources appear tightly coupled to a provider, but version management is not done there. - C. Incorrect.
Incorrect. Terraform can infer which provider a resource belongs to based on the resource type prefix, which is why
aws_instancemaps to the AWS provider. However, inference alone does not guarantee consistent versions across environments. Without explicit version constraints,terraform initmay select different acceptable versions over time, leading to unexpected behavior changes. This option reflects the common misconception that provider inference also handles version reproducibility. - D. Incorrect.
Incorrect. Backends control where Terraform stores state and, in some cases, how operations are coordinated, but they do not manage provider plugin version selection. Provider requirements are separate from backend configuration. This is a plausible distractor because both backends and providers are initialized during
terraform init, but they serve different purposes.