A root configuration declares required_version = "~> 1.10.0" and runs on Terraform 1.10.5. The team bumps a registry module to a release whose own terraform block declares required_version = ">= 1.11". What happens, and what must change?
Select an answer to reveal the explanation.
Short Explanation
Version constraints work like a group dinner reservation: everyone's dietary rules apply, not just the host's. Your CLI has to satisfy the root and every module, and right now nothing does. The trap is thinking the root's rule overrides the module's.
Full Explanation
The required_version setting constrains which Terraform CLI versions may run a configuration, and Terraform prints an error and exits without taking actions when the running version does not meet it. The documentation states that modules may declare their own constraints and that the CLI must satisfy all version constraints associated with the configuration, including those defined in modules. In this scenario, 1.10.5 fails the module's ">= 1.11" constraint. Upgrading the CLI alone is not enough either: the pessimistic constraint "~> 1.10.0" allows only 1.10.x patch releases, so any 1.11 or later binary fails the root constraint. The team must widen the root constraint and upgrade the CLI together, or stay on the previous module release until they are ready. The root module has no power to override a child module's requirement. Child module constraints are enforced as strictly as the root's; they are not advisory. Terraform does not download or switch CLI binaries; that is the job of the installation tooling or, in HCP Terraform, the workspace's Terraform version setting. Exam caveat: required_version applies only to the CLI, not providers, which are controlled by required_providers and the lock file. Operational check: before bumping a module, read its terraform block, compare it with the CLI used in every pipeline and workspace, and plan the core upgrade first if needed.