Init, Format, and Validate

Scenario: A pull request looks valid, but CI cannot download the provider version selected on the author's machine.

terraform fmt canonicalizes HCL style. terraform init initializes the backend, installs modules and providers, and writes or honors the lock file; rerun it after dependency or backend changes. terraform validate checks syntax and internal consistency but does not prove credentials, quotas, permissions, or runtime behavior. init -upgrade deliberately revisits selections within constraints; ordinary init favors locked versions.

Analogy: Init stocks a workshop with the correct tools; validate checks the blueprint is internally coherent. Neither proves the building site will grant permits.

A worked configuration

terraform fmt -recursive
terraform init
terraform validate
terraform providers
terraform version

In CI use deterministic versions and a provider mirror/cache where appropriate. Review lock-file checksum or version changes like dependency updates in application code. A surprising provider upgrade can change diff behavior even when HCL is untouched.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-version-lockfile Terraform lab. Open /labs/terraform and choose slug tf-version-lockfile; the lab runs real Terraform against the offline FakeCloud provider.