A CI image installs the latest Terraform release whenever it is rebuilt, and a new minor version recently changed plan behavior without warning. The team wants upgrades to happen only deliberately and wants engineers' laptops held to the same rule. What should they do?
Select an answer to reveal the explanation.
Short Explanation
You want two locks on the door: the CI image installs one exact version, and required_version makes Terraform refuse to run anything else, on laptops too. The trap is the lock file, which pins providers, not the Terraform binary.
Full Explanation
Two controls work together. The CI install step, whether a container image tag, a setup action input or a download script, should name an exact Terraform version so a rebuild never pulls a new release by accident. The configuration's terraform block should declare required_version, for example a pessimistic constraint that allows only patch releases of the approved minor version; Terraform prints an error and exits without taking actions when the running CLI does not satisfy it, which holds laptops to the same rule. Changing the version then becomes an explicit pull request that edits both. The dependency lock file records provider versions and checksums only; it does not record or enforce the Terraform CLI version. Exact provider constraints in required_providers control provider selection and say nothing about the core binary. The -upgrade option on init chooses newer providers and modules within constraints and has no effect on which Terraform binary is installed, so running it on every pipeline would add provider churn without addressing the problem. Exam caveat: in HCP Terraform, each workspace has its own Terraform version setting that serves the CI pinning role for remote runs. Operational check: add a pipeline step that prints terraform version, and confirm that running with a different minor release fails on the required_version check.