What topics does Terraform Pro 002 domain 2 cover?

The official exam guide splits Terraform state and backend operations into 3 topics: Remote backends and remote state, Inspecting state and remediating drift and Dependency chains and Terraform version upgrades. Every practice question on this page is mapped to one of them, and the table above shows how many questions each topic has.

Should I practise Terraform state and backend operations on its own?

Drill it on its own while you are learning it or when it is your weakest domain — a focused session makes the patterns in its questions obvious quickly. Once your accuracy here is steady, switch back to mixed sessions across every domain: the real exam interleaves them, and recognising which domain a question belongs to is part of the skill.

Terraform Pro 002 · Domain 2

Terraform state and backend operations practice questions

Q: How many Terraform state and backend operations practice questions are there?

105 published questions are mapped to this domain, each with an explanation on every option, backed by 3 revision lessons on the same topics. You can answer 5 a day without an account; a free account raises the daily allowance.

Terraform state and backend operations is worth 13% of the Terraform Pro 002 exam — the 3rd-heaviest of the 7 domains. Remote backends and remote state, inspecting and managing state, remediating drift, and upgrading Terraform safely across environments. Weight approximates the sub-objective share. 6 fully worked examples are further down this page, answers included.

Exam weight: 13%
the 3rd-heaviest of the 7 domains
Questions: 105
across 3 topics
Free, no account: 5/day
a free account allows 10 a day
Explanations: Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 7 domains, in Learn mode.

Review what you missed

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Terraform state and backend operations questions, fully explained

Questions from the Terraform Pro 002 bank mapped to domain 2, with the answer key and the reasoning behind every option. None of them repeat the examples on the main Terraform Pro 002 practice page.

Question 1Terraform state and backend operations

One root configuration is deployed to dev and prod, and each environment keeps its state in a different S3 bucket in a different account. The team wants a single committed backend block, no generated or duplicated Terraform files per environment, and no secrets on the command line. How should the pipeline select each environment's bucket?

Choose one.

a
Commit a backend_override.tf per environment that redefines the bucket argument
Override files do merge into the backend block, but they are per-environment Terraform files, which the requirement rules out.
b
Create a prod workspace with terraform workspace new prod before running init
Workspaces keep separate state objects inside the same configured backend; they cannot point prod at a different bucket in another account.
c
Omit bucket from the block and run init with -backend-config=prod.s3.tfbackend Correct
Partial configuration lets the shared block omit bucket while a small per-environment .tfbackend file supplies it at init, with no Terraform files duplicated.
d
Export TF_VAR_bucket in each job and set bucket = var.bucket in the block
TF_VAR_ variables set input variables, and a backend block cannot reference input variables at all.

The concept

Partial backend configuration supplies some backend arguments at init time from a file or key/value flags.

Why that’s the answer

The block keeps the shared arguments and leaves bucket out; terraform init -backend-config=prod.s3.tfbackend merges the environment's value in. HashiCorp recommends the *.backendname.tfbackend naming. Override files work mechanically but are per-environment Terraform files, workspaces cannot change the bucket, and variables cannot be used in a backend block.

How to reason it out

List the constraints: one committed block, no per-environment .tf files.
Recall partial configuration via -backend-config files.
Reject override files, which are extra Terraform files.
Reject workspaces, which share the configured bucket.

Exam tip: Different buckets per environment: one block, one .tfbackend file per environment, passed at init.

Terraform Professional: Remote Backends and Remote State — the lesson that teaches this.

Question 2Terraform state and backend operations

A pipeline runs terraform init with -backend-config="access_key=..." and -backend-config="secret_key=...", then terraform plan -out=tfplan. A security review asks where copies of those two values now exist. Which TWO locations hold them? (Select TWO.)

Choose TWO.

a
The .terraform/terraform.tfstate file in the working directory Correct
Terraform records the current backend configuration, including values passed with -backend-config, in .terraform/terraform.tfstate.
b
The remote state object that the plan read from the S3 bucket
The state snapshot stores resources and outputs, not the backend configuration used to reach it.
c
The saved plan file that the -out flag wrote to disk Correct
Plan files capture the backend information from .terraform/terraform.tfstate at the time the plan was created.
d
The .terraform.lock.hcl file that init writes beside the configuration
The dependency lock file records provider versions and checksums, not backend arguments.
e
The terraform.tfstate.backup file that init writes beside the configuration
A backup file is a copy of state written by local state operations; it does not contain backend arguments, and init does not write one for a remote backend.

The concept

Values given to a backend through configuration or -backend-config are persisted in the working directory and in saved plans.

Why that’s the answer

Terraform writes the effective backend configuration, credentials included, to .terraform/terraform.tfstate, and every saved plan captures that information. The remote state object and the dependency lock file hold different data. That is why HashiCorp recommends supplying backend credentials through environment variables and never committing the .terraform directory.

How to reason it out

Separate backend configuration from state data.
Recall that .terraform stores the current backend configuration.
Recall that saved plans embed the backend information.
Rule out the lock file and remote state, which hold other data.

Exam tip: Anything passed to -backend-config ends up in .terraform and in saved plan files.

Terraform Professional: Remote Backends and Remote State — the lesson that teaches this.

Question 3Terraform state and backend operations

A platform team needs the S3 backend to authenticate in CI without the access key ever being written into the working directory or saved plan files. Which approach follows HashiCorp's guidance?

Choose one.

a
Provide the credentials to init through AWS environment variables Correct
HashiCorp recommends environment variables for backend credentials; they are not written into .terraform or plan files.
b
Provide the credentials to init through -backend-config key=value pairs
Values passed with -backend-config are stored in .terraform and captured in plan files, and shells may keep them in history.
c
Provide the credentials to init through an uncommitted .s3.tfbackend file
A .tfbackend file is still partial backend configuration, so its values are persisted to .terraform and saved plans.
d
Provide the credentials to init through access_key in the backend block
Hard-coded backend values are stored in the configuration and in .terraform, the opposite of the requirement.

The concept

Backend credentials should come from environment variables (or the platform's identity), not from backend configuration.

Why that’s the answer

Every way of putting a credential into backend configuration, whether in the block, a .tfbackend file or -backend-config pairs, persists it in .terraform/terraform.tfstate and in saved plans. Environment variables such as AWS_ACCESS_KEY_ID, or better a role the runner already assumes, keep it out of both.

How to reason it out

Note the requirement: nothing written to .terraform or plans.
Recall that all backend configuration paths persist values.
Choose environment variables, which are read but not stored.

Exam tip: Backend secrets go in environment variables, never in backend configuration.

Terraform Professional: Remote Backends and Remote State — the lesson that teaches this.

Question 4Terraform state and backend operations

A team changes its S3 backend key from "network.tfstate" to "prod/network.tfstate" in the same bucket. The existing state must end up at the new key so the next plan shows no changes. Which command should an engineer run next?

Choose one.

a
terraform init -reconfigure
-reconfigure disregards the existing configuration and does not migrate state, so the new key starts empty.
b
terraform init -upgrade
-upgrade updates providers and modules within their version constraints; it does not handle a backend change.
c
terraform init -backend=false
-backend=false skips backend initialization entirely, so nothing is copied and later commands still fail.
d
terraform init -migrate-state Correct
-migrate-state detects the changed backend configuration and copies the existing state to the new location.

The concept

When the backend configuration changes, init needs either -migrate-state (copy state) or -reconfigure (start fresh).

Why that’s the answer

Changing the key is a backend configuration change, so init must be re-run with one of two flags. -migrate-state copies existing state to the new location; -reconfigure ignores the old configuration and leaves the new key empty, which would make the next plan propose creating everything again.

How to reason it out

Recognise the key change as a backend change.
Recall the two flags init accepts for a backend change.
Pick the one that copies state: -migrate-state.

Exam tip: Moving state to a new backend location: init -migrate-state; starting fresh: init -reconfigure.

Terraform Professional: Remote Backends and Remote State — the lesson that teaches this.

Question 5Terraform state and backend operations

A reviewed change moves a project's state from one S3 bucket to another by editing the bucket argument in its backend "s3" block. The CI runner's working directory is still initialized against the old bucket, the new bucket is empty, and the job runs with no terminal attached. Which init command copies the existing state to the new bucket in that job?

Choose one.

a
terraform init -migrate-state -input=false
Migration still asks for confirmation; with input disabled and no -force-copy, Terraform aborts the migration with an error.
b
terraform init -migrate-state -force-copy -input=false Correct
-migrate-state requests the copy from the old bucket and -force-copy answers its confirmation prompts with yes, so it completes with input disabled.
c
terraform init -reconfigure -force-copy -input=false
-reconfigure discards the saved old-bucket backend and initializes the new bucket as a first-time setup; there is no local state to copy, so the new bucket stays empty.
d
terraform init -reconfigure -input=false
-reconfigure initializes the new bucket without reading the old one, leaving the new key empty and the state behind in the old bucket.

The concept

State migration needs confirmation; in non-interactive runs -force-copy supplies it.

Why that’s the answer

Two facts decide this. First, when an initialized working directory switches backends, only -migrate-state copies the state from the old backend; -reconfigure forgets the old backend and starts the new one empty. Second, migration prompts for confirmation, and with -input=false Terraform aborts rather than guess. -force-copy suppresses those prompts by answering yes (and on its own implies -migrate-state), so -migrate-state -force-copy -input=false is the non-interactive form.

How to reason it out

Choose -migrate-state because state must be copied from the old bucket.
Note the job cannot answer prompts (-input=false).
Recall that migration prompts abort when input is disabled.
Add -force-copy to answer the prompts automatically.

Exam tip: Unattended state migration: init -migrate-state -force-copy -input=false.

Terraform Professional: Remote Backends and Remote State — the lesson that teaches this.

Question 6Terraform state and backend operations

After changing the S3 backend key from "app.tfstate" to "apps/app.tfstate", an engineer ran terraform init -reconfigure. The next plan proposes creating all 42 existing resources. Which statement explains the plan?

Choose one.

a
Init pointed Terraform at the new key without copying the state that was stored at the old key Correct
-reconfigure disregards the previous backend configuration and does not migrate state, so Terraform now reads an empty state.
b
Init deleted the state object stored at the old key after it had configured the new key
Neither flag deletes the old state object; it is still in the bucket and can be migrated or restored.
c
Init released the state lock, so the plan ran without reading the state at the new key
Locking controls concurrent writes; it does not stop Terraform reading state, and the new key simply has none.
d
Init refreshed the state at the old key and found that the 42 resources had drifted away
init does not refresh resources, and drift would show updates or replacements for tracked objects, not a full create.

The concept

-reconfigure starts the backend fresh and leaves existing state where it was.

Why that’s the answer

With -reconfigure, Terraform treats the new backend location as the source of truth without migrating anything, so the plan sees an empty state and proposes creating every resource. The original object at the old key is untouched, which is what makes recovery possible (point back at it and use -migrate-state).

How to reason it out

Note which flag ran: -reconfigure.
Recall that -reconfigure never migrates state.
Explain the plan: Terraform reads an empty state at the new key.
Note the old object still exists for recovery.

Exam tip: A full create plan after a backend change usually means -reconfigure was used where -migrate-state was needed.

Terraform Professional: Remote Backends and Remote State — the lesson that teaches this.

What Terraform Pro 002 domain 2 tests, topic by topic

The official exam guide breaks Terraform state and backend operations into 3 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published Terraform Pro 002 practice questions per topic in Terraform state and backend operations
Topic	What it covers	Questions
Remote backends and remote state	Official Terraform Infrastructure Engineer Professional (002) objectives, 2a Create and manage Remote Backend and Remote State Configuration.	35
Inspecting state and remediating drift	Official Terraform Infrastructure Engineer Professional (002) objectives, 2b Manage state and remediate drift; 2e Inspect Terraform state.	35
Dependency chains and Terraform version upgrades	Official Terraform Infrastructure Engineer Professional (002) objectives, 2c Identify dependency chains before upgrades; 2d Upgrade Terraform versions across environments.	35
Total		105

Revise Terraform state and backend operations before you drill it

Other Terraform Pro 002 domains

Terraform state and backend operations: your questions

Terraform state and backend operations is domain 2 of the Terraform Pro 002 exam guide and carries 13% of the scored content — the 3rd-heaviest of the 7 domains. HashiCorp has not yet published the exam's question count, so there is no per-domain number of questions to give.

Source

The domain weight and topic list on this page come from the official Terraform Pro 002 exam guide.

HashiCorp Terraform Infrastructure Engineer Professional (002) exam page — HashiCorp