HashiCorp Terraform Associate 003: The Certification That Proves You Can Build, Version, and Manage Infrastructure as Code

Objective 1 — Understand Infrastructure as Code (IaC) Concepts

Declarative vs imperative: Terraform is declarative — you describe the desired end state and Terraform determines how to reach it. Tools like Bash scripts are imperative — you describe the steps. Declarative tools enable idempotency: applying the same configuration multiple times produces the same result without accumulating side effects.

Mutable vs immutable infrastructure: Mutable infrastructure is patched in place (traditional operations). Immutable infrastructure is replaced rather than patched — deploy a new AMI or container image and terminate the old instance. Terraform enables the immutable model: most resource attribute changes trigger a destroy-and-recreate cycle. The lifecycle { create_before_destroy = true } meta-argument controls the replacement order to prevent downtime.

Terraform vs alternatives:

• AWS CloudFormation: AWS-only, JSON/YAML, AWS-managed state via stacks, no explicit state file, tightly AWS-integrated but no multi-cloud
• Azure Bicep/ARM: Azure-only, first-party Microsoft tooling
• Pulumi: multi-cloud like Terraform, uses general-purpose languages (TypeScript, Python, Go) instead of HCL
• Ansible: primarily configuration management and Day 2 operations — procedural, agentless; not designed for resource lifecycle management (no drift detection, no destroy planning)
• Terraform: multi-cloud, HCL declarative DSL, 3,000+ provider ecosystem, explicit state file with drift detection via terraform plan

Objectives 2–3 — Terraform Purpose, Basics, and HCL Syntax

Block types: resource (managed infrastructure object), data (read existing infrastructure without managing it), variable (input variable — attributes: type, default, description, sensitive, validation), output (expose values — attributes: value, description, sensitive), locals (named expressions for reuse within the module), module (calls a child module), terraform (configures Terraform itself — required_version, required_providers, backend), provider (configures a specific provider).

Types: primitive — string, number, bool; collection — list(string), set(string), map(string); structural — object({name = string}), tuple([string, number]). The any type disables type checking.

Meta-arguments (available on resource and module blocks):

• depends_on: explicit dependency declaration when implicit reference-based dependencies are insufficient
• count: creates N copies of a resource; differentiated via count.index
• for_each: creates one resource per map key or set element (each.key, each.value) — preferred over count for named resources: insertions don’t re-index existing resources
• lifecycle: create_before_destroy, prevent_destroy, ignore_changes, replace_triggered_by

Key functions: length(), element(), contains(), merge(), flatten(), toset(), lookup(map, key, default), format(), join(), cidrsubnet(), jsonencode(), base64encode(). Also know string templates ("${var.region}-subnet"), heredoc syntax, and the ternary operator (condition ? true_val : false_val).

Version constraints: ~> 4.0 (pessimistic — allows 4.x, not 5.0), >= 3.5, < 5.0, = 3.5.1 (exact pin). The .terraform.lock.hcl file records exact provider versions and hashes selected by terraform init — commit this file to source control for consistent provider versions across team members and CI.

Objective 4 — Core Terraform Workflow and CLI

The standard workflow: Write → Init → Validate → Plan → Apply.

• terraform init: downloads provider plugins into .terraform/providers/, downloads module sources, configures the backend. Run after any change to required_providers, module source, or backend. The -upgrade flag updates provider versions within defined constraints.
• terraform validate: checks configuration syntax and semantic consistency. Does not access provider APIs or the state file. Catches type mismatches, missing required arguments, and undefined references.
• terraform plan: reads state, calls provider APIs to determine real resource state, and computes the diff. Output prefixes: + (create), ~ (update in-place), -/+ (destroy-and-recreate), - (destroy). Use -out=plan.tfplan to save a plan for deterministic apply — the saved plan applies exactly as shown even if configuration changes between plan and apply.
• terraform apply: provisions resources, updates terraform.tfstate. With a saved plan: terraform apply plan.tfplan. Without: generates a new plan and prompts for confirmation (or -auto-approve for automation).
• terraform destroy: equivalent to terraform apply -destroy. Creates a destroy plan and applies it.

Additional CLI: terraform fmt (auto-formats .tf files to canonical style), terraform show (human-readable state or plan), terraform output (read output values; -json for scripting), terraform console (interactive HCL expression evaluator), terraform graph (DOT-format dependency graph), terraform apply -replace=resource.type.name (forces replacement of a specific resource — replaces the deprecated terraform taint command). The -target flag scopes plan or apply to specific resources — use sparingly; HashiCorp discourages routine use because it can leave state inconsistent.

Objective 7 — Implement and Maintain State

terraform.tfstate is a JSON file recording the mapping between Terraform configuration and real-world resources. It contains resource IDs, attribute values (including sensitive ones like passwords and private keys), and dependency information. Never commit an unencrypted local state file to source control.

Remote backends solve the collaboration and durability problems of local state:

• S3 + DynamoDB: S3 stores the state file (enable SSE and versioning); a DynamoDB table with a LockID string attribute provides state locking. Specified in the backend "s3" { ... } block.
• Azure Blob Storage: built-in lease mechanism provides locking; configured via backend "azurerm" { ... }
• GCS: native object lock provides locking; configured via backend "gcs" { ... }
• Terraform Cloud: natively integrated — state is encrypted at rest, versioned, and locked automatically per run via the cloud { ... } block

State manipulation commands (use with caution):

• terraform state list: lists all resources tracked in state
• terraform state show resource.type.name: prints all attributes of a tracked resource
• terraform state mv source destination: renames a resource in state without reprovisioning — use when refactoring (e.g., moving a resource into a module)
• terraform state rm resource.type.name: removes from state without destroying — use to stop managing an existing resource (the real resource continues to exist)
• terraform import resource.type.name real-id: imports an existing real resource into Terraform state; requires an empty resource block already present in configuration

CLI workspaces (terraform workspace new staging) allow multiple state files within the same backend configuration. terraform.workspace is interpolatable in HCL. Useful for dev/staging/prod isolation with a single configuration, but prefer separate backend configurations for strict production environment isolation.

Objective 5 — Interact with Terraform Modules

A module is any directory containing .tf files. The working directory is the root module. Child modules are called via module blocks and are the primary code-reuse mechanism in Terraform — they encapsulate a logical group of resources behind a defined interface of input variables and output values.

Module source types:

• Local path: source = "./modules/vpc" — relative path; no versioning, changes immediately reflected
• Terraform Registry: source = "hashicorp/consul/aws" — format is <NAMESPACE>/<MODULE>/<PROVIDER>; pin with version = "~> 0.0.5"
• Private Registry: Terraform Cloud/Enterprise hosts private modules; same source format with the private hostname
• GitHub/Git: source = "github.com/hashicorp/example"; pin to a tag with ?ref=v1.2.0

Module inputs are declared with variable blocks inside the module and passed as arguments in the module block. Module outputs are declared with output blocks and referenced as module.<name>.<output_name>. Providers can be passed explicitly via the providers meta-argument for multi-account or multi-region patterns. Published modules on the public Terraform Registry must follow the terraform-<PROVIDER>-<NAME> naming convention and use semantic versioning tags.

Objective 9 — Understand Terraform Cloud Capabilities

Terraform Cloud provides: remote state (encrypted at rest, versioned, locked per run), remote runs (plan and apply on TFC-managed agents — no local credentials needed), VCS integration (plans triggered automatically on pull requests), team RBAC (viewer/planner/operator roles per workspace), variable sets (reusable variable collections shared across workspaces), audit logging, and Sentinel policy-as-code (paid tiers — block or warn on non-compliant plans).

The most commonly tested Terraform Cloud concept: CLI workspaces vs Terraform Cloud workspaces are fundamentally different objects. CLI workspaces (terraform workspace new) use different state files within the same backend configuration directory — they’re a lightweight isolation mechanism sharing the same provider configuration. Terraform Cloud workspaces are full environment representations — each has its own VCS connection, variable set, state, team access rules, and run history. An organisation in Terraform Cloud contains many workspaces; each workspace manages one environment (or one component at larger scale).