Terraform Associate 004: State, Change and Collaborative Infrastructure

A Terraform plan looks reassuring until an engineer notices that applying it will replace the production database rather than update one property. Another team has moved a resource into a module, but the state still points to its old address; a third is about to copy secrets into a variable file checked into source control. These are not obscure edge cases. They are the situations that reveal whether infrastructure as code is being used with real engineering judgment.

HashiCorp's current Terraform Associate (004) exam tests Terraform 1.12 and combines foundational provider and CLI knowledge with state management, modules, configuration lifecycle behavior, sensitive-value handling and HCP Terraform collaboration. The version matters: its published comparison with 003 highlights newer attention to `depends_on`, `create_before_destroy`, custom validation, ephemeral values, write-only arguments and workspace/project organization. Preparation for the current 004 exam requires these version-specific decisions, while the unversioned Terraform Associate page explains the broader certification transition.

Understand the graph before executing a plan

Terraform evaluates configuration and resource references to build a dependency graph. An expression that uses one resource's output generally provides an implicit dependency; `depends_on` is useful when an operational dependency is real but not represented in such references. Overusing explicit dependencies can serialize work unnecessarily or obscure the actual relationships. A plan shows proposed resource actions after configuration, provider schemas and state are considered. Read the action symbols and reason for replacement, not only the summary count of additions and changes.

Create a simple web application that requires a network, security rules and an instance or container service. Change a reference so Terraform can infer ordering, then model a case where an explicit dependency is justified. Explain why the database should not be recreated merely to move its declaration between modules. Use a nonproduction state to test the change and document which business data would be at risk if an operator blindly applied the plan. Safe IaC begins with understanding consequences.

Control provider and Terraform versions predictably

Providers translate Terraform resource operations to platform APIs. Their version constraints and the dependency lock file help a team reproduce compatible behavior. The Terraform CLI version and provider version are separate concerns; upgrading one does not imply the other is safe. Terraform Associate 004 explicitly tests on Terraform 1.12, so candidates should understand the features available in that version rather than projecting later changes backward. Initialization, validation, planning and applying are distinct stages with different side effects.

Use a lab repository whose required provider version is pinned to a suitable range. Run initialization in a fresh working directory and inspect the selected version. Deliberately alter the version constraint in a branch and compare resulting configuration behavior without touching production infrastructure. Credentials should come from supported authentication mechanisms, not be hard-coded into provider blocks. A team that can reproduce its toolchain is better able to explain a surprising plan, roll back a faulty release and investigate drift.

One real-world review exercise compares what a plan says with what an operator expects to happen. If a changed module output propagates through several resources, ask which concrete values become unknown until apply and how that uncertainty affects risk. A reviewer should not simply approve because the plan contains no destroy actions; an overly broad network permission or a new administrator credential can be dangerous without any deletion. Define a small set of security and cost checks that require human judgment, then practice explaining the results to an application owner.

Use resource lifecycle rules for specific risks

The lifecycle settings such as `create_before_destroy` can be useful when a resource can be created in parallel before its predecessor is removed, but not every cloud resource or identity allows two instances to coexist. Precondition and postcondition checks, variable validation and `check` blocks have different scopes. Custom conditions should protect meaningful invariants such as a supported region, capacity threshold or required ownership label. They should not become a thicket of arbitrary assertions that prevents legitimate repair.

For a load-balanced service, describe how to provision a replacement backend and verify it before removing the old one. Compare that with a stateful database whose name, access endpoint or storage cannot be duplicated safely. A lifecycle directive will not magically preserve data or fix a schema migration. Add a variable validation rule that rejects an unsupported environment and observe when its error appears. Every safeguard should correspond to a real failure it is intended to prevent.

Protect ephemeral and write-only sensitive values

Sensitive Terraform variables can suppress ordinary display while still influencing state storage. Ephemeral values and supported write-only arguments can reduce persistence of certain secrets in compatible workflows, but they are not a universal replacement for credential security. Know which values a provider actually accepts through such arguments and how the secret reaches Terraform's execution environment. Keep remote state protected regardless, because many other resource attributes may remain confidential even when explicit passwords are not stored.

Design a database deployment that uses approved secret storage and avoids placing the secret in repository files or console output. Inspect the behavior of a supported write-only argument in a lab, including what Terraform can and cannot compare in later plans. Account for secret rotation and failed applies: the system should not require leaking the old password to recover from an error. The safe outcome is a documented secret lifecycle with minimal exposure, not just a declaration marked `sensitive = true`.

Treat state operations as production changes

State tracks managed resource instances and can be stored locally or remotely. Remote backends and HCP Terraform can support controlled collaboration, while locking protects against competing operations where supported. State is not a disposable cache: losing or corrupting it can make Terraform misidentify existing resources and propose dangerous recreation. Import brings an existing resource under management, `moved` blocks help preserve identity across refactoring, and removing an address from state requires understanding whether the real object should remain intact.

Rehearse moving a resource between module addresses in a disposable environment, then compare the plan before and after an appropriate moved declaration. Test importing an existing object and recording its necessary configuration. Do not hand-edit state files casually; protect backups and use supported commands under change review. Terraform modules and state are where most infrastructure migration risks become visible. A good operator can explain which state change affects Terraform's tracking and which action actually modifies cloud infrastructure.

Design module boundaries that survive team growth

Modules should encapsulate coherent infrastructure responsibilities with documented inputs and outputs. A module that creates every part of an application may look convenient but make small changes difficult to review and share across teams. Decide who owns a resource, its lifecycle and the meaningful values other modules need. Version shared modules and define provider requirements clearly. Avoid exposing confidential values through outputs or making hidden resources depend on implicit manual processes.

Build a reusable network module with a limited number of stable outputs and a separate application module that consumes them. Change the network CIDR in a test environment and inspect which downstream resources would be affected. A reviewer should be able to predict the blast radius from a small, readable plan. Discuss when a module should introduce an input rather than hard-code an organization's policy decision. Reuse is successful when it standardizes intent without making infrastructure opaque.

Organize HCP Terraform workspaces and projects

HCP Terraform includes remote execution, collaborative state, workspace and project organization, private registries, policy enforcement and team access features. The 004 exam explicitly includes organizing workspaces and projects. A workspace is an execution and state context, while a project can group related workspaces for administration and visibility. This is different from assuming each cloud project or environment must map directly to one HCP workspace without examining ownership and dependencies. Policy checks and run approval need clear authority.

For an organization with three application teams, model which workspaces manage shared networking and which manage application-specific infrastructure. Decide where variables and credentials come from and who may trigger, review and apply production runs. Review drift detection and the response to an out-of-band emergency fix. HCP Terraform can improve governance, but centralizing approvals without transparent operating procedures may slow recovery. HCP Terraform teams matter because collaboration has as many failure modes as configuration syntax.

Prepare with a deliberate failure scenario

Create a small repository using a modern Terraform 1.12-supported workflow. Include provider constraints, a versioned module, remote state in a safe lab and a validation rule. Introduce a resource change that would replace a stateful object and explain how the plan reveals it. Add a concurrent run and an intentionally missing secret. Determine which actions Terraform blocks automatically and which still depend on human approval and business risk assessment.

Finish with a migration rehearsal: import an object, refactor its address, check state and confirm that applying the plan produces only intended changes. A candidate who can distinguish a safe plan from a dangerous but syntactically valid one demonstrates the core competency. HashiCorp Associate (004) is a foundation for controlled infrastructure operations; passing it should correspond to the ability to articulate exactly what Terraform will manage and why.