HC-003

Terraform Associate (003) Exam Details

Exam Objective Domains

What Is Infrastructure as Code (IaC)?

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure through machine-readable configuration files rather than manual processes or interactive tools. IaC enables version control, peer review, automated testing, and repeatable deployments. Terraform is a declarative IaC tool, meaning you describe the desired end state and Terraform determines the steps to reach it.

Exam Tip: Understand the difference between declarative (Terraform, CloudFormation) and procedural/imperative (Ansible, scripts) approaches. Terraform is declarative -- you define what you want, not how to get there.

Terraform vs Other IaC Tools

HCL Block Types

HashiCorp Configuration Language (HCL) is Terraform's primary configuration language. Configuration files use the .tf extension. JSON-based alternatives use .tf.json.

Variable Definition & Precedence

Variables can be set from multiple sources. Terraform evaluates them in the following order of precedence (highest to lowest):

1. -var and -var-file flags on the command line
2. *.auto.tfvars or *.auto.tfvars.json files (alphabetical order)
3. terraform.tfvars.json file
4. terraform.tfvars file
5. Environment variables (TF_VAR_name)
6. Default value in the variable block
7. Interactive prompt (if no default and not set)

Exam Tip: The -var flag has the HIGHEST precedence and will always override any other value. Environment variables (TF_VAR_) have LOWER precedence than tfvars files.

Variable Types

Sensitive Variables & Outputs

Mark variables as sensitive = true to prevent their values from appearing in CLI output and logs. Similarly, outputs can be marked sensitive. Sensitive values are still stored in state in plain text -- always encrypt your state file.

Common Built-in Functions

Exam Tip: Terraform does NOT support user-defined functions. You can only use built-in functions. Use terraform console to test functions interactively.

Provider Configuration

Providers are plugins that interact with APIs of cloud platforms and services. Each provider adds a set of resource types and data sources. Providers must be declared in the required_providers block and configured in a provider block.

Version Constraints

Exam Tip: The ~> operator is heavily tested. ~> 5.0 means >= 5.0 and < 6.0. ~> 5.0.0 means >= 5.0.0 and < 5.1.0.

Provider Aliases (Multiple Configurations)

Use aliases to configure the same provider with different settings (e.g., deploying to multiple AWS regions):

Resource Meta-Arguments

Exam Tip: count and for_each CANNOT be used together on the same resource. for_each requires a set or map -- use toset() to convert a list. count uses numeric index which can cause issues when removing items from the middle.

Data Sources

Data sources allow Terraform to read information from existing infrastructure that is not managed by the current configuration. They are defined with a data block and are read-only -- they never create, update, or delete infrastructure.

Provisioners (Use as Last Resort)

Provisioners run only at creation time by default. Set when = destroy to run during destruction. If a provisioner fails, the resource is marked tainted (replaced on next apply). Use on_failure = continue to ignore errors.

Exam Tip: HashiCorp considers provisioners a LAST RESORT. Prefer cloud-init, user_data, or configuration management tools. Provisioners can break idempotency.

Understanding Terraform State

Terraform state is a JSON file (terraform.tfstate) that maps real-world resources to your configuration. It tracks metadata, resource dependencies, and attribute values. State is the source of truth for Terraform to know what exists and what needs to change.

• State maps configuration resources to real-world objects via unique resource IDs
• State tracks dependencies between resources for correct ordering
• State improves performance by caching attribute values (avoids querying APIs for every plan)
• State contains sensitive data in plain text -- always secure it
• Default local state file: terraform.tfstate with backup in terraform.tfstate.backup

Remote State Backends

Remote backends store state outside of the local filesystem, enabling team collaboration and state locking.

Exam Tip: State locking prevents concurrent operations that could corrupt state. S3 alone does NOT provide locking -- you need DynamoDB for that. terraform force-unlock LOCK_ID manually releases a stuck lock.

State Commands

State Locking & Drift Detection

State Locking: Prevents simultaneous writes to state. If Terraform detects the state is locked, it will retry for a configurable period. Use -lock=false to disable (not recommended). Force unlock with terraform force-unlock LOCK_ID.

Drift Detection: Running terraform plan or terraform apply compares the actual state of resources against the configuration. If someone changed a resource outside Terraform (manual change), the plan will show the difference and propose correcting it. Use terraform refresh (or terraform apply -refresh-only) to update state without making changes.

Exam Tip: terraform refresh is deprecated as a standalone command. Use terraform apply -refresh-only instead for safer drift reconciliation.

Terraform Import & State Migration

Import: Brings existing infrastructure under Terraform management. You must write the resource configuration manually first, then run terraform import <resource_address> <resource_id>. Terraform 1.5+ also supports import blocks in configuration for declarative imports.

Backend Migration: When changing backends (e.g., local to S3), run terraform init -migrate-state to copy state to the new backend. Use terraform init -reconfigure to reinitialize without migrating state.

Workspaces

Workspaces allow you to maintain multiple state files for the same configuration, enabling separation of environments (e.g., dev, staging, prod) without duplicating code.

The current workspace is available via terraform.workspace in configuration. The default workspace is named default and cannot be deleted. Local state for non-default workspaces is stored in terraform.tfstate.d/.

Exam Tip: CLI workspaces are NOT the same as HCP Terraform (Terraform Cloud) workspaces. CLI workspaces are just separate state files. HCP Terraform workspaces include variables, run history, and access controls.

Terraform Core Workflow

The fundamental Terraform workflow consists of three stages:

Essential Terraform Commands

Plan Symbols & Saved Plans

Save a plan: terraform plan -out=tfplan. Apply it: terraform apply tfplan. Saved plans skip the confirmation prompt because they are pre-approved.

Exam Tip: terraform apply runs a plan first automatically. Using -auto-approve skips the interactive confirmation. terraform plan -destroy previews what terraform destroy would do.

terraform init Deep Dive

terraform init is the first command you run. It is safe to run multiple times (idempotent).

• Downloads and installs providers into .terraform/providers/
• Downloads modules into .terraform/modules/
• Initializes the backend (local or remote)
• Creates .terraform.lock.hcl -- the dependency lock file (should be committed to VCS)
• -upgrade flag updates providers/modules to latest allowed versions
• -migrate-state moves state between backends
• -reconfigure reinitializes without migrating existing state

Debugging & Logging

Set the TF_LOG environment variable to enable detailed logging:

Use TF_LOG_PATH to write logs to a file. Separate provider vs core logs with TF_LOG_CORE and TF_LOG_PROVIDER.

Terraform Modules

A module is a container for multiple resources that are used together. Every Terraform configuration has at least one module (the root module) -- the .tf files in your working directory. Child modules are called from the root module using module blocks.

Module Sources

Exam Tip: The version argument only works with registry modules, NOT with local path or Git sources. After adding or changing a module source, you must run terraform init again.

Module Best Practices

• Modules should have a clear single purpose
• Use variables.tf, outputs.tf, and main.tf as standard file names
• Expose outputs so the calling module can reference child module resources
• Access child module outputs via module.<name>.<output>
• Pin module versions in production to prevent unexpected changes
• Use the description argument on variables and outputs for documentation

HCP Terraform (Terraform Cloud) Overview

HCP Terraform is HashiCorp's managed service for Terraform. It provides remote state management, remote execution, a private registry, and team collaboration features.

HCP Terraform Execution Modes

Sentinel policies run between plan and apply in HCP Terraform. They can enforce rules like "all EC2 instances must have tags" or "no resources in unapproved regions." Policies use hard-mandatory, soft-mandatory, or advisory enforcement levels.

Exam Tip: The free tier of HCP Terraform supports up to 500 managed resources. Sentinel and team management require paid tiers. The cloud block in terraform settings replaces the older remote backend for HCP Terraform integration.