Hedronite · Cert Lesson · Cert-Prep / HashiCorp · Fri 2026-09-11

Terraform Associate: remote backends — partial config and state migration

The exam asks where state lives, how init learns that address, and what happens when the address changes.

Lesson Class: Cert-Prep (Terraform Associate 003 / Pro-depth)

Paired Ops: Terraform partial backend config: S3 keys at init time

Paired Dev: HCL backend blocks: partial config and init-time injection

Paired Go: DynamoDB DescribeTable Terraform lock inventory

Grounding: Lab 31 · Lab 04 · Brikman Ch.3

Init

Learn the backend address.

Reconfigure

Change address without moving state.

Migrate

Move state when the address changes on purpose.

Init, reconfigure, migrate: name the intent.

The exam asks where state lives, how init learns that address, and what happens when the address changes.

§I — Frame

09-08 Cert practiced validation, check blocks, and terraform test. 09-05 Cert practiced terraform.workspace guardrails. 08-18 Cert practiced force-unlock hazard. Those stay filed.

Today the Associate and Pro-depth slot returns to remote backends with a sharper question: how does a root stay environment-agnostic while still using S3 (or another remote store)? The answer is partial backend configuration plus explicit migration or reconfigure flags.

§II — Objective map

Remote backend purpose. Store state off the laptop. Enable team and CI access. Prefer a locking backend so two applies cannot interleave writes. S3+DynamoDB is the AWS pair; know that locking is backend-specific.

Backend block constraints. No variables. No locals. No resource attributes. Configure at init. This is a frequent exam discriminator against "just use var.environment in the key."

Partial configuration. Omit arguments in the committed backend block. Supply them with:

terraform init -backend-config=backend.hcl
terraform init -backend-config="bucket=acme-tfstate" -backend-config="key=app/dev.tfstate"

Changing backends.

| Intent | Flag | Effect |

|---|---|---|

| Point this directory at a different backend without copying state | -reconfigure | Drops prior backend settings; does not move the object |

| Copy state from the previous backend address to the new one | -migrate-state | Interactive unless scripted carefully; moves the authoritative object |

| First init on a fresh directory | (none) | Creates local backend metadata under .terraform/ |

State isolation versus workspaces. Workspaces are named states under one configuration. File layout with distinct key values is the stronger promotion boundary. Partial config serves file layout.

§III — Practice prompts

Q1. A root module sets key = local.env_key inside backend "s3". What happens at terraform init, and what pattern replaces it?

Answer: Init rejects or fails to interpolate the local because the backend is not graph-evaluated. Use a partial backend plus -backend-config (Lab 31 / Brikman Limitations).

Q2. CI reuses a checkout that previously inited against network/dev.tfstate and now must plan network/prod.tfstate. Which flag belongs on init, and why not omit it?

Answer: -reconfigure (unless you intentionally -migrate-state). Omitting it risks planning against the previous backend metadata still cached in .terraform/.

Q3. Distinguish terraform_remote_state from the root's own backend configuration in one sentence each.

Answer: The root backend is where *this* configuration reads and writes its state. terraform_remote_state is a data source that *reads outputs* from another configuration's state.

Q4. A teammate proposes workspaces instead of separate keys for prod and staging. What Associate-relevant tradeoff do you cite?

Answer: Workspaces share one configuration and one backend bucket namespace pattern; they are weaker as a promotion bulkhead than separate roots and keys (file layout).

Q5. Partial config leaves dynamodb_table to backend.hcl. Does that change when the lock is acquired?

Answer: No. Once init merges the table name, plan and apply acquire and release the lock as with a fully inline backend. Partial config changes *when* the table name is known (init), not *whether* locking occurs.

§IV — Pro-depth notes

HCP Terraform / TFE can own remote operations so local backends are unnecessary for day-to-day applies. Still know CLI partial config for modules developed outside HCP and for disaster recovery against an S3 mirror. Force-unlock remains a Pro operations hazard (08-18); do not conflate it with -reconfigure.

§V — Closing

Name three verbs for the exam: init (learn the address), reconfigure (change the address without moving state), migrate (move state to the new address). Partial configuration is how environment identity enters init without entering the backend expression dialect. Drill Lab 31 until the empty bucket/key/region shape feels normal.