Your complete guide to earning the HashiCorp Certified: Terraform Associate (003) β the leading Infrastructure as Code credential, covering IaC concepts, HCL configuration, state management, modules, and Terraform Cloud for teams.
The HashiCorp Certified: Terraform Associate (003) is the leading Infrastructure as Code (IaC) certification for cloud engineers and DevOps practitioners. It validates your ability to use Terraform for provisioning, managing, and automating cloud infrastructure across AWS, Azure, GCP, and hundreds of other providers. The exam covers the full Terraform workflow β from HCL configuration authoring and state management to modules, workspaces, and collaboration through Terraform Cloud. The 003 update (from 002) emphasizes Terraform Cloud features, the cloud block, moved block, check blocks, precondition/postcondition lifecycle, and the terraform test framework introduced in Terraform 1.6+.
Install Terraform, configure the AWS/Azure provider, write your first resource block (S3 bucket or storage account), run the full init β plan β apply β destroy cycle. Observe what the .terraform/ directory contains after init.
Experiment with version constraint operators: ~> (pessimistic), >=, =, != for both required_version and required_providers. Practice what happens when you specify incompatible constraints. Examine .terraform.lock.hcl before and after terraform init -upgrade.
Create a configuration with all variable types (string, number, bool, list, map, object). Test all 5 precedence levels by providing values via -var flag, .tfvars file, environment variables (TF_VAR_), and defaults. Implement validation blocks with can() and contains().
Open terraform console and practice: cidrsubnet for VPC subnetting, flatten/merge/toset for collection manipulation, jsonencode for AWS policies, templatefile for user-data scripts, try() and can() for error handling. Build all the subnet CIDRs for a 3-AZ VPC using only cidrsubnet.
Create 3 S3 buckets with count, then migrate to for_each. Observe how removing one item causes different behavior: count causes replacement of subsequent resources, for_each only affects the removed key. This is a critical exam concept.
Build an AWS security group where ingress rules are driven by a variable list of objects. Add/remove rules by editing the variable β no changes to resource block needed. Practice with nested dynamic blocks.
Create an S3 bucket and DynamoDB table (LockID hash key) manually or via separate Terraform config. Configure your main workspace to use S3 backend with DynamoDB locking. Migrate existing local state to S3 via terraform init (it offers to copy state). Verify locking: open two terminals, run terraform plan simultaneously and observe one being blocked.
Create a resource manually in AWS console (e.g., security group). Write a resource block in Terraform, run terraform import, then run terraform plan until there's no diff. Practice generating config with -generate-config-out (TF 1.5+).
Rename a resource in your config (e.g., aws_instance.app to aws_instance.web), add a moved block, and verify that terraform plan shows no resource replacement β only a state rename. Then migrate a count-based resource to for_each using moved blocks for each element.
Create a terraform-aws-webserver module (or Azure equivalent) with proper structure: main.tf, variables.tf, outputs.tf, versions.tf, README.md. Call it from a root configuration using local source path, then push to GitHub and reference it via Git URL with version pinning.
Create a free Terraform Cloud account, connect it to a GitHub repo, create a workspace in VCS-driven mode. Create a PR β observe TFC posting a speculative plan. Merge the PR β observe TFC queueing a run. Approve and apply the run in TFC UI.
Create a variable set with cloud credentials (AWS or Azure environment variables, marked sensitive). Apply to your TFC workspace. Verify the workspace can authenticate to cloud without workspace-specific credentials. Create a second workspace and apply the same variable set β observe how a single set serves multiple workspaces.
Write a Sentinel policy that prevents EC2 instance types larger than t3.medium. Apply it as a policy set in TFC. Test with a plan that uses t3.large β verify the policy blocks or warns. Change enforcement level from soft-mandatory to advisory and observe different behavior.
count vs for_each: Index corruption on count list removal, stable keys with for_each. Variable precedence: -var > auto.tfvars > TF_VAR_ > default. State locking: DynamoDB LockID key, force-unlock caution. Lifecycle: create_before_destroy, prevent_destroy, ignore_changes. Sentinel: Three enforcement levels and their behaviors. Modules: path.module for portable file references. TFC: VCS speculative plans on PRs, cloud block syntax, variable sets vs workspace vars.
Practice with 150 exam-quality questions, master core concepts with flashcards, and build real skills with hands-on projects.