A shared module starts using a language feature added in Terraform 1.11. Teams still running Terraform 1.9 now see confusing configuration errors instead of a clear message that their CLI is too old. What should the maintainer add to the module?
Select an answer to reveal the explanation.
Short Explanation
Tell Terraform the minimum version up front and it'll tell your callers plainly that their CLI is too old. Just don't pin it exactly, or you'll lock out everyone already on something newer.
Full Explanation
The required_version argument in a terraform block constrains which Terraform CLI versions may run a configuration, and constraints declared in child modules apply too: a run must satisfy every version constraint in the configuration, including those in modules. When the CLI does not satisfy a constraint, Terraform prints an error naming the requirement and exits without taking action, which replaces confusing parse errors with an actionable message. For a shared module, a minimum version constraint such as greater than or equal to 1.11 is the right shape, because it states the real requirement and allows every newer release. An exact pin to 1.11.0 would block callers on 1.12 through 1.15 who are perfectly able to run the module, turning a compatibility statement into an artificial upgrade barrier. A README note documents the requirement but enforces nothing, so the confusing errors continue for anyone who has not read it. A .terraform-version file is read by third-party version managers, not by the Terraform CLI, so callers' runs ignore it. Exam caveat: required_providers should follow the same rule in shared modules, declaring a minimum provider version and leaving exact selection to the root module and its lock file. Operational check: run terraform init with an older CLI and confirm it fails with an unsupported Terraform core version message that names the module.