Dev and prod both call a shared registry module with version = "~> 3.0". Dev was tested on 3.4.0, but when prod was initialized two weeks later it installed 3.5.0, which nobody had tested. The team wants prod to run only module code that has already passed in dev. Which practice achieves this?

For remote modules, Terraform selects the newest available version that satisfies the version constraint each time it installs modules. The dependency lock file does not help, because it tracks provider selections only; Terraform does not remember module version choices. A pessimistic constraint such as ~> 3.0 therefore lets environments initialized at different times receive different releases. Pinning an exact version in each environment's module block, for example version = "3.4.0", makes the installed code deterministic, and promotion becomes an explicit change: once a release has passed in dev, a pull request raises prod's pin to that same version, giving reviewers a clear diff and an easy revert. Committing the lock file would not pin the module, because modules are not recorded in it. Tracking the main branch removes versioning altogether, so untested commits would reach prod immediately. A minimum-only constraint still allows any newer release, including untested ones. Exam caveat: the version argument works only for registry sources; git sources are pinned with a ref in the source address. Operational check: run terraform init in prod and confirm the module installation output names the exact version that dev tested.