Terraform Associate · 12% of the exam

Maintain infrastructure with Terraform: free practice questions

5 sample questions from our 32-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real HashiCorp exam.

1. A developer runs `terraform destroy -target=aws_instance.web`. What is the correct understanding of this command's scope and HashiCorp's guidance around it?

  • A. It destroys only `aws_instance.web` and any resources that depend on it, and is recommended as the default way to remove infrastructure in normal operation
  • B. It destroys only `aws_instance.web` and resources depending on it, but HashiCorp recommends reserving targeted operations for exceptional situations (like recovering from errors) rather than routine use, since it can leave configuration and state inconsistent✓ Correct
  • C. It destroys the entire configuration's resources regardless of the `-target` flag, since `destroy` always operates on the whole state
  • D. It only marks the resource for destruction; a second, separate `terraform apply` is required to actually remove it
Explanation

Option B is correct. `-target` scopes the destroy operation to the named resource and anything that depends on it, but HashiCorp's own guidance is that targeted operations are intended for exceptional circumstances — such as recovering from a bad state or working around a specific error — not as a routine workflow, because repeated targeted operations can leave the overall configuration and real infrastructure out of sync with what a full plan would show. Option A is incorrect on the recommendation half — targeting is explicitly discouraged as a default practice. Option C is incorrect — `-target` does scope the operation; it does not destroy everything regardless. Option D is incorrect — `terraform destroy` (targeted or not) performs the destruction directly; it doesn't require a follow-up `apply` to complete the action.

2. A resource's cloud provider automatically injects a `LastModifiedBy` tag whenever any change is applied through the console, which then shows up as drift on every subsequent `terraform plan` even though nothing meaningful changed. Which lifecycle meta-argument is designed to stop Terraform from proposing changes for that specific attribute?

  • A. `prevent_destroy = true`
  • B. `create_before_destroy = true`
  • C. `ignore_changes = [tags["LastModifiedBy"]]`✓ Correct
  • D. `replace_triggered_by = [tags]`
Explanation

Option C is correct. `ignore_changes`, listing the specific attribute (or `all`), tells Terraform to stop comparing that attribute between configuration and real infrastructure, silencing the false-positive diff caused by an externally-managed value like an auto-injected tag. Option A is incorrect — `prevent_destroy` blocks destroy operations entirely; it has no effect on attribute-level drift or diffs. Option B is incorrect — `create_before_destroy` only changes the ordering of replacement operations; it doesn't suppress or ignore any attribute changes. Option D is incorrect — `replace_triggered_by` does the opposite of what's wanted here: it forces a resource to be replaced when a referenced value changes, rather than ignoring that change.

3. A team wants to upgrade all providers used in their configuration to the newest versions permitted by their existing version constraints, and update the dependency lock file accordingly. Which command should they run?

  • A. `terraform init -upgrade`✓ Correct
  • B. `terraform providers upgrade`
  • C. `terraform apply -upgrade-providers`
  • D. Manually delete `.terraform.lock.hcl` and run `terraform validate`
Explanation

Option A is correct. `terraform init -upgrade` re-resolves provider (and module) version selections to the newest versions allowed by the configuration's constraints, updating `.terraform.lock.hcl` to record the new selections. Option B is incorrect — `terraform providers upgrade` is not a real subcommand; `terraform providers` on its own just reports the provider requirements tree. Option C is incorrect — `apply` has no `-upgrade-providers` flag; provider resolution happens during `init`, not `apply`. Option D is a real but riskier path — deleting the lock file does force Terraform to re-resolve on the next `init`, but `terraform validate` does not perform provider installation or lock-file writing at all, so this sequence wouldn't actually upgrade or re-lock anything by itself.

4. A team notices `terraform plan` in CI is taking far longer than expected and suspects a specific provider is slow to respond during refresh. They temporarily set `TF_LOG=TRACE` and `TF_LOG_PATH=/tmp/tf-debug.log` for one CI run. After the run, what should they do with that log file?

  • A. Delete it immediately without ever opening it, since Terraform automatically parses it for them
  • B. Leave `TF_LOG` and `TF_LOG_PATH` permanently enabled in CI going forward so every run captures the same detail automatically
  • C. Review the log for timing and provider-communication detail to pinpoint the slow calls, then unset `TF_LOG`/`TF_LOG_PATH` again once the investigation is complete so routine runs stay lean✓ Correct
  • D. Attach it as-is to the state file so future `terraform plan` runs can reference it
Explanation

Option C is correct. This is the intended troubleshooting workflow: enable verbose logging for the run(s) needed to diagnose the issue, inspect the captured detail (which for `TRACE` includes provider plugin request/response timing useful for spotting slow calls), then turn logging back off so ordinary runs aren't burdened with unnecessary volume and disk usage. Option A is incorrect — nothing about Terraform automatically parses log files; a human (or tooling built for the purpose) needs to read them. Option B is incorrect — leaving `TRACE` logging on permanently in CI produces exactly the noise and storage overhead this domain's guidance warns against for routine use. Option D is incorrect — log files are unrelated to and never attached to the state file; they are separate diagnostic artifacts.

5. Before running `terraform import aws_db_instance.legacy db-prod-01`, what must already exist in the Terraform configuration for the import to succeed?

  • A. Nothing — `terraform import` writes the matching resource block into a `.tf` file automatically
  • B. A resource block named `aws_db_instance.legacy` must already be present, even if its arguments are empty or incomplete✓ Correct
  • C. A `data` block referencing the same identifier, which `terraform import` converts into a managed resource
  • D. An `import` block declaring the same `to` and `id` values, which `terraform import` reads before writing to state
Explanation

Option B is correct. The classic `terraform import` command only creates a state entry — it requires a corresponding resource block to already exist in configuration so that a subsequent `terraform plan` can compare state against configuration; otherwise Terraform has state for a resource with no matching config and will report an error. Option A is incorrect — plain `terraform import` never generates configuration; that capability belongs to the `-generate-config-out` flag used with `plan` and `import` blocks, not the standalone `import` command. Option C is incorrect — `data` blocks are read-only lookups and are never converted into managed resources by import. Option D is incorrect — an `import` block is a separate, alternative mechanism from the `terraform import` command; you would use one or the other, not both.

27 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free
Maintain infrastructure with Terraform — Free Terraform Associate Practice Questions | DataCertPrep — Certification Prep