You Can Pass This Exam For Free
Choose Your Study Path
Limited or no experience with Terraform or IaC tools. You need to build foundational knowledge of cloud infrastructure and Terraform from scratch.
Week 1Learn IaC fundamentals: why IaC matters, declarative vs imperative approaches, idempotency, and how Terraform fits into the IaC landscape compared to tools like CloudFormation and Pulumi
Week 2Install Terraform CLI, set up a free cloud provider account (AWS Free Tier or similar). Write your first configuration: provider block, resource block, terraform init, plan, apply, destroy
Week 3Deep dive into Terraform configuration: variables (input, local, environment), outputs, data sources, resource references, expressions, and built-in functions
Week 4Study resource lifecycle management: depends_on, lifecycle blocks (create_before_destroy, prevent_destroy, ignore_changes), custom conditions (precondition, postcondition, check blocks)
Week 5Learn modules: using registry modules, creating local modules, module inputs/outputs, standard module structure. Practice writing and calling a reusable module
Week 6Study state management: local vs remote backends, state locking, terraform state commands (list, show, mv, rm, pull, push), resource drift detection, and terraform import
Week 7Learn HCP Terraform: workspaces vs CLI workspaces, VCS-driven workflows, remote operations, teams and permissions, Sentinel policies, cost estimation, and projects
Week 8Take practice exams, review explanations carefully. Focus on areas where you score below 70%. Re-study weak domains and schedule your exam
Exam Overview
Format
57 questions, 60 minutes. Multiple choice, multiple answer, and true/false questions. Online proctored.
Scoring
Passing score: 70 out of 100. No penalty for wrong answers — always answer every question.
Domains & Weights
- Infrastructure as Code (IaC) with Terraform8%
- Terraform Fundamentals13%
- Core Terraform Workflow15%
- Terraform Configuration22%
- Terraform Modules12%
- Terraform State Management12%
- Maintain Infrastructure with Terraform8%
- HCP Terraform10%
Registration
$70.5 USD. Online proctored via Certiverse. Available in English only. Exam fee is $70.50 USD plus local taxes. Credential valid for 2 years.
Topic Priority Table
Not all topics are tested equally. Focus your study time on Tier 1 first, then Tier 2. Tier 3 topics rarely appear — just recognize what they do.
Domain 18% of exam
Infrastructure as Code (IaC) with Terraform
This domain covers foundational IaC concepts: why managing infrastructure through code is better than manual processes, declarative vs imperative approaches, idempotency, and how Terraform fits into the IaC ecosystem. While the smallest domain, it establishes the conceptual foundation for everything else.
Key Topics
Terraform CLIHCLDeclarative ConfigurationIdempotencyMulti-Cloud Support
Must-Know Concepts
- IaC advantages: version control, automation, consistency, repeatability, documentation, collaboration, and disaster recovery
- Declarative vs imperative: Terraform is declarative (you describe desired state, Terraform figures out how to get there). Tools like Ansible scripts are often imperative (step-by-step instructions)
- Idempotency: applying the same configuration multiple times produces the same result. Terraform only makes changes when the desired state differs from the actual state
- Multi-cloud support: Terraform can manage resources across AWS, Azure, GCP, and hundreds of other providers in a single configuration
- Terraform is cloud-agnostic and uses a plugin-based architecture with providers for each platform
Common Exam Traps
Terraform is DECLARATIVE, not imperative. You describe what you want, not the steps to create it
IaC does not eliminate the need for understanding cloud services — you still need to know what resources to create and how they connect
Terraform is not a configuration management tool like Ansible or Chef. It provisions infrastructure; config management configures software on existing servers
Domain 213% of exam
Terraform Fundamentals
Covers how Terraform works under the hood: provider architecture, plugin system, state tracking, version constraints, and the dependency lock file. You need to understand how Terraform discovers, downloads, and manages providers, and how it tracks infrastructure through state.
Key Topics
ProvidersProvider RegistryVersion ConstraintsDependency Lock FileState FilePlugin Architecture
Must-Know Concepts
- Providers are plugins that let Terraform interact with APIs. They are downloaded during terraform init from the Terraform Registry
- The required_providers block in the terraform block specifies which providers are needed, their source, and version constraints
- Version constraint syntax: = (exact), >= (minimum), ~> (pessimistic constraint — allows only rightmost version component to increment), != (exclude)
- The dependency lock file (.terraform.lock.hcl) records exact provider versions and checksums. It SHOULD be committed to version control for reproducible builds
- terraform init -upgrade updates providers to the latest version matching constraints and updates the lock file
- State is how Terraform maps configuration to real-world resources. Without state, Terraform cannot know what it manages
- Terraform uses a plugin-based architecture where the core binary handles workflow and the provider plugins handle API calls
Common Exam Traps
The pessimistic constraint ~> 1.2 allows 1.2 through 1.x (any minor version). ~> 1.2.3 allows 1.2.3 through 1.2.x (only patch versions). The behavior changes based on how many version segments you specify
The dependency lock file (.terraform.lock.hcl) is NOT the state file. The lock file tracks provider versions; the state file tracks infrastructure resources
terraform init is the ONLY command that downloads providers. Running plan or apply without init first will fail if providers are not installed
Provider source addresses use the format registry.terraform.io/hashicorp/aws — know the three-part namespace/type format
Domain 315% of exam
Core Terraform Workflow
The write-init-plan-apply workflow is the heart of using Terraform. This domain tests your understanding of each command, their flags, and how the workflow changes in team and HCP Terraform environments. At 15%, expect about 8-9 questions on workflow mechanics.
Key Topics
terraform initterraform planterraform applyterraform destroyterraform fmtterraform validate
Must-Know Concepts
- The core workflow is: Write configuration -> terraform init -> terraform plan -> terraform apply. Optionally terraform destroy to tear down
- terraform init: initializes backend, downloads providers and modules. Must be re-run when adding new providers, modules, or changing backend configuration
- terraform plan: creates an execution plan showing additions (+), modifications (~), and destructions (-). Can save to a file with -out=planfile
- terraform apply: executes changes. Without a plan file, it generates a new plan and asks for confirmation. With a plan file, it applies exactly what was planned
- terraform destroy: creates and executes a plan to destroy all managed resources. Equivalent to terraform apply -destroy
- terraform fmt: formats HCL files to canonical style. Does not change logic. Use -check flag to verify formatting without changing files
- terraform validate: checks syntax and internal consistency without accessing remote services or state
- The -auto-approve flag on apply and destroy skips the confirmation prompt
- The -target flag limits operations to specific resources, but should be used sparingly as it can lead to state inconsistencies
Common Exam Traps
terraform plan does NOT make any changes to infrastructure. It is a read-only operation. Only apply makes changes
terraform validate does NOT check that resources exist in the cloud. It only validates HCL syntax and internal references
When applying a saved plan file, Terraform does NOT ask for confirmation. It applies immediately because the plan was already reviewed
terraform fmt formats files in the current directory by default. Use -recursive to format all subdirectories
terraform init is idempotent — it is safe to run multiple times. It will not break existing state or downloads
Domain 422% of exam
Terraform Configuration
The largest domain at 22% covering everything about writing Terraform HCL: resources, data sources, variables, outputs, expressions, functions, dependencies, lifecycle rules, custom conditions, and sensitive data handling. This is where hands-on experience pays off most.
Key Topics
ResourcesData SourcesVariablesOutputsExpressionsFunctionsDependenciesLifecycleCustom ConditionsSensitive Data
Must-Know Concepts
- Resource blocks define infrastructure objects. Know meta-arguments: count, for_each, depends_on, provider, and lifecycle
- Data sources (data blocks) read information from existing infrastructure. They are read-only and do not create resources
- Input variables: declared with variable blocks, support types (string, number, bool, list, map, object, tuple, set), default values, validation rules, sensitive flag, and description
- Variable precedence (highest to lowest): -var CLI flag and -var-file, *.auto.tfvars, terraform.tfvars, environment variables (TF_VAR_name), default values. Note: TF_VAR_ env vars are above defaults but below terraform.tfvars
- Output values expose data from a module. Can be marked as sensitive. Used to pass data between modules and display information after apply
- Built-in functions: know common ones like join, split, lookup, merge, length, toset, tolist, file, templatefile, format, upper, lower, coalesce, try, can
- Implicit dependencies: Terraform automatically determines order when one resource references another. Explicit dependencies: use depends_on when there is no reference-based relationship
- Lifecycle meta-argument: create_before_destroy (create replacement before destroying old), prevent_destroy (error on destroy), ignore_changes (ignore specific attribute changes)
- Custom conditions: precondition (validate before create), postcondition (validate after create), check blocks (continuous validation as warnings)
- Ephemeral values and write-only arguments: never persisted to state, solving the problem of sensitive data leaking into terraform.tfstate
Common Exam Traps
Variable precedence: CLI -var flags override EVERYTHING. Environment variables (TF_VAR_) are above defaults but BELOW terraform.tfvars and *.auto.tfvars files — they are NOT the lowest. Correct order from lowest: defaults < TF_VAR_ env vars < terraform.tfvars < *.auto.tfvars < -var-file < -var flag
for_each requires a map or set of strings. If you pass a list, you must convert it to a set with toset(). count takes a number. Do not confuse them
depends_on creates an explicit dependency. It should only be used when Terraform cannot infer the dependency from resource references
prevent_destroy = true causes Terraform to error on ANY plan that would destroy the resource, including terraform destroy. Terraform refuses to proceed and shows an error like 'Instance cannot be destroyed'. To actually destroy the resource, you must first remove the prevent_destroy setting and apply, then destroy
Sensitive variables are hidden in plan and apply output, but they ARE stored in the state file in plaintext unless you use ephemeral values
Domain 512% of exam
Terraform Modules
Modules are reusable packages of Terraform configuration. This domain tests how to use, create, and structure modules, including passing data between modules and using the Terraform Registry. At 12%, expect about 7 questions.
Key Topics
Root ModuleChild ModulesTerraform RegistryModule SourcesModule Inputs/OutputsStandard Module Structure
Must-Know Concepts
- Every Terraform configuration has a root module (the directory where you run terraform commands). Child modules are called from the root module
- Module sources: local paths (./modules/vpc), Terraform Registry (hashicorp/consul/aws), GitHub URLs, S3 buckets, GCS buckets, and other supported sources
- Modules accept input variables and expose output values. The calling module passes values via arguments and reads results via module.name.output_name
- Standard module structure: main.tf (resources), variables.tf (input variables), outputs.tf (output values), README.md (documentation)
- Terraform Registry modules use semantic versioning. Always pin module versions in production using the version argument
- Modules encapsulate resources — resources inside a module are not directly accessible from outside. You must expose them via output values
- Provider configuration should NOT be defined inside modules (except in rare cases). Providers should be configured in the root module and passed to child modules
Common Exam Traps
You cannot reference a resource inside a child module directly. You MUST use outputs to expose values from a module to the calling configuration
Module source changes require re-running terraform init to download the new module version or source
Local modules (./path) do not need version constraints. Registry modules SHOULD always have version constraints
The root module is just the top-level configuration directory — it is also a module. Every Terraform configuration is technically a module
Provider configuration in child modules is an anti-pattern. Let the root module configure providers and pass them down
Domain 612% of exam
Terraform State Management
State is how Terraform tracks the real-world resources it manages. This domain covers local and remote state storage, state locking, state commands for refactoring, handling resource drift, and the moved block. Mismanaging state is the most common source of production Terraform problems.
Key Topics
State FileRemote BackendsState Lockingterraform state CommandsResource Driftmoved Block
Must-Know Concepts
- The state file (terraform.tfstate) maps configuration resources to real-world infrastructure. It is the source of truth for what Terraform manages
- Local state is stored in the current directory as terraform.tfstate. Remote state is stored in backends like S3, GCS, Azure Blob, or HCP Terraform
- State locking prevents concurrent operations from corrupting state. Not all backends support locking — S3 requires DynamoDB for locking
- terraform state list: lists all resources in state. terraform state show: displays attributes of a specific resource
- terraform state mv: moves a resource to a different address (renaming). terraform state rm: removes a resource from state WITHOUT destroying it
- terraform state pull/push: download or upload state manually (push is dangerous and should rarely be used)
- Resource drift: when real infrastructure changes outside Terraform. terraform plan detects drift by comparing state to actual resources
- The moved block in configuration (Terraform 1.1+) declares that a resource has been refactored (renamed/moved) without destroying and recreating it
- terraform import brings existing infrastructure into Terraform state. The import block (1.5+) is the modern approach
Common Exam Traps
terraform state rm removes a resource from state but does NOT destroy the actual infrastructure. The resource still exists in the cloud but Terraform no longer manages it
The state file contains sensitive information (resource attributes, passwords, keys). It should be encrypted and access-controlled when stored remotely
terraform refresh (now part of plan/apply with -refresh-only) updates state to match real infrastructure. It does NOT change infrastructure
You should NEVER manually edit the state file. Always use terraform state commands or terraform import to modify state
The moved block replaces terraform state mv for renaming resources in configuration. It is declarative and version-controlled
Domain 78% of exam
Maintain Infrastructure with Terraform
Covers ongoing infrastructure management tasks: importing existing resources, troubleshooting common issues, inspecting state, and debugging Terraform operations. While only 8% of the exam, these are practical skills that often appear in scenario-based questions.
Key Topics
terraform importImport Blockterraform showterraform outputTF_LOGterraform graph
Must-Know Concepts
- terraform import: brings existing infrastructure under Terraform management by adding it to the state file
- Import block (Terraform 1.5+): declarative way to import resources in configuration, can generate configuration automatically
- terraform show: displays the current state or a saved plan file in human-readable format
- terraform output: displays output values from the root module. Use -json for machine-readable format
- TF_LOG environment variable enables debug logging. Levels: TRACE (most verbose), DEBUG, INFO, WARN, ERROR
- TF_LOG_PATH: directs log output to a file instead of stderr
- terraform graph: generates a visual representation of the dependency graph in DOT format
- Troubleshooting workflow: check terraform validate errors, review plan output, enable TF_LOG for detailed logs, check provider documentation
Common Exam Traps
terraform import does NOT generate configuration. You must write the configuration BEFORE importing (unless using the import block in Terraform 1.5+)
TF_LOG=TRACE is the most verbose logging level, not DEBUG. TRACE shows every API call and internal operation
terraform show without arguments displays the current state. With a plan file argument, it shows the plan details
terraform graph outputs DOT format — you need a tool like Graphviz to render it visually
Domain 810% of exam
HCP Terraform
HCP Terraform (formerly Terraform Cloud) is HashiCorp's managed service for team collaboration. This domain covers remote state, VCS-driven workflows, workspace management, teams and permissions, policy enforcement, cost estimation, and projects. At 10%, expect about 5-6 questions.
Key Topics
HCP Terraform WorkspacesVCS IntegrationRemote OperationsSentinel PoliciesCost EstimationTeams & PermissionsProjects
Must-Know Concepts
- HCP Terraform provides remote state storage, remote execution, VCS integration, team collaboration, and governance features
- Workspace types: CLI-driven (runs triggered from local CLI) vs VCS-driven (runs triggered by Git commits/PRs)
- HCP Terraform workspaces are DIFFERENT from CLI workspaces. HCP workspaces have their own state, variables, run history, and access controls
- Remote execution: Terraform runs in HCP Terraform's infrastructure, not on your local machine. Provides consistent environment and audit trail
- Teams and permissions: organizations contain teams, teams are assigned workspace permissions (read, plan, write, admin, custom)
- Sentinel and OPA policies enforce governance rules. Three enforcement levels: advisory (warning), soft-mandatory (overridable by admins), hard-mandatory (cannot be overridden)
- Cost estimation runs between plan and apply, showing estimated monthly costs of infrastructure changes
- Projects organize workspaces into logical groups for management and access control at scale
- Dynamic provider credentials: HCP Terraform can generate short-lived credentials for cloud providers, eliminating the need for static secrets
Common Exam Traps
HCP Terraform workspaces are NOT the same as CLI workspaces created with terraform workspace new. This is the most common HCP Terraform exam trap
In VCS-driven workflows, speculative plans run on pull requests but do NOT apply changes. The apply only happens on merge to the tracked branch
Sentinel policies can reference cost estimates via the tfrun import. This is how you enforce cost limits
The free tier of HCP Terraform supports up to 500 managed resources. Know the tier limitations
Remote operations mean your local machine only sends configuration — the actual plan and apply run on HCP Terraform servers
Terraform Concepts You Must Not Confuse
These pairs appear on nearly every exam. Learn the difference and you'll avoid the most common traps.
Top Mistakes to Avoid
Confusing HCP Terraform workspaces (full environments with state, variables, access controls) with CLI workspaces (which only swap state files in the same directory)
Thinking terraform plan makes changes to infrastructure — it is read-only and only shows a preview of what will happen
Not knowing variable precedence: -var CLI flag beats everything, then -var-file, then *.auto.tfvars, then terraform.tfvars, then environment variables (TF_VAR_), and defaults are last — TF_VAR_ vars are above defaults but below all tfvars files
Confusing count (numeric index) with for_each (map/set keys) — removing items from count-based lists shifts all subsequent indexes and triggers recreation
Thinking prevent_destroy stops terraform destroy from working — it prevents destruction during changes, but terraform destroy still errors out and requires you to remove the lifecycle setting
Believing terraform import generates configuration — the legacy CLI command does NOT; only the import block (Terraform 1.5+) can generate config
Confusing data sources (read-only lookups) with resources (manage infrastructure) — data sources query existing infrastructure but never create or modify it
Thinking terraform validate checks whether cloud resources exist — it only validates HCL syntax and internal consistency, not actual infrastructure
Not understanding the dependency lock file (.terraform.lock.hcl) — it tracks provider versions and should be committed to version control, unlike the state file
Mixing up Sentinel enforcement levels: advisory (warning only), soft-mandatory (overridable), and hard-mandatory (cannot override)
Exam-Ready Checklist
Can explain all 8 exam domains and their relative weights — Terraform Configuration (22%) and Core Workflow (15%) are the heaviest
Know every terraform CLI command: init, plan, apply, destroy, fmt, validate, show, output, import, graph, console, and state subcommands
Can write variable blocks with types, defaults, validation rules, and sensitive flags from memory
Understand variable precedence order (lowest to highest): defaults < TF_VAR_ env vars < terraform.tfvars < *.auto.tfvars < -var-file < -var CLI flag
Can explain the difference between count and for_each, and know when to use each
Know all lifecycle meta-arguments: create_before_destroy, prevent_destroy, ignore_changes, replace_triggered_by
Can distinguish between HCP Terraform workspaces and CLI workspaces
Understand remote state, state locking, and all terraform state subcommands (list, show, mv, rm, pull, push)
Know the standard module structure and how to pass data between modules using variables and outputs
Can explain provider version constraints including the pessimistic constraint operator (~>)
Understand Sentinel policy enforcement levels: advisory, soft-mandatory, hard-mandatory
Know the difference between preconditions, postconditions, and check blocks
Can explain terraform import (CLI) vs import block (configuration) and their differences
Scored 70%+ on at least two full practice exams before scheduling the real exam
Recommended Resources
Free & Official Resources
Paid Courses & Practice Exams
These are recommended if you prefer a structured learning path. They can save time but are not required to pass.