terraform init

1. Downloads the provider. Reads versions.tf's required_providers block, and downloads the matching azurerm provider plugin into a local .terraform/ folder.
2. Locks the provider version. Writes (or checks, if it already exists) .terraform.lock.hcl, recording the exact provider version and checksums downloaded, so every future run uses the identical version.
3. Configures the backend. Reads backend.tf and connects to the configured remote state location, so later commands know where to read and write state.

Init does not read or evaluate any resource blocks, and it does not contact Azure's resource APIs at all — it only needs to reach the Terraform provider registry and, if a backend is configured, the state storage account.

Run it from inside the folder containing the .tf files you want to work with. This project has two separate root modules, and each needs its own independent init:

terraform -chdir=terraform init
terraform -chdir=terraform/bootstrap init

-chdir=<path> tells Terraform to run as if you'd cd'd into that folder first, without actually changing your shell's working directory — useful from a repository root, and the pattern this project's README and GitHub Actions workflow use throughout.

• Terraform CLI is installed, at a version satisfying versions.tf's required_version (1.7 or later, below 2.0).
• Network access to registry.terraform.io (or an internal mirror) to download the provider.
• If initializing with a real backend: the state storage account and container already exist — created once by bootstrap/main.tf — and you're authenticated (az login) as an identity with the Storage Blob Data Contributor role on that container.
• For offline / structural checks only, that last requirement can be skipped entirely with -backend=false.

• A local .terraform/ folder exists, containing the downloaded provider plugin.
• .terraform.lock.hcl is present and up to date — commit this file to Git so everyone uses the same provider version.
• If a backend was configured, Terraform is connected to it: later commands (plan, apply, output) will read and write state there instead of a local file.
• No Azure resources have been created, changed, or inspected yet.

terraform -chdir=terraform init -backend-config backend.hcl

Uses the partial-configuration file described on the backend.tf page to supply the storage account, container, and state file name.

terraform -chdir=terraform init -input=false -lockfile=readonly \
  -backend-config="storage_account_name=$TF_STATE_STORAGE_ACCOUNT" \
  -backend-config="container_name=tfstate" \
  -backend-config="key=metals.tfstate"

-input=false stops Terraform from pausing for interactive prompts in a non-interactive CI job. -lockfile=readonly uses the committed .terraform.lock.hcl exactly as-is, without letting the workflow silently upgrade provider versions on its own.

terraform -chdir=terraform init -backend=false -input=false -lockfile=readonly

Downloads the provider so terraform validate and terraform test can run, without ever touching the real state backend — used by this project's CI checks on every push and pull request.

terraform -chdir=terraform init -migrate-state -backend-config backend.hcl

Used only when someone previously ran Terraform locally (with local state) and needs to copy that state into the new shared backend, instead of starting from an empty remote state against already-existing resources.