Terraform Associate 004 Chapter 2 Overview

Hi, in this mini series I’m adding an overview of the exam content for the terraform associate 004 exam found here: https://developer.hashicorp.com/terraform/tutorials/certification-004/associate-review-004. Hope this helps you on your quest to pass the exam 🙂 look for more sections (1-8) under Terraform in the navigation bar.

Section 2 — Terraform Fundamentals

2a & 2b — Providers: what they are and how to use them

A provider is a plugin that lets Terraform talk to a specific platform — AWS, Azure, GCP, Cloudflare, GitHub, whatever. Without a provider, Terraform can’t do anything. Think of it as the translator between your config and the actual API.

You declare a provider in your config like this:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-1"
}

Key things to know for the exam:

• Providers come from the Terraform Registry (registry.terraform.io)
• terraform init downloads and installs them
• You should always pin provider versions in production using ~> (allows patch updates but not major)
• The dependency lock file (.terraform.lock.hcl) records exactly which version was installed — commit this to Git so everyone on the team uses the same version

2c — Using multiple providers

You can use more than one provider in a single config. For example, deploying to AWS and managing your Cloudflare DNS in the same project. Each just gets its own provider block. Nothing complicated — just declare both.

2d — How Terraform manages state

This is one of the most important concepts in the whole exam — expect multiple questions on it.

Terraform keeps a state file (terraform.tfstate) that records what infrastructure currently exists. Every time you run terraform apply, Terraform compares your config to the state file to figure out what needs to change.

Key things to know:

• State is the source of truth for what Terraform thinks exists
• By default it’s stored locally as terraform.tfstate — fine for learning, bad for teams
• For teams you use remote state (stored in S3, GCS, or HCP Terraform) so everyone shares the same state
• State locking prevents two people running apply at the same time and corrupting state
• Never edit the state file manually
• terraform.tfstate can contain sensitive values — treat it like a secret