Home/ cloud-computing/ HashiCorp Certified: Terraform Associate/ Cheat Sheet
HashiCorp Certified: Terraform Associate· Exam reference card · 2026 · Edureify AI
HashiCorp Certified: Terraform Associate

HashiCorp Certified: Terraform Associate Cheat Sheet

Terraform Associate Tests IaC Workflow Judgment — Not Terraform Syntax Memorization

The exam tests whether you understand Terraform's core workflow, state management, and module architecture — not whether you've memorized HCL syntax perfectly.

Check Your Readiness →
Among the harder certs
Avg: Approximately 65–70%
Pass: 750 / 1000
Most candidates understand HashiCorp Certified: Terraform Associate concepts — and still fail. This exam tests how you apply knowledge under pressure.
Core Framework

Terraform Core Workflow

Terraform Associate tests understanding of IaC concepts, Terraform's core workflow, state management, modules, providers, and Terraform Cloud. The exam is conceptual and applied — know why each command exists, not just what it does.

  1. 01
    Write — Define infrastructure as HCL code
  2. 02
    Init — Initialize providers and download modules (terraform init)
  3. 03
    Plan — Preview changes without applying (terraform plan)
  4. 04
    Apply — Execute the planned changes (terraform apply)
  5. 05
    Destroy — Remove managed infrastructure (terraform destroy)
  6. 06
    State — Terraform tracks real infrastructure in the state file
Scenario Traps

Wrong instinct vs correct approach

A team member has manually changed infrastructure that Terraform manages
✕ Wrong instinct

Manually update the Terraform code to match the manual change

✓ Correct approach

Run terraform plan to detect drift — Terraform will show the difference between state and actual infrastructure; decide whether to reconcile by importing or by reverting the manual change through Terraform

Multiple team members need to run Terraform against the same environment simultaneously
✕ Wrong instinct

Share a single local state file via source control

✓ Correct approach

Use remote state with state locking (Terraform Cloud, S3 + DynamoDB) — local state doesn't support concurrent access and leads to state corruption and infrastructure conflicts

A Terraform module needs to be reused across development, staging, and production
✕ Wrong instinct

Create separate copies of the module for each environment

✓ Correct approach

Use a single module with input variables to parameterize environment-specific values; call the same module from different root configurations with different variable values — duplication defeats the purpose of modules

Quick Rules

Know these cold

  • ▸ Always run terraform plan before terraform apply — preview before changing
  • ▸ Remote state + state locking is mandatory for team Terraform usage
  • ▸ Modules enable reuse — parameterize with variables, don't duplicate code
  • ▸ State file contains sensitive data — encrypt it and restrict access
  • ▸ terraform import brings existing resources under Terraform management
  • ▸ Provider versions should be pinned to prevent unexpected breaking changes
  • ▸ terraform fmt for formatting; terraform validate for syntax; terraform plan for logic review
Self Check

Can you answer these without checking your notes?

In this scenario: "A team member has manually changed infrastructure that Terraform manages" — what should you do first?
Run terraform plan to detect drift — Terraform will show the difference between state and actual infrastructure; decide whether to reconcile by importing or by reverting the manual change through Terraform
In this scenario: "Multiple team members need to run Terraform against the same environment simultaneously" — what should you do first?
Use remote state with state locking (Terraform Cloud, S3 + DynamoDB) — local state doesn't support concurrent access and leads to state corruption and infrastructure conflicts
In this scenario: "A Terraform module needs to be reused across development, staging, and production" — what should you do first?
Use a single module with input variables to parameterize environment-specific values; call the same module from different root configurations with different variable values — duplication defeats the purpose of modules
Failure Patterns

Common Exam Mistakes — What candidates get wrong

Confusing terraform plan with terraform apply

terraform plan shows what changes will be made without making them — it's a preview and safety check. terraform apply executes those changes. Candidates who skip plan in scenarios where validation is required make unsafe infrastructure changes.

Misunderstanding Terraform state purpose and risks

Terraform state is the source of truth about managed infrastructure. It must be stored remotely (S3, Terraform Cloud) for team use — local state causes conflicts. Direct state manipulation should be a last resort, not standard practice.

Treating modules as optional rather than essential for maintainability

Modules enable code reuse, encapsulation, and standardization. Candidates who write all Terraform in a single file without modules produce unmaintainable configurations at scale.

Confusing terraform.tfvars with variables.tf

variables.tf declares variable definitions (name, type, description, default). terraform.tfvars provides variable values. These are distinct files with distinct purposes — mixing them up in code organization questions is a common error.

Ignoring the implications of state file containing sensitive data

Terraform state files often contain secrets and sensitive resource attributes in plaintext. Using remote state with encryption and access controls is a security requirement — storing state locally or without encryption is a security risk.

Terraform Associate tests IaC production judgment. Test whether your Terraform practices are team-ready.

Start Diagnostic Test → View all exams