Terraform Associate (003)

The exam expects you to clearly explain why IaC matters and how Terraform fits into the IaC landscape. Understand that Terraform is declarative and cloud-agnostic — it can manage AWS, Azure, GCP, and hundreds of other providers with a single workflow. Be ready to contrast declarative vs imperative approaches and explain why idempotency is critical for reliable infrastructure automation.

For the exam, emphasize that Terraform’s key differentiators are its execution plan (preview before apply), resource graph (parallel resource creation based on dependency analysis), and provider model (cloud-agnostic). Understand that Terraform is not a configuration management tool like Ansible — Terraform provisions infrastructure, while Ansible configures software on that infrastructure. They are complementary, not competing.

The exam tests your understanding of how Terraform is installed and configured, not the specific installation steps for each OS. Know that terraform init must be run before any other command to download providers and initialize the backend. Understand the purpose of the terraform {} settings block and why credential management should use environment variables or provider-specific mechanisms rather than hardcoded values.

HCL syntax is fundamental to every exam question that includes code snippets. Practice reading HCL blocks and identifying the block type, labels, and arguments. Know the difference between = (argument assignment) and {} (nested block). Remember that Terraform processes all .tf files in a directory as a single configuration — the order of blocks across files does not matter because Terraform builds a dependency graph.

The core workflow (init, plan, apply) is tested heavily on the exam. Remember that terraform plan is read-only and safe to run at any time. Always review the plan output before applying. In production workflows, save the plan to a file and pass it to apply to ensure exactly what was reviewed gets executed. Understand that terraform destroy is a convenience command — the same result can be achieved by removing resources from the configuration and running apply.

The exam frequently tests provider versioning. Know the difference between >=, ~>, and = constraints. The pessimistic constraint operator ~> is the most commonly recommended: ~> 5.0 allows 5.0 through 5.x, while ~> 5.1.0 allows 5.1.0 through 5.1.x. Always commit the .terraform.lock.hcl file but never commit the .terraform directory. Understand that terraform init -upgrade updates providers within the allowed version constraints.

Provider aliases appear frequently on the exam in multi-region scenarios. Remember the syntax: define the alias in the provider block, then reference it in resources with the provider meta-argument. A common exam question pattern gives you two provider blocks for different regions and asks which resources will be created where. The key rule: resources without an explicit provider argument use the default (non-aliased) provider.

Resource blocks are the most fundamental building block of Terraform. For the exam, understand the difference between in-place updates and destroy/recreate (force replacement). Some attribute changes, like renaming an S3 bucket or changing an EC2 AMI, require destruction and recreation. Terraform shows this in the plan output with -/+. Know that resource addresses uniquely identify each resource in state and are essential for targeted operations.

Meta-arguments are heavily tested on the exam. The most common question pattern asks you to choose between count and for_each. Rule of thumb: if you have a list of identical things, count works; if each resource has a unique identity, use for_each. Understand that lifecycle { prevent_destroy = true } does not prevent terraform destroy from working on the whole configuration — it only prevents individual resource destruction during plan/apply. depends_on should be a last resort; prefer implicit dependencies through attribute references.

Data sources are a common exam topic. Remember that data sources are read-only and prefixed with data. in expressions. A frequent exam question involves terraform_remote_state for sharing outputs between configurations — know that it only exposes values declared as outputs in the source configuration. Understand that data sources are refreshed on every plan/apply, making them suitable for dynamic values like the latest AMI ID or current availability zones.

Variable precedence is a high-priority exam topic. Memorize the order: defaults are lowest, command-line -var flags are highest. A common trap: terraform.tfvars is auto-loaded, but a file named custom.tfvars is not — it must be passed with -var-file="custom.tfvars". Files matching *.auto.tfvars are automatically loaded. For sensitive variables, understand that sensitive = true only redacts CLI output; the state file still contains the plaintext value.

Outputs are the primary way to expose information from a Terraform configuration or module. For the exam, know that root module outputs are displayed after apply and stored in state, while child module outputs are used for cross-module data flow. A frequently tested pattern: one configuration exports a VPC ID via output, and another configuration reads it using terraform_remote_state. Understand that outputs are the only way to access a module’s data from the parent.

Locals, functions, and expressions are tested through code-reading questions. You will not need to memorize every function, but know the most common ones: join, split, lookup, merge, length, file, templatefile, cidrsubnet. Understand that locals are evaluated lazily and can reference variables, resources, and other locals. The terraform console command is invaluable for testing expressions interactively before putting them in configuration files.

State is one of the most important exam topics. Understand that state is not optional — it is required for Terraform to function. The exam tests whether you know that state files contain sensitive data (always protect them), that state locking prevents concurrent corruption, and that the default local state file (terraform.tfstate) is unsuitable for team use because it cannot be shared or locked. This is why remote backends exist.

Remote backends are heavily tested. Know that the S3 + DynamoDB combination provides both remote storage and locking for AWS environments. The exam may ask what happens when you change the backend configuration — you must run terraform init again, and Terraform offers to migrate the existing state. The cloud block (for Terraform Cloud) is the successor to the remote backend and is the recommended approach for teams using HashiCorp’s platform.

State manipulation commands are tested frequently. The key distinction: state mv renames or reorganizes resources within state without affecting infrastructure, state rm detaches a resource from Terraform management without destroying it, and import adopts existing infrastructure into Terraform. Remember that terraform import only updates state — you must still write the resource block manually. In Terraform 1.5+, the import block in configuration can generate the corresponding resource code with terraform plan -generate-config-out=generated.tf.

The exam tests your understanding of module sources and when to use each type. Know that terraform init downloads remote modules into the .terraform/modules directory. Local modules are not copied — they are read directly from the file path. Registry modules must include a version constraint; Git modules use ?ref= for pinning. The standard module structure (main.tf, variables.tf, outputs.tf, README.md) is a best practice, not a requirement.

Module inputs and outputs are a core exam topic. Think of modules like functions in programming: inputs are parameters, outputs are return values, and internal implementation is private. The exam may show a module block and ask what value a specific argument maps to or how to reference an output. Remember that module authors control what is exposed through outputs — not everything inside the module is available to the caller.

For the exam, understand that module versioning is critical for production stability. Never use unversioned registry modules in production — always pin with a version constraint. Know the benefits of modules: reusability (use the same VPC module for dev and prod), standardization (enforce naming conventions and tagging), and maintainability (update in one place). The exam may ask why you would use a module versus inline resources — the answer centers on reuse and encapsulation.

The exam specifically tests the difference between CLI workspaces and Terraform Cloud workspaces — they are not the same concept. CLI workspaces only separate state; Terraform Cloud workspaces separate state, variables, permissions, and more. A common exam trap: CLI workspaces are not recommended for managing different environments (dev/staging/prod) in production because they share the same variable values and backend credentials. Use separate directories or Terraform Cloud workspaces for true environment isolation.

Terraform Cloud features are tested at an awareness level. Know that Sentinel policies run between plan and apply and can enforce mandatory, soft-mandatory, or advisory rules. Understand the VCS-driven workflow: commit triggers plan, merge triggers apply. The exam may ask about the execution modes: remote (plan and apply run in TFC), local (plan and apply run on your machine, state in TFC), and agent (plan and apply run on a self-hosted agent for private network access). The free tier of Terraform Cloud supports up to 500 managed resources.

The exam asks specifically about when provisioners are appropriate. The official answer: provisioners are a last resort. Prefer cloud-native mechanisms like user data scripts (AWS), custom images built with Packer, or configuration management tools triggered separately. If you must use a provisioner, understand that failure marks the resource as tainted, meaning it will be destroyed and recreated on the next apply. The on_failure argument can be set to continue to ignore provisioner failures.

Dynamic blocks, fmt, and validate are common exam topics. Know that dynamic blocks generate nested blocks (not top-level resource blocks) and are the only way to make the number of nested blocks variable. For terraform fmt, remember it modifies files in-place by default; use -check for CI validation. terraform validate runs after init (it needs provider schemas) but does not access remote APIs. The -replace flag has superseded taint — know both but understand that -replace is the current recommended approach.