Two engineers run terraform plan on the same commit and get different results, because their machines selected different minor versions of the same provider. The repository's .gitignore excludes .terraform.lock.hcl. What change makes provider selection reproducible across laptops and CI?
Select an answer to reveal the explanation.
Short Explanation
The lock file is the shopping receipt: it says exactly which provider version you bought and its checksum. Throw away the receipt and every machine shops on its own. And don't fall for the module trap, because that receipt never lists modules.
Full Explanation
The dependency lock file records, for each provider, the exact version that terraform init selected and the checksums of acceptable packages. When the file is present and committed, later init runs reuse those selections instead of choosing the newest version that satisfies the constraints, so every machine and pipeline installs the same provider builds. Excluding it from version control means each fresh checkout resolves constraints independently, which is precisely how two engineers end up on different minor versions. Committing the .terraform directory is not a substitute: it holds platform-specific binaries and cached module copies, it is meant to be local, and it does not drive version selection. The lock file does not track modules at all; module versions are controlled by the version argument in each module block, so pinning modules cannot fix a provider mismatch. Running init -upgrade on every run deliberately ignores the recorded selections and picks the newest allowed version, which makes results less reproducible, not more. Exam caveat: when teams use different operating systems, run terraform providers lock with each needed platform so the file holds checksums for all of them. Operational check: after committing the file, run terraform init on two machines and confirm both report the same provider version.