Terraform Associate 003 — State, Backends, and the Core Workflow

The exam is not a memory test for flags. It is a test of whether you understand what Terraform is doing when you run it.

State and the workflow are not two topics. They are one loop: the workflow is the only sanctioned way to change state, and state is the memory the workflow reads and writes.

§ IFrame

The Terraform Associate 003 exam is not a memory test for command flags. It is a test of whether you understand what Terraform is doing when you run it. Two of its nine objective areas carry most of that understanding: Objective 4, which is Terraform state, and Objective 5, which is the core Terraform workflow. Get those two right and the rest of the exam is vocabulary. Get them wrong and no amount of flag memorization saves you, because you will not understand why the flags exist.

Today's trio drills exactly this surface. The Ops lesson gave you state as a concept and the backend as the thing that protects it. The Dev lesson tested the plan the workflow produces. This cert lesson takes the same two ideas and shapes them the way the exam asks: precise, scenario-driven, and about the mental model rather than the syntax.

§ IIDomain Foundations — The Two Objectives Share One Spine

State and the workflow are not two separate topics. They are one loop seen from two angles. The core workflow is write, plan, apply. Every step of that loop reads or writes state. write produces config that state will be compared against. plan reads state, refreshes it against the real world, and computes a diff. apply executes the diff and writes the new state. State is the memory the workflow depends on; the workflow is the only sanctioned way to change state. The exam tests whether you can hold both in one picture.

Brikman's state chapter, which grounds this lesson, frames the whole thing around a single problem: state that lives on one laptop cannot be shared, cannot be locked, and stores secrets in plain text. The exam's Objective 4 is essentially a set of questions about how remote backends answer that problem, and Objective 5 is a set of questions about the commands that read and write state safely.

§ IIIObjective 4 Flavor — State and Backends

The exam wants five things about state to be automatic for you.

What state is for. State maps your configuration's resource addresses to real provider IDs, tracks metadata and dependencies, and is how Terraform knows what it already manages. Without it, Terraform cannot tell an existing resource from one it needs to create.

Local versus remote backends. The default backend is local: terraform.tfstate on disk. A remote backend stores state in a shared service such as S3, Azure Storage, Google Cloud Storage, or Terraform Cloud. The exam repeatedly rewards the reason for remote state: sharing across a team, encryption of the file at rest and in transit, and locking to prevent concurrent corruption.

State locking. When a backend supports locking, Terraform acquires a lock during operations that write state, so two applies cannot run against the same state at once. Not every backend locks. S3 needs a companion DynamoDB table to provide the lock; the S3 bucket alone stores but does not lock. Know that pairing cold. It is a favorite exam scenario.

Sensitive data in state. State stores values in plain text, including secrets a resource needed to be created. This is why state belongs in an encrypted, access-controlled backend and never in version control. The exam tests this as a security-awareness question, not a trivia question.

State isolation. Separate state files per environment or component limit blast radius. Brikman's guidance is to isolate state by placing different components at different backend keys or workspaces, so a mistake in staging cannot reach production state. The exam frames this as "how do you keep environments from interfering."

§ IVObjective 5 Flavor — The Core Workflow and Its Commands

Objective 5 is the loop and the commands that run it. Five commands carry the weight.

terraform init prepares a working directory. It downloads provider plugins, initializes the backend, and installs modules. Run it first in any new directory, after adding a provider or module, and after changing the backend. An uninitialized directory cannot plan.

terraform plan computes and shows the execution plan without changing anything. It refreshes state, diffs against config, and prints what it would create, update, or destroy. This is the safe rehearsal step, and -out saves the plan so apply executes exactly what you reviewed.

terraform apply executes the changes. Given a saved plan file, it applies that plan without re-prompting. Given no plan file, it computes a fresh plan and asks for confirmation. It acquires the state lock, writes to the world, then writes new state.

terraform destroy removes the resources under management. It is apply in reverse, and the exam expects you to know it is state-driven: it destroys what state records, not what is in the config.

terraform validate and terraform fmt check syntax and format. validate confirms the configuration is internally consistent without touching any remote state or provider. fmt rewrites files to canonical style. Both belong early in CI, before plan.

The exam loves the ordering. init before plan, plan before apply, validate needs only a config and not credentials. A common trap asks which command you run after changing a backend configuration: the answer is init, because the backend is initialized there, and Terraform will offer to migrate existing state to the new backend during that init.

§ VWorked Scenario — Promoting a Module Through Environments Safely

A team keeps one networking module and deploys it to staging and production. They want the exam-correct posture: shared state, locking, isolation, and a workflow that never surprises them. The setup answers every objective in one shape.

Each environment gets its own backend key so staging state and production state never touch. The backend is S3 with a DynamoDB lock table, so every apply in either environment acquires a lock and no two engineers collide. The CI pipeline runs terraform init, then terraform validate, then terraform plan -out=tfplan, and a human reviews the plan before a second job runs terraform apply tfplan against the saved file. Because apply consumes the saved plan, it does exactly what was reviewed, with no drift between review and execution. Brikman's CI chapter shows this same shape using GitHub Actions with OIDC, where the pipeline authenticates to the cloud without long-lived stored credentials, which is the current best-practice answer the exam is moving toward.

Read what each choice defends. The per-environment key defends isolation, so a bad staging apply cannot corrupt production state. The DynamoDB lock defends against concurrency, so two applies queue instead of colliding. The saved plan defends against the gap between what a human approved and what ran. This one scenario touches Objective 4's state and locking and Objective 5's init-plan-apply loop, which is why a team that operates this way tends to pass the exam almost as a side effect of working correctly.

§ VIConnection to Today's Ops and Dev Lessons

The three lessons drill one surface from three angles. The Ops lesson built the backend and named the lock as the thing that keeps a shared ledger honest, and it read drift through plan. The Dev lesson took the plan the workflow produces, wrote it to JSON, and asserted a module's contract in pytest before any apply. This cert lesson frames both as the exam frames them: state is Objective 4, the workflow is Objective 5, and the two are one loop. If you can run the §V scenario and explain why each piece is there, you have the two heaviest objective areas, and you have them because you built the thing, not because you memorized it.

§ VIIPractice Questions

§ VIIIClosing

Objectives 4 and 5 are not two topics to study separately. They are one loop: the core workflow is the only sanctioned way to change state, and state is the memory the workflow reads and writes. Learn remote backends for what they buy — sharing, encryption, locking — and learn the command order for the reasons behind it, not the flags. A candidate who can stand up the §V scenario and defend every choice in it has already answered most of what the exam will ask, because the exam is testing whether you understand the machine you just built.

Before you sit the exam, provision the §V setup once with your own hands. An S3 bucket, a DynamoDB lock table, two backend keys, a plan you save and apply. The questions you would have missed become obvious the moment the lock table is the thing standing between you and a corrupted state file.

Paired lessons → Ops 01-Earth-DevOps/Synthesis-Lessons/2026-07-22-terraform-state-... · Dev Polyglot-Dev/Python/2026-07-22-testing-terraform-with-python-...