HashiCorp Certified Terraform Associate 004 Exam Prep Course

Click on PRACTICE to get access to a free, dynamic AWS account to use for Terraform labs.

Click on PRACTICE to get access to a free, dynamic Azure account to use for Terraform labs.

In this lab, you'll set up your first Terraform project structure and configure the AWS provider, then run the core fmt, validate, and init workflow. You'll also experiment with version constraints by forcing a deliberate error, learning how required_version controls which Terraform versions can run your configuration.

In this lab, you'll create your first AWS resource with Terraform by defining a VPC and running the full init, plan, apply workflow. You'll use terraform fmt to clean up non-canonical HCL, then make changes to the CIDR block and tags to see the difference between a resource replacement and an in-place update.

In this lab, you'll enhance a VPC configuration with variables and outputs, learning how variable precedence works across defaults, terraform.tfvars, and the -var-file flag. You'll also apply provider-level default tags and use outputs to display resource details like the VPC ID, ARN, and CIDR block.

In this lab, you'll add subnets, a route table, associations, and a security group to a VPC, learning how Terraform uses resource references to manage dependencies and creation order. A deliberate quoting error also shows why terraform validate doesn't catch every problem, since some only surface at plan time.

In this lab, you'll work with Terraform state, query live AWS information through data sources, and explore additional CLI commands. You'll build a separate development environment that pulls account, region, and availability zone details to populate resource tags dynamically, then use state commands like list, show, and output to inspect what Terraform is tracking. You'll also see how the sensitive flag masks output values in the terminal while still exposing them through the -json flag. Finally, you'll tear down both the development and main environments to confirm a clean state.

In this lab, you will migrate Terraform state from the default local backend to a remote S3 backend with native state locking enabled. You will inspect the local state file, provision a state bucket, and move your state with terraform init -migrate-state. You will then strand a stale state lock on purpose, repair it with terraform force-unlock, view state file versions in S3, and migrate state back to the local backend before cleaning up.

In this lab, you'll take a Terraform configuration full of hardcoded values and refactor it to be dynamic and reusable using variables, data sources, and string interpolation. You'll define variables for CIDR blocks and naming, then pull live account, region, and availability zone data from AWS to build resource names and tags automatically. After deploying a VPC, subnet, and route table, you'll change a single variable in terraform.tfvars and reapply to watch the naming and tags update across every resource.

In this lab, you'll refactor a configuration by moving common values into a locals block, then use them to standardize naming and tagging across a VPC, subnets, and a security group deployed to AWS. You'll also compute values dynamically by pulling the current region from a data source and building a name prefix through interpolation. Finally, you'll change a few locals and reapply to watch every dependent resource update from a single edit.

In this lab, you'll refactor individually defined subnets and security groups using count, then again using for_each, deploying each to AWS to see how they're tracked in state. The key difference shows up when you remove a subnet from the middle: count shifts every index after it and forces unwanted destruction and recreation, while for_each touches only the resource you removed. By the end, you'll know which meta-argument to reach for in production and why.