Interact with Terraform modules →hardMultiple ChoiceObjective-mapped

TF-004 Interact with Terraform modules Practice Question

Exhibit

Refer to the exhibit.
```
$ terraform init
Initializing modules...
Downloading hashicorp/consul/aws 0.7.2 from registry.terraform.io...
- consul in .terraform/modules/consul

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 3.0"...
- Installing hashicorp/aws v3.74.0...
- Installed hashicorp/aws v3.74.0

Error: Unsupported terraform provider version

  on .terraform/modules/consul/main.tf line 1, in terraform:
   1: terraform {
   2:   required_providers {
   3:     aws = {
   4:       source  = "hashicorp/aws"
   5:       version = "~> 2.70"
   6:     }
   7:   }
   8: }

The root module requires hashicorp/aws >= 3.0, but the module requires ~> 2.70.
```

What is the correct way to resolve this provider version conflict?

⚠ Common exam trap

HashiCorp often tests the misconception that you can override or ignore a child module's provider version constraint, when in fact Terraform enforces compatibility across all modules and the correct fix is to align the root module's constraint with the child module's requirement.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Change the root module's required version to ~> 2.70.

The root module's required_providers version constraint must be compatible with the version constraints declared in any child modules. The error indicates the root module requires a provider version that conflicts with the consul module's constraint (e.g., ~> 2.70). Changing the root constraint to ~> 2.70 aligns it with the child module, satisfying Terraform's version resolution logic during `terraform init`.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Ignore the module's required_providers and force install the root version.
Why it's wrong here
Terraform's dependency resolution process aggregates all `required_providers` blocks from the root module and all nested modules. It then attempts to find a single provider version that satisfies *all* declared constraints simultaneously. There is no built-in mechanism or command-line flag to "force install" a specific provider version from the root module, overriding a module's explicit version requirement. Such an action would fundamentally break the module's intended functionality and is not supported by Terraform's design principles.
✗
Remove the required_providers block from the root module.
Why it's wrong here
Removing the `required_providers` block from the root module would eliminate its explicit version constraint for that provider. While this might allow Terraform to select a version solely based on the module's requirements, it's problematic if the root module implicitly relies on specific features or bug fixes present only in a newer version. This approach makes the root module's provider dependency implicit and less maintainable, potentially leading to runtime errors if the chosen version doesn't meet the root module's unstated needs.
✓
Change the root module's required version to ~> 2.70.
Why this is correct
This is the correct approach because it directly addresses the version conflict by aligning the constraints. If the module requires `~> 2.70` (meaning any patch version within 2.70, e.g., `2.70.0` up to `2.70.x` but less than `2.71.0`), then setting the root module's requirement to `~> 2.70` ensures both the root and the nested module can successfully use the same provider version. This modification makes both `required_providers` blocks compatible, allowing Terraform's dependency resolver to find a mutually acceptable version.
✗
Manually edit the .terraform/modules/consul/main.tf to change the version.
Why it's wrong here
The `.terraform` directory is an internal working directory managed exclusively by Terraform. Its contents, including downloaded module sources, are considered ephemeral and are subject to being overwritten or recreated during `terraform init` or other operations. Manually editing files within this directory, such as `main.tf` for a downloaded module, will have no lasting effect as your changes will be lost the next time Terraform initializes, reverting to the original module source. Provider version constraints must be modified in the actual source code of the module or the root configuration.

Visual reference

Go deeper

TF-004 Interact with Terraform modules Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question