A CI runner in an air-gapped network cannot reach the public Terraform Registry, and terraform init fails to download providers. Which approach lets init install providers inside the isolated network?
Select an answer to reveal the explanation.
Short Explanation
Think of a provider mirror as a local warehouse stocked ahead of time. You tell Terraform's CLI config to shop there instead of the public registry. The trap is the lock file, which is a receipt with checksums, not a box of binaries.
Full Explanation
Terraform's provider installation behaviour is controlled by the provider_installation block in the CLI configuration file, not by the root module. A filesystem_mirror method points at a local directory laid out in the mirror format, and a network_mirror method points at an HTTPS service that serves provider packages; each method can use include and exclude patterns, and direct can be kept for any providers still allowed to reach their origin registry. The mirror is typically populated on a connected machine with terraform providers mirror and then transferred into the isolated network. The dependency lock file records versions and checksums used to verify packages; it contains no binaries and gives init nowhere to download from. A required_providers source is always a registry-style address of hostname, namespace and type; it cannot be a filesystem path. The -get=false option skips child module installation only, and Terraform has no built-in copies of provider plugins to fall back on. Exam caveat: when a mirror serves packages for only some platforms, the lock file may need checksums for every platform in use, generated with terraform providers lock. Operational check: run terraform init with TF_LOG set to trace on the runner and confirm providers are installed from the mirror location.