A production root configuration calls a registry module at version 3.2.1. CI checks out the repository fresh and runs terraform init on every run. The team requires that a newly published module release never reach production until someone deliberately changes the configuration. Which approach meets this?

The dependency lock file records selections for providers only. Terraform does not remember version selections for remote modules, so on every fresh initialization it selects the newest available module version that satisfies the constraint in the module block. Because CI initializes from a clean checkout on every run, any constraint that admits newer releases will pick them up automatically as soon as they are published. An exact version constraint is the documented way to make Terraform always select the same module version, so moving to a new release requires a reviewed change to the configuration. The pessimistic constraint approximately 3.2 allows any 3.x release at or above 3.2, so a 3.3.0 release would flow into production unreviewed. A minimum constraint allows every later version, including future major versions with breaking changes. Committing the lock file is good practice for providers, but it contains no module entries, so it cannot hold the module at 3.2.1. Exam caveat: pessimistic constraints are reasonable in non-production environments that should track patches, with promotion to production by changing the exact pin. Operational check: run terraform init in a clean checkout and confirm the output reports version 3.2.1 even after a newer release is published.