The Core Workflow — Terraform Associate 004 practice questions

During an outage an engineer uses `-target` to apply a single resource, and afterwards proposes making it the team's standard practice to keep applies fast. The BEST response is:

1. Adopt it, since limiting the graph is the documented way to reduce plan time on very large configurations
2. Adopt it only for destroy operations, where narrowing the blast radius of a run is most obviously valuable
3. Replace it with `-refresh=false`, which achieves the same narrowing of scope with considerably fewer side effects
4. Reject it: targeting is documented for exceptional recovery, and routine use leaves state inconsistent with the configuration

Answer: D — Reject it: targeting is documented for exceptional recovery, and routine use leaves state inconsistent with the configuration

D) Correct — HashiCorp positions `-target` as an escape hatch for recovering from errors, warning that habitual use produces state that no longer reflects the whole configuration. A) is the misconception the warning exists to counter; splitting configurations is the supported answer to slow plans. B) narrows the bad advice without fixing it — targeted destroys carry the same inconsistency risk. C) confuses two unrelated flags: skipping refresh changes how state is reconciled, not which objects are in scope.

Which statement about 'terraform apply' confirmation is correct?

1. apply always applies immediately without ever asking for confirmation first.
2. apply prompts for approval unless -auto-approve or a saved plan file is given.
3. apply requires SSH access to each target host before it will confirm the changes.
4. Confirmation behaviour is set with an attribute inside the terraform block.

Answer: B — apply prompts for approval unless -auto-approve or a saved plan file is given.

B is right: interactive apply shows the plan and waits for a yes, and there are exactly two ways to skip that — pass -auto-approve, or hand apply a plan file that was already reviewed. A misses the default prompt entirely. C invents a transport requirement; Terraform talks to provider APIs, not hosts. D invents a setting — the terraform block configures required_version, required_providers, backend and cloud, not prompting.

A team runs 'terraform plan' but skips saving the plan file with -out. What is the risk on apply?

1. apply recomputes the plan, which may differ from the one that was reviewed.
2. No risk — apply reuses the identical plan that the previous command computed.
3. apply refuses to run unless it is handed a previously saved plan file.
4. apply silently reads the cached plan from .terraform/plan.json instead.

Answer: A — apply recomputes the plan, which may differ from the one that was reviewed.

A is right: without -out there is no artifact to hand to apply, so apply re-plans from current state and real infrastructure, and the result can differ from what a reviewer approved. B assumes a plan cache that does not exist. C is wrong because apply runs happily with no plan file, just with a confirmation prompt. D names a file Terraform never writes. For change control, always run plan -out=FILE and apply that exact file.

What does 'terraform plan' do?

1. Applies the configuration and then prints the resulting resource attributes to stdout
2. Reads the state file and reports its contents without consulting the configuration
3. Destroys the resources described in state so the environment can be rebuilt cleanly
4. Checks configuration syntax only, without comparing it against real infrastructure
5. Generates an execution plan of pending changes; -out saves it for a later apply run

Answer: E — Generates an execution plan of pending changes; -out saves it for a later apply run

E is right: plan refreshes, compares desired configuration with recorded state and reports creates, updates, destroys and replacements without changing anything; -out=plan.bin lets apply execute exactly what was reviewed. A is apply, B is closer to terraform show, C is destroy and D is validate.

A pipeline runs `terraform plan -out=tfplan`, waits for a human approval step, then runs `terraform apply tfplan`. Which statement about the apply is correct?

1. The apply re-prompts for confirmation, because approval was recorded outside Terraform
2. The apply executes exactly the actions recorded in the saved plan, without asking for confirmation
3. The apply recomputes the diff from the current configuration and ignores the contents of the saved file
4. The apply requires the same variable values to be passed again, since the plan file omits them

Answer: B — The apply executes exactly the actions recorded in the saved plan, without asking for confirmation

B) Correct — a saved plan already encodes the decided actions and the variable values used, so apply proceeds without an interactive prompt. A) contradicts the documented behaviour; the confirmation prompt exists only when apply computes its own plan. C) would defeat the purpose of a saved plan and is not what happens. D) is wrong on the mechanics: the resolved variable values are captured in the plan file, which is also why plan files must be treated as sensitive.

Which command formats Terraform configuration files to canonical style?

1. terraform style
2. terraform lint
3. terraform format
4. terraform fmt

Answer: D — terraform fmt

Trick: the command is 'fmt' (like gofmt), not 'format' or 'style'. -check returns nonzero if files would be changed (useful in CI).

Which command downloads provider plugins and configures the backend for a working directory?

1. terraform plan
2. terraform apply
3. terraform init
4. terraform get

Answer: C — terraform init

Trick: right-command/wrong-use archetype. 'terraform get' downloads modules only (mostly obsolete; init handles it). init does providers AND backend AND modules.

An auditor changed tags on several managed resources directly in the provider console. The team wants Terraform's state to acknowledge reality before deciding what to do, without altering any infrastructure. Which command fits BEST?

1. terraform apply -refresh-only
2. terraform apply -replace=<address>
3. terraform plan -destroy
4. terraform init -reconfigure

Answer: A — terraform apply -refresh-only

A) Correct — a refresh-only apply reconciles state with what the provider reports and proposes no changes to real resources, which is exactly the requested outcome. B) forces replacement of a resource, a destructive action and the modern successor to the deprecated taint workflow, not a state reconciliation. C) previews destroying everything the configuration manages, which is not what is wanted. D) re-initialises the backend and has no relationship to detecting or absorbing drift.

If 'terraform apply' fails partway through, what is the state file's condition?

1. State is automatically rolled back to its exact pre-apply contents by Terraform itself.
2. State records what was created up to the failure; some resources may be partial.
3. State is deleted so that the next run is forced to re-initialize the directory.
4. State is locked indefinitely until an administrator clears the lock by hand.

Answer: B — State records what was created up to the failure; some resources may be partial.

B is right: Terraform writes state as it goes, so a failed apply leaves a real record of everything that succeeded, plus resources that were created but not fully configured and are flagged for replacement on the next run. A is the rollback misconception — there are no transactions across provider APIs. C is invented behaviour. D confuses a crashed run, which can leave a stale lock, with the normal failure path. Re-running plan and apply usually reconciles the difference.

What does 'terraform validate' check?

1. Whether each resource will actually be created successfully when the plan is applied
2. Internal consistency of the configuration, syntax and arguments, with no API calls
3. Whether the configured provider credentials are valid for the target cloud account
4. An estimate of the monthly cost of the resources the configuration would provision
5. Network reachability between the machine running Terraform and the provider endpoints

Answer: B — Internal consistency of the configuration, syntax and arguments, with no API calls

B is right: validate is a local check of syntax, argument names, types and references after init, with no remote calls and no state access. A and C require a plan against a real account. D is cost estimation. E is not a Terraform function at all. Custom conditions such as variable validation blocks are also evaluated here.

terraform init -upgrade?

Force upgrade providers/modules to latest acceptable versions.

terraform validate?

Check syntax/configuration without making API calls.

terraform init?

Initialize working directory. Downloads providers, sets up backend.

What does terraform validate check, and what does it deliberately NOT check?

It checks that the configuration is syntactically valid and internally consistent — correct block structure, valid argument names, correct types where known, and resolvable references. It does not contact any provider API or the remote state, so it cannot tell you whether the infrastructure exists, whether credentials work, or what will actually change.