Understand Terraform basics →mediumMultiple ChoiceObjective-mapped

TF-004 Understand Terraform basics Practice Question

A Terraform configuration uses a module from the Terraform Registry. The module's documentation states it requires Terraform version >= 0.14. The team is using Terraform 0.12. What should the developer do to use this module?

⚠ Common exam trap

A common misconception is that version constraints in a module block can override the module's own required_version, but in Terraform the module's internal constraint is absolute and cannot be bypassed by the caller.

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

✓

Upgrade Terraform to a supported version.

The module explicitly requires Terraform >= 0.14, and the team is using Terraform 0.12, which lacks features or syntax changes introduced in later versions. Terraform modules from the Registry enforce version constraints via the `required_version` setting; using an incompatible version will cause a clear error during `terraform init` or `terraform plan`. The only reliable solution is to upgrade Terraform to a version that satisfies the module's requirement.

Answer analysis

Option-by-option breakdown

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

✓
Upgrade Terraform to a supported version.
Why this is correct
Terraform modules declare their minimum required Terraform version using the `terraform` block's `required_version` argument. If the current Terraform CLI version is older than this specified requirement, the `terraform init` command will fail with an explicit error, preventing any further operations. Upgrading the Terraform CLI to a version that meets or exceeds the module's `required_version` is the most straightforward and intended solution to resolve this compatibility issue, allowing the configuration to initialize successfully.
✗
Fork the module and modify it to be compatible.
Why it's wrong here
While technically possible, forking a module to downgrade its Terraform version requirements or rewrite its code for an older Terraform version is highly impractical and introduces significant maintenance overhead. This approach would necessitate maintaining a custom fork, missing out on upstream updates and bug fixes, and potentially introducing new issues. It is an extreme measure that is far less efficient and sustainable than simply upgrading the Terraform CLI to meet the module's declared compatibility.
✗
Add a version constraint in the module block to pin to an older compatible version.
Why it's wrong here
The `version` argument within a `module` block specifies the *module's own source version* (e.g., `v1.2.3` for a specific release of the module), not the required Terraform CLI version. There is no mechanism within the `module` block itself to override or satisfy the *module's internal `required_version` constraint* for the Terraform CLI. Attempting to pin the module to an older *module version* might seem plausible, but if that older module version still requires a newer Terraform CLI than currently installed, the problem persists.
✗
Use the module as-is; the version requirement is only a recommendation.
Why it's wrong here
The `required_version` specified within a module's `terraform` block is a strict, non-negotiable constraint, not merely a recommendation. Terraform performs a critical version check during the `terraform init` command execution. If the current CLI version does not satisfy the module's requirement, the initialization process will explicitly fail with an error message, preventing any further operations like `plan` or `apply`. This ensures that incompatible configurations are not executed, safeguarding against potential issues.

Go deeper

TF-004 Understand Terraform basics Practice Question

Why each option matters

Option-by-option breakdown

Related to this question