004 — HashiCorp Certified: Terraform Associate Exam Blueprint

How to use this exam blueprint

Use this page as an independent readiness map for the HashiCorp Certified: Terraform Associate (004) exam from HashiCorp. It is designed to help you turn broad Terraform exam topics into concrete review tasks.

Do not treat the order of topics as an exam weighting. Instead, use the checklist to answer three questions:

1. Can I explain the concept clearly?
2. Can I recognize the right Terraform command, file, or workflow in a scenario?
3. Can I avoid common traps around state, dependencies, variables, modules, and remote execution?

A good final-review target: for each row below, you should be able to explain the concept, identify the relevant Terraform artifact, and predict what Terraform will do next.

Topic-area readiness table

Terraform workflow you must be ready to recognize

    flowchart LR
	    A[Write or update .tf files] --> B[terraform fmt]
	    B --> C[terraform init]
	    C --> D[terraform validate]
	    D --> E[terraform plan]
	    E --> F{Review changes}
	    F -->|Accept| G[terraform apply]
	    F -->|Reject| A
	    G --> H[State updated]
	    H --> E

Ready means you can explain each step

CLI command checklist

“Can you do this?” core skills checklist

Terraform fundamentals

• Explain declarative configuration: desired end state, not step-by-step imperative instructions.
• Explain why Terraform compares configuration, state, and real infrastructure.
• Describe the difference between Terraform CLI, providers, modules, state, and backends.
• Explain why state is required for mapping resource addresses to real objects.
• Recognize that Terraform is not a general-purpose configuration management tool.
• Explain idempotence in practical terms: repeated runs should converge on desired state when inputs are unchanged.
• Describe drift and how Terraform detects proposed remediation during planning.

Configuration language and files

• Identify .tf files as Terraform configuration files loaded together in a module directory.
• Read HCL blocks, labels, arguments, nested blocks, expressions, and references.
• Distinguish resource, data, variable, locals, output, module, provider, and terraform blocks.
• Explain that file names do not define dependency order.
• Use comments, formatting, and naming conventions to make configuration easier to review.
• Recognize when a value is known only after apply.
• Identify interpolation and direct references, such as var.name, local.tags, and module.network.id.

Providers

• Explain providers as plugins that translate Terraform operations into API calls.
• Configure required_providers with source and version constraints.
• Explain why .terraform.lock.hcl matters for reproducible provider selections.
• Know when to run terraform init after provider changes.
• Explain provider authentication at a high level without hard-coding secrets.
• Use provider aliases conceptually for multiple accounts, regions, subscriptions, projects, or endpoints.
• Recognize provider-specific errors versus Terraform syntax errors.

Resources and data sources

• Explain that resources are managed by Terraform.
• Explain that data sources read existing information for use in configuration.
• Read a resource address such as resource_type.name or module.app.resource_type.name.
• Predict when Terraform will create, update, replace, or destroy a managed object.
• Explain why some argument changes require replacement while others update in place.
• Recognize that provider behavior determines many resource-specific details.

Variables, locals, and outputs

• Define input variables with type constraints, defaults, descriptions, and validation.
• Explain common variable value sources, including CLI flags, .tfvars, auto-loaded files, environment variables, defaults, and remote workspace variables.
• Use locals to name computed values and reduce repetition.
• Use outputs to expose root module or child module values.
• Mark variables and outputs as sensitive when appropriate.
• Explain that sensitive values can still be stored in state.
• Troubleshoot an unset required variable.

Expressions and collection handling

• Read string, number, bool, list, map, object, and set values.
• Use conditionals for simple branching.
• Understand for expressions at a reading level.
• Explain count and for_each differences.
• Predict why for_each with stable keys is often safer than count with list indexes.
• Recognize common functions such as length, lookup, merge, toset, join, and templatefile at a conceptual level.
• Identify when a value cannot be known until apply.

Dependencies and lifecycle

• Explain implicit dependencies from references.
• Explain when explicit depends_on is appropriate.
• Recognize that Terraform builds a dependency graph.
• Predict high-level create and destroy order from references.
• Explain lifecycle behaviors such as preventing accidental destruction or creating replacements before destroying old objects.
• Recognize when lifecycle settings can hide or complicate drift.
• Explain replacement triggers at a concept level.

State and backends

• Explain local state versus remote state.
• Explain state locking and why teams need it.
• Identify sensitive data risks in state.
• Explain why state files should not be casually edited, copied, or committed.
• Know the difference between removing an object from state and destroying the object.
• Explain when state movement can support refactoring.
• Recognize backend initialization and migration prompts.
• Explain why backend configuration changes require care.

Modules

• Explain root module and child module.
• Call a module using source.
• Pass variables into a child module.
• Read outputs from a child module.
• Understand local modules, registry modules, and version-pinned remote modules at a high level.
• Explain why modules improve reuse but do not eliminate the need to understand state and providers.
• Recognize module nesting in resource addresses.

HCP Terraform and remote workflows

• Explain why teams use remote execution and shared workspaces.
• Distinguish Terraform CLI local execution from remote runs.
• Recognize VCS-driven run workflows at a high level.
• Know that variables can be managed in remote workspaces.
• Explain remote state, locking, run history, and collaboration benefits.
• Recognize that provider credentials for remote runs must be available to the remote execution environment.
• Explain that workspace names and state context matter before planning or applying.

HCL readiness checks

You do not need to memorize every provider-specific argument for the HashiCorp Certified: Terraform Associate (004) exam. You should be comfortable reading the structure and predicting Terraform behavior.

Provider and Terraform block pattern

terraform {
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.0"
    }
  }
}

provider "random" {}

Can you explain?

• What required_providers controls.
• What provider source means.
• Why version constraints matter.
• Why terraform init is needed before planning.
• Why provider plugins are separate from the Terraform CLI.

Variables, locals, and outputs

variable "environment" {
  type        = string
  description = "Deployment environment"

  validation {
    condition     = contains(["dev", "test", "prod"], var.environment)
    error_message = "Environment must be dev, test, or prod."
  }
}

locals {
  name_prefix = "app-${var.environment}"
}

output "prefix" {
  value = local.name_prefix
}

Can you explain?

• When validation is evaluated.
• Why locals can simplify repeated expressions.
• How an output is accessed from the root module.
• What changes if an output is marked sensitive = true.

Module call pattern

module "network" {
  source      = "./modules/network"
  environment = var.environment
}

output "network_id" {
  value = module.network.id
}

Can you explain?

• Which directory is the root module.
• Which directory is the child module.
• How input variables are passed to the child module.
• How child module outputs are exposed.
• Why child module resources appear with module paths in state.

Multiple instances pattern

variable "names" {
  type = set(string)
}

resource "example_resource" "item" {
  for_each = var.names

  name = each.key
}

Can you explain?

• Why for_each creates addressable instances by key.
• Why sets and maps are commonly used with for_each.
• How changing a key can affect resource identity.
• How this differs from count.index.

State readiness checklist

State is one of the most tested practical concepts because it affects safety, collaboration, and troubleshooting.

State scenario checks

Providers and dependency lock file

Be ready to reason about provider installation and version selection.

Module readiness table

Module self-test prompts

• Can you identify all inputs a module requires?
• Can you identify which outputs a module exposes?
• Can you explain why changing a module source or version may require terraform init?
• Can you trace a resource address inside module.network or module.app.module.database?
• Can you explain why copying a module is different from versioning and reusing it?
• Can you explain why a module should not rely on undeclared root variables?

Variable precedence and value-source checks

You should know that Terraform can receive variable values from multiple places. Exact precedence details are worth reviewing in your Terraform study materials, but for exam readiness you should be able to identify likely sources and troubleshoot conflicts.

Variable traps

• A variable declared without a default must be provided.
• locals are not input variables.
• Outputs do not pass values into a module; inputs do.
• Marking a variable sensitive changes display behavior, not all storage risks.
• tfvars files can accidentally expose secrets if committed.
• Type constraints can reject values before provider calls happen.

Workspaces readiness

Terraform workspaces are often misunderstood. Be ready for practical questions about state context.

Workspace safety checks

Before planning or applying, ask:

• Which workspace am I in?
• Which backend is configured?
• Which variable values are being used?
• Which provider credentials are active?
• Which state will be modified?
• Am I using local execution or remote execution?

HCP Terraform and collaborative workflow checks

For the HashiCorp Certified: Terraform Associate (004), be ready to reason about why an organization would use a managed Terraform workflow such as HCP Terraform.

Local CLI vs remote run prompt

Can you explain what changes when a run is remote?

• The Terraform configuration still defines desired infrastructure.
• The execution environment changes.
• Provider credentials must be available remotely.
• Workspace variables may replace local .tfvars.
• State is usually managed remotely.
• Local files not committed or uploaded may be unavailable to the remote run.
• The plan/apply review process may be controlled by workspace settings.

Scenario and decision-point checks

Troubleshooting readiness

Artifact checklist

Security and sensitive-data checks

Security questions are often practical rather than theoretical. Focus on how Terraform handles credentials, state, and review.

You should be able to explain

• Provider credentials should not be hard-coded in .tf files.
• Environment variables, secure variable stores, and remote workspace variables are common credential patterns.
• Terraform state may contain sensitive values.
• sensitive = true reduces accidental display but does not remove the value from state.
• State access should be limited to people and systems that need it.
• Remote execution changes where credentials must be available.
• Module inputs can accidentally expose secrets if passed or output carelessly.
• Version constraints and dependency locks support supply-chain predictability.
• Review plans before applying, especially when destruction or replacement appears.

Security trap table

Refactoring, import, and drift checks

Be ready for conceptual scenarios where Terraform configuration changes but the desired real infrastructure should remain.

Example moved block pattern:

moved {
  from = example_resource.old_name
  to   = example_resource.new_name
}

Can you explain?

• Why this is different from deleting one block and creating another.
• How it helps Terraform understand address changes.
• Why you still need to review the plan.

Common weak areas and traps

Mini practice prompts

Use these prompts during final review. If you cannot answer quickly, revisit the related topic.

1. A teammate changed a resource name in Terraform code, and the plan now shows destroy/create. What Terraform concepts could prevent unnecessary replacement?
2. A plan succeeds locally but fails in HCP Terraform. What differences should you check?
3. A variable has a default, a .tfvars value, and an environment value. How would you investigate the value used in the plan?
4. A secret output is marked sensitive. Where might the secret still exist?
5. A module needs to expose a generated ID to the root module. What must be declared?
6. A resource exists in the cloud console but not in Terraform state. What are the options?
7. A team accidentally applied in the wrong workspace. What did the workspace control?
8. A provider upgrade changes the plan unexpectedly. Which files and settings should you inspect?
9. A plan shows -/+ replacement. What should you look for before approving?
10. A state lock is stuck. Why is force-unlocking risky?

Final-week checklist

Seven days out

• Rebuild your command map: fmt, init, validate, plan, apply, destroy, show, output, state, workspace.
• Review provider source, version constraint, and lock-file behavior.
• Practice reading small HCL snippets without running them.
• Review state concepts: binding, drift, locking, import, move, remove, backend.
• Review module inputs, outputs, source, versioning, and nested addresses.

Three to four days out

• Work through scenario questions about wrong workspace, wrong variables, provider errors, and unexpected replacement.
• Compare local and remote execution workflows.
• Review sensitive data handling and where secrets can appear.
• Practice identifying whether a problem is syntax, initialization, provider authentication, state, or remote API behavior.
• Revisit count vs for_each and implicit vs explicit dependencies.

Final day

• Do not cram provider-specific service details at the expense of Terraform fundamentals.
• Review the normal workflow from configuration change to state update.
• Review common command flags only where they change workflow meaning, such as saved plans.
• Review what Terraform does not do: it does not automatically secure state, infer business intent, or manage resources absent from state unless imported or declared.
• Practice explaining each major topic aloud in one or two sentences.

Readiness scorecard

Use this as a quick go/no-go review before more practice.

Practical next step

Pick one weak area from the scorecard and do a focused practice loop: read a small Terraform configuration, predict the plan behavior, identify the state impact, and explain which command you would run next. Then move into exam-style practice questions for the HashiCorp Certified: Terraform Associate (004) until your misses are concentrated in only one or two reviewable topics.