Question 1 · choose 1
After terraform init, a new file named .terraform.lock.hcl appears next to the configuration. A teammate wants to add it to .gitignore along with the .terraform directory. What should the team do with it?
- AIgnore it, because init recreates it on every machine from the version constraints alone
- BIgnore it, because it caches downloaded provider binaries that are specific to one platform
- CIgnore it, because HCP Terraform regenerates it at the start of every run
- DCommit it, so every run selects the same provider versions and checks the same checksums
Show the answer and why
AIgnore it, because init recreates it on every machine from the version constraints alone
Incorrect
Without the committed file, each init could pick a newer matching version, which is exactly what the lock file prevents.
BIgnore it, because it caches downloaded provider binaries that are specific to one platform
Incorrect
Provider binaries live in .terraform/providers. The lock file holds version selections and checksums, not binaries.
CIgnore it, because HCP Terraform regenerates it at the start of every run
Incorrect
HCP Terraform installs providers using the versions in the lock file when one exists; it does not regenerate it.
DCommit it, so every run selects the same provider versions and checks the same checksums
Correct
The lock file records the provider versions Terraform selected and their checksums; committing it makes later init runs reuse those exact selections.
.terraform.lock.hcl belongs in version control with the configuration; the .terraform directory does not.
HashiCorp documentation