This domain tests conceptual understanding rather than hands-on syntax, so expect definition-based and scenario-comparison questions. Focus on articulating IaC benefits like idempotency, version control, and repeatability versus manual provisioning. Terraform's provider-agnostic model and its position in the multi-cloud landscape are frequent question anchors.

💡 Easiest domain conceptually, but candidates lose points by confusing declarative with imperative models or underselling specific IaC benefits like self-documentation and peer review via version control.

This domain bridges concepts and mechanics — expect questions on how providers are sourced, versioned, and initialized, as well as how state is created and used. Pay close attention to the provider version constraint syntax (e.g., ~>, >=) and the difference between required_providers and provider blocks. Understanding that state is the source of truth mapping real infrastructure to configuration is critical.

💡 Version constraint syntax is a frequent trap — candidates confuse ~> (pessimistic constraint) with >= (minimum version). Also, know that providers are downloaded into .terraform/ during init, not apply.

This is the most procedural domain — questions map directly to CLI commands and their outputs. You must know the exact sequence (init → validate → plan → apply → destroy) and what each command does and does not do. Pay special attention to what terraform plan -out does, what terraform fmt -recursive covers, and the difference between terraform validate and a plan-time check.

💡 Candidates often confuse terraform validate with terraform plan — validate does NOT contact provider APIs. Also, terraform destroy is equivalent to terraform apply -destroy, which may appear as a trick option.

As the highest-weighted domain at 25%, this is where the exam is won or lost — expect the largest number of questions covering HCL syntax, variable types, expressions, and dependency management. Know the difference between resource and data blocks at a syntactic and behavioral level, and be proficient with built-in functions like length(), toset(), lookup(), and merge(). Sensitive variable handling and lifecycle meta-arguments (create_before_destroy, prevent_destroy) are high-value topics.

💡 The most common pitfall is confusing count.index with for_each keys — with for_each, use each.key and each.value. Also, sensitive = true on a variable does not encrypt state; it only suppresses CLI output.

Module questions focus on sourcing (registry, local path, Git, S3), variable scoping rules, and version pinning. Understand that child modules cannot access parent module variables unless explicitly passed, and that outputs from child modules must be explicitly declared to be accessible. The Terraform Registry module source format (namespace/module/provider) and version argument behavior are frequently tested.

💡 Candidates often forget that local path modules (source = './modules/vpc') do not support the version argument — version pinning only works with registry and some remote sources. Also, module outputs must be explicitly exposed via output blocks inside the module.

State management questions test both conceptual knowledge (why state exists, what drift is) and practical backend configuration. Know the backend block syntax for common remote backends (S3, Azure Blob, HCP Terraform), understand that state locking prevents concurrent runs, and know the difference between terraform refresh (deprecated standalone command) and the -refresh-only plan mode. Resource drift — when real infrastructure diverges from state — and its resolution is a key scenario topic.

💡 A critical pitfall: the backend block cannot reference variables or locals — it must use hardcoded values or be configured via partial configuration with -backend-config. Also, terraform state rm removes a resource from state but does NOT destroy the real resource.

Despite its low weight (6.25%), this domain covers operationally important topics including terraform import, state inspection, and debug logging. Know that terraform import requires you to write the resource block manually before importing, and that TF_LOG accepts levels TRACE, DEBUG, INFO, WARN, ERROR with TRACE being the most verbose. The terraform state show and terraform state list commands are commonly tested in 'how do you inspect' scenarios.

💡 Candidates frequently miss that terraform import does not generate configuration — you must write the resource block first, then import. Also, after import, running terraform plan may still show changes if the configuration does not perfectly match the imported resource's actual attributes.

This domain covers HashiCorp Cloud Platform (HCP) Terraform features including remote runs, workspace organization, and governance via Sentinel policies and role-based access control. Know the difference between HCP Terraform workspaces (isolated environments with their own state and variables) and local Terraform workspaces (terraform workspace command). Understand the cloud block as the modern replacement for the remote backend block and how CLI-driven vs. VCS-driven workflows differ.

💡 Candidates confuse HCP Terraform workspaces with CLI workspaces (terraform workspace new/select) — they are fundamentally different concepts. HCP Terraform workspaces are full isolated environments; CLI workspaces are state-level multiplexing within a single configuration directory.