2.1.3. The Dependency Lock File
💡 First Principle: Version constraints say what's acceptable; the lock file records what was actually chosen — so committing the lock file is what guarantees every teammate and CI run installs the identical provider versions, turning "newest that matches" into "exactly this."
terraform init writes .terraform.lock.hcl in your working directory. It records the exact provider version selected for each constraint plus cryptographic hashes of the provider packages. On subsequent runs, Terraform installs the locked versions rather than re-resolving constraints — and verifies the hashes to detect tampering.
You should commit the lock file to version control. That's the whole point: without it, two engineers with ~> 5.0 might end up on 5.31 and 5.40 and see different behavior. To intentionally move to newer versions within your constraints, run terraform init -upgrade, which re-resolves and rewrites the lock file.
⚠️ Exam Trap: Don't confuse the lock file with Terraform CLI versioning. .terraform.lock.hcl locks provider (and module-less dependency) versions. The Terraform CLI version itself is controlled separately — for example with a required_version setting in the terraform block — and is not what the lock file pins.
Reflection Question: A teammate reports a bug you can't reproduce, even though you're both on the same configuration. What file would you check first, and why might it explain the difference?
