Terraform Associate · 12% of the exam

Terraform state management: free practice questions

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

1. A HCP Terraform workspace is configured with a remote backend. A developer runs `terraform state pull` from their local machine. What does this command do, and what format is the output?

  • A. It downloads the current state file from the remote backend and prints it to stdout in raw JSON format✓ Correct
  • B. It compares the local state with the remote state and prints a human-readable diff
  • C. It locks the remote state and prevents other operations until `terraform state push` is run
  • D. It retrieves the state and writes it to a local `terraform.tfstate` file, overwriting any existing local state
Explanation

`terraform state pull` retrieves the current state from the configured backend (including remote backends like HCP Terraform) and prints it to stdout as raw JSON. This is useful for inspecting state, piping it to tools like `jq`, or creating a local backup. Option B is wrong: `state pull` does not perform a diff; it simply retrieves and prints the current state. Option C is wrong: `state pull` is a read-only operation and does not acquire a lock (state-modifying commands like `apply` acquire locks). Option D is wrong: `state pull` writes to stdout, not to a file; if you want to save it, you redirect stdout (e.g., `terraform state pull > backup.tfstate`).

2. A Terraform configuration manages a fleet of `aws_instance` resources using `for_each` with the following map variable: ```hcl variable "servers" { default = { web = "t3.micro" api = "t3.small" jobs = "t3.medium" } } resource "aws_instance" "fleet" { for_each = var.servers instance_type = each.value ami = "ami-0abcdef1234567890" } ``` A team member removes the `web` key from the map variable and runs `terraform apply`. What happens?

  • A. Terraform destroys `aws_instance.fleet["web"]` and leaves the other instances untouched✓ Correct
  • B. Terraform recreates all three instances because the `for_each` map changed
  • C. Terraform shifts the remaining instances down so `api` becomes index 0, causing two replacements
  • D. Terraform returns an error because you cannot remove keys from a `for_each` map without first running `terraform state rm`
Explanation

Option A is correct: with `for_each`, each resource instance is keyed by the map key (`"web"`, `"api"`, `"jobs"`). Removing `"web"` causes Terraform to plan the destruction of only `aws_instance.fleet["web"]`; the other keyed instances are unaffected because their keys remain stable. Option B is incorrect: this behavior describes the problem with `count`-based indexing, not `for_each`. Option C is also a `count` misconception—index shifting does not apply to `for_each`. Option D is incorrect: there is no requirement to manually `terraform state rm` before removing a `for_each` key; Terraform handles the removal through a normal plan/apply cycle.

3. A team is migrating their Terraform state from a local backend to an S3 remote backend. They update the backend configuration and run `terraform init`. What does Terraform do during this initialization?

  • A. Terraform creates a new empty state file in S3 and leaves the local state file intact
  • B. Terraform prompts the user to confirm whether they want to copy the existing local state to the new S3 backend✓ Correct
  • C. Terraform automatically copies the local state to S3 without any user interaction
  • D. Terraform requires the user to manually run `terraform state push` to migrate the state after `terraform init` completes
Explanation

Option B is correct. When `terraform init` detects that the backend configuration has changed (or a new backend is being configured), it detects any existing state and interactively asks the user whether they want to copy the existing state to the new backend. This is the standard state migration workflow. Option A is incorrect — Terraform does not silently create an empty state and leave the old one behind; that would result in a loss of state tracking. Option C is incorrect — Terraform does NOT automatically copy state without confirmation; it always prompts because copying or migrating state is a significant and potentially irreversible operation. Option D is incorrect — manually running `terraform state push` is not required; the migration is handled by `terraform init` itself after user confirmation.

4. A Terraform configuration uses the following `for_each` expression: ```hcl resource "aws_subnet" "private" { for_each = var.subnet_config vpc_id = aws_vpc.main.id cidr_block = each.value.cidr availability_zone = each.value.az } ``` An engineer wants to reference a specific subnet output from this resource in another resource. Which resource address correctly references the subnet with key `"us-east-1a"`?

  • A. `aws_subnet.private[0].id`
  • B. `aws_subnet.private["us-east-1a"].id`✓ Correct
  • C. `aws_subnet.private.us-east-1a.id`
  • D. `module.aws_subnet.private["us-east-1a"].id`
Explanation

Option B is correct. When `for_each` is used with a map (or set of strings), resources are addressed using the key in bracket notation with a quoted string: `aws_subnet.private["us-east-1a"]`. Option A is wrong — bracket notation with a numeric index (`[0]`) is used for `count`-based resources, not `for_each` map resources. Option C is wrong — dot notation without brackets is not valid for accessing `for_each` instances. Option D is wrong — the `module.` prefix is used to reference resources inside a child module, not for resources in the root module; this address format would only be valid if `private` were a module call.

5. A Terraform engineer runs `terraform plan -refresh-only`. What does this command do, and how does the output differ from a standard `terraform plan`?

  • A. It re-downloads all provider plugins and refreshes the lock file, but does not evaluate resource changes.
  • B. It compares the real infrastructure state against the Terraform state file and proposes updates *only* to the state file to reflect any drift, without proposing changes to match the desired configuration.✓ Correct
  • C. It performs a full plan that includes both drift detection and all pending configuration changes, identical to `terraform plan`.
  • D. It destroys all resources and re-creates them to ensure infrastructure matches the configuration exactly.
Explanation

Option B is correct. `terraform plan -refresh-only` queries the real infrastructure, identifies any attributes that have drifted from what is recorded in state, and proposes a state file update to reflect the current real-world values — it does NOT propose resource creation, updates, or deletions to match desired configuration. Option A is wrong — `-refresh-only` has nothing to do with provider plugins or the lock file. Option C is wrong — a standard `terraform plan` evaluates configuration changes on top of refreshed state; `-refresh-only` stops after the refresh phase and only proposes state updates. Option D is wrong — that describes a destroy-and-recreate workflow, not `-refresh-only`.

57 more questions in this domain

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

Start practicing free