TF-Associate-004 - Core Terraform workflow (19% of the exam) - Section 3b

Initialize a Terraform working directory.

terraform init installs providers, downloads modules, and initialises the backend. It is the most misunderstood command: it does not create infrastructure. Candidates should know when re-running init is required (new provider or module, backend change) and what -upgrade does.

terraform initbackend initialisationprovider and module installationinit -upgrade

Practice question for this objective

Free sampleCore Terraform workflowmedium

A configuration has been working for weeks with a single provider. A practitioner adds a new 'required_providers' entry for the random provider and a 'random_pet' resource, then runs 'terraform plan'. Terraform reports that it requires the random provider but it is not installed. What is the correct next step?

terraform {
  required_providers {
    aws    = { source = "hashicorp/aws", version = "~> 5.0" }
    random = { source = "hashicorp/random", version = "~> 3.6" }
  }
}
resource "random_pet" "name" {
  length = 2
}

ARun 'terraform apply -auto-approve', which will pull the random provider automatically as part of applying the new resource.
BRe-run 'terraform init' so Terraform installs the newly added random provider into the working directory. Correct
CRun 'terraform get -update' to fetch the random provider, since it retrieves both modules and providers.
DDelete the .terraform.lock.hcl file so Terraform re-resolves and installs all providers on the next plan.

Adding a new provider or module requires re-running terraform init so the new dependency is installed before plan or apply. The set of installed plugins is fixed at init time. Introducing a new required provider makes the working directory out of date, and only a fresh 'terraform init' installs the added provider and records it in the lock file.

Why A is wrong: This is tempting because apply follows plan, but apply also depends on installed plugins and will fail for the same reason until the provider is installed by init.

Why B is correct: Correct: adding a provider changes the directory's requirements, and 'terraform init' is re-run to install the new provider and update the lock file.

Why C is wrong: This looks plausible, but 'terraform get' only downloads modules referenced by the configuration and does not install provider plugins.

Why D is wrong: Removing the lock file changes version selection but does not itself install anything, and plan still does not install providers, so the error persists until init runs.

See more TF-Associate-004 practice questions, answers explained.

Exam traps in Core Terraform workflow

Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.

It provisions the resources declared in the configuration against the target provider
Why it is wrong: This is tempting because init is the first command you run, but init never contacts a provider to create resources; that is the job of apply.
terraform apply -auto-approve, which detects the new backend block and migrates the state as the apply proceeds.
Why it is wrong: Apply cannot run against a changed backend that has not been initialised, so it fails with the same requirement rather than migrating the state.
Because init must recreate the state file, which is deleted whenever the configuration changes
Why it is wrong: This is tempting because init touches directory setup, but init does not delete or recreate state; changing configuration leaves existing state in place.

Initialize a Terraform working directory.

Practice question for this objective

Exam traps in Core Terraform workflow

More in this domain