SaveMyCert
Log in
5 of 5 free questions left today·for 10 a day
Terraform Pro 002 practice

Free Terraform Pro 002 practice questions

Drill exam-realistic HashiCorp Certified: Terraform Infrastructure Engineer Professional (002) questions by domain, with an explanation on every option — not just the right one. 5 fully worked examples are further down this page, answers included.

Question bank
793
across 7 domains
Free, no account
5/day
a free account allows 10 a day
Real exam
90 min
question count not yet published · pass Pass / fail
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across all domains, in Learn mode.

Review what you missed

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

5 sample Terraform Pro 002 questions, fully explained

Real questions from the Terraform Pro 002 bank, with the answer key and the reasoning behind every option. Read them, then go back up the page and try the rest.

Question 1Scalable Terraform configuration design

A platform team's requirement says the environment input of a shared module may only be dev, staging or prod, and a mistyped value must stop the run before Terraform produces any plan. What should the module author add?

Choose one.

  • a
    A validation block on the variable using contains() in its condition Correct

    Input variable validation runs before a plan is generated and errors when the condition is false, so a typo such as "prdo" stops the run immediately.

  • b
    A precondition on each resource that reads the environment variable

    A precondition is checked during planning, later than input validation, and the rule must be repeated on every resource that reads the input instead of living with the input.

  • c
    A check block with an assert that compares the environment variable

    A check block only reports a warning; the run continues, so the bad value would still be planned.

  • d
    A string type constraint on the variable with nullable set to false

    A string type and nullable = false reject null or non-string values, but any string, including a typo, is accepted.

The concept

Input variable validation encodes allowed values for an input and is checked before Terraform builds a plan.

Why that’s the answer

The requirement has two parts: only three allowed values, and failure before planning. A validation block on the variable checks the value as soon as Terraform evaluates the input, before planning, and errors with your error_message. A precondition would also error, but it is checked later, while the plan is built, and must be copied onto every resource; a check block only warns; a type constraint cannot list allowed values.

How to reason it out
  1. Identify where the rule belongs: on the input itself.
  2. Note the timing requirement: before a plan exists.
  3. Recall that validation errors before planning while check blocks only warn.
  4. Reject type constraints, which cannot express an allowed-value list.

Exam tip: Allowed values for an input belong in a validation block on that variable.

Terraform Professional (002): Turning Requirements into Predictable, Secure Configuration — the lesson that teaches this.

Question 2Terraform state and backend operations

To give each environment its own state bucket, an engineer edits the root module's backend block:terraform { backend "s3" { bucket = var.state_bucket key = "app/terraform.tfstate" region = "eu-west-1" } }The variable has a default value. What happens when the engineer runs terraform init?

Choose one.

  • a
    Init prompts for the state_bucket value before it configures the backend block

    Terraform prompts only for required backend arguments left out of a partial configuration; it does not evaluate variables in the backend block.

  • b
    Init uses the default value declared on state_bucket for this block

    Backend configuration is processed before variables are evaluated, so a variable default is never substituted into it.

  • c
    Init stops with an error because the block refers to a named value Correct

    A backend block cannot refer to named values such as input variables, locals or data source attributes, so initialization fails with an error.

  • d
    Init reads state_bucket from terraform.tfvars when it is present

    Variable definition files feed input variables during plan and apply; they are not read into the backend block.

The concept

A backend block is static: it cannot reference input variables, locals or data source attributes.

Why that’s the answer

Terraform needs the backend before it can evaluate the rest of the configuration, so the backend block accepts only literal values. Referencing var.state_bucket is an error at init. Per-environment values belong in partial configuration supplied with -backend-config, not in variables, defaults or tfvars files.

How to reason it out
  1. Notice the backend argument is an expression, not a literal.
  2. Recall that backend blocks cannot refer to named values.
  3. Conclude that init fails rather than substituting a value.
  4. Use -backend-config for values that differ by environment.

Exam tip: Backend blocks take literals only; vary them with -backend-config, never with variables.

Terraform Professional: Remote Backends and Remote State — the lesson that teaches this.

Question 3Infrastructure lifecycle and operations

A team manages dev, staging and prod from one Terraform configuration with an S3 backend. A new security rule says prod applies must run with an AWS role that dev engineers cannot assume, and prod state must sit in a bucket only the platform team can read. Which way of separating the environments meets the rule?

Choose one.

  • a
    CLI workspaces dev, staging and prod in the existing configuration

    Workspaces in one working directory share the same backend, so prod state lands in the same bucket that dev engineers already use.

  • b
    CLI workspaces plus a provider role ARN chosen by terraform.workspace

    This changes the provider role, but all workspaces still share one backend and its access, so prod state stays readable to dev engineers.

  • c
    A separate root configuration and backend for each environment Correct

    Each root has its own backend block (prod's own bucket) and runs with its own credentials, so prod state and the prod role can be locked to the platform team.

  • d
    One configuration with a -var-file per environment on the same backend

    Variable files change inputs only; the backend, and whoever can read it, is the same for every environment.

The concept

CLI workspaces give several states to one configuration through one backend; separate root configurations give each environment its own backend and credentials.

Why that’s the answer

The deciding requirement is isolation of state access and credentials. HashiCorp documents that CLI workspaces are not appropriate for deployments needing separate credentials and access controls, because every workspace uses the same backend. Choosing a role per workspace fixes only the provider side, and tfvars files change only inputs. A separate root configuration per environment can point prod at its own bucket and run with prod-only credentials.

How to reason it out
  1. Identify the constraint: prod state and prod credentials isolated from dev engineers.
  2. Recall that every CLI workspace in a directory uses the same backend.
  3. Note that per-workspace inputs or role ARNs do not change who can read the backend.
  4. Choose a structure that gives prod its own backend and credentials.

Exam tip: Separate credentials or access controls per environment: separate root configurations, not CLI workspaces.

Terraform Professional: Scaling Projects and Multiple Environments — the lesson that teaches this.

Question 4CI/CD and automation workflows

A pull-request job must fail when any .tf file in the repository is not in canonical format, including files under modules/ and envs/. The job must never rewrite files in the checkout. Which command should it run from the repository root?

Choose one.

  • a
    terraform fmt -check -recursive Correct

    -check never writes files and exits non-zero when any input is unformatted; -recursive extends it to every subdirectory.

  • b
    terraform fmt -check -list=true

    -check is right, but without -recursive fmt only processes the current directory, so modules/ and envs/ are never examined.

  • c
    terraform validate -no-color

    validate checks syntax and internal consistency, not canonical formatting, so misformatted but valid files pass.

  • d
    terraform fmt -diff -recursive -list=true

    Without -check, fmt still rewrites every unformatted file it finds; -diff and -list only add output, so the job neither fails nor stays read-only.

The concept

terraform fmt rewrites files to the canonical style; -check turns it into a read-only gate and -recursive widens its scope.

Why that’s the answer

With -check, fmt does not modify files (it implies -write=false) and its exit status is 0 only when the input is already formatted, so the job fails on any finding. By default fmt processes only the specified or current directory, so -recursive is needed for modules/ and envs/. -diff alone shows and still applies changes, and validate does not look at formatting at all.

How to reason it out
  1. Identify the two requirements: whole repository, no writes.
  2. -check gives a read-only pass/fail exit status.
  3. -recursive adds subdirectories, which fmt skips by default.
  4. Combine them.

Exam tip: CI formatting gate: terraform fmt -check -recursive.

Terraform Professional: CI/CD Pipelines and Deployment Strategies — the lesson that teaches this.

Question 5Terraform security and governance

A root module that runs in an HCP Terraform workspace declares a third-party API key as an input variable whose default is the real key, and the file is committed to the team's repository. The key must leave the repository while runs keep receiving it. What should the team do?

Choose one.

  • a
    Remove the default and store the key as a sensitive workspace variable Correct

    The value no longer exists in version control, and HCP Terraform supplies it to every run as a write-only variable that nobody can read back in the UI or API.

  • b
    Keep the default and add sensitive = true to the variable declaration

    sensitive only redacts the value in CLI and UI output; the key would still sit in the committed .tf file.

  • c
    Move the default into a terraform.tfvars file in the same repository

    The key moves to another committed file, so it is still in version control and its history.

  • d
    Move the value into a locals block in a separate secrets.tf file

    A local value is still configuration text in the repository, so the key stays committed.

The concept

Secret values belong in a secret store or a protected variable, never in configuration text that is committed.

Why that’s the answer

The requirement is that the key leaves the repository. Removing the default and supplying the value as a sensitive workspace variable achieves that while keeping runs working. Marking the variable sensitive, or moving the value to tfvars or locals, only relocates or redacts it; every copy remains in version control.

How to reason it out
  1. Find where the secret currently lives: a committed default.
  2. Ask whether each option removes it from version control.
  3. Recall that sensitive = true redacts output but does not move the value.
  4. Choose the option that supplies the value from outside the repository.

Exam tip: Redacting a secret is not removing it: secrets come from outside the repository.

Terraform Professional (002): Secrets, Rotation and Pipeline Identities — the lesson that teaches this.

The Terraform Pro 002 question bank, by domain

The bank is built to the exam's own weighting, so the practice you get reflects the marks that are actually on offer — not whichever domain was easiest to write questions for.

Published Terraform Pro 002 practice questions per exam domain
DomainExam weightTopicsQuestions
Scalable Terraform configuration design20%4160
Terraform state and backend operations13%3105
Infrastructure lifecycle and operations22%5175
CI/CD and automation workflows10%279
Terraform security and governance13%298
Advanced module usage and registry practices10%280
HCP Terraform and Terraform Enterprise operations12%296
Total100%20793

Practise Terraform Pro 002 one domain at a time

Domain 1: Scalable Terraform configuration design20% of the exam · 160 questions, with worked examples and a topic breakdown.Domain 2: Terraform state and backend operations13% of the exam · 105 questions, with worked examples and a topic breakdown.Domain 3: Infrastructure lifecycle and operations22% of the exam · 175 questions, with worked examples and a topic breakdown.Domain 4: CI/CD and automation workflows10% of the exam · 79 questions, with worked examples and a topic breakdown.Domain 5: Terraform security and governance13% of the exam · 98 questions, with worked examples and a topic breakdown.Domain 6: Advanced module usage and registry practices10% of the exam · 80 questions, with worked examples and a topic breakdown.Domain 7: HCP Terraform and Terraform Enterprise operations12% of the exam · 96 questions, with worked examples and a topic breakdown.

How Terraform Pro 002 questions are worded

Most Terraform Pro 002 questions are not asking whether you can recall a definition. They describe a situation and ask which option satisfies it — so the skill being tested is reading the requirement precisely and eliminating options that fail it.

Single-response vs multiple-response

A single-response question has exactly one right answer. A multiple-response question tells you how many to pick ("Choose TWO") and there is no partial credit — getting one of the two right scores nothing. Read that instruction before you read the options.

Read the last line first

The final sentence is the actual question; everything before it is scenario. Read it first, then read the scenario knowing what you are looking for. It stops you from building an answer in your head that the question never asked for.

Hunt for the qualifier

Most scenarios turn on one word — MOST cost-effective, LEAST operational overhead, with the LEAST latency, without changing application code. Two options are frequently both technically correct, and the qualifier is the only thing separating them.

Eliminate, then choose

Distractors are almost always real HashiCorp services doing a real job — just not this job. Rule out the ones that break a stated constraint before you compare what's left. On a question you truly don't know, eliminating two options turns a guess into a coin flip.

Practise Terraform Pro 002 from your browser

The SaveMyCert Chrome extension opens a daily drill of 5 Terraform Pro 002 questions in the side panel, with the full explanation behind every answer. No account needed.

Get the Chrome extension (opens in a new tab)

Beyond Terraform Pro 002 practice

Terraform Pro 002 sample questions with answersA page of fully worked questions across every domain, answers and explanations included.Terraform Pro 002 revision notes20 lessons covering every domain — go back to the source when a question keeps catching you out.Terraform Pro 002 cheat sheetEvery key fact on one page. Skim it the week of the exam.Terraform Pro 002 flashcardsThe same key facts one at a time, answer hidden until you commit — recall practice rather than re-reading.Terraform Pro 002 mock examsQuestions are practice; our 65-question mocks run against the real exam's 90-minute clock. Rehearse the real thing.HashiCorp Certified: Terraform Infrastructure Engineer Professional (002) (Terraform Pro 002) exam overviewExam facts, who it is for, cost and how it fits alongside the other certifications.

Terraform Pro 002 practice questions: your questions

Yes. You can answer 5 questions a day with no account at all, and a free account raises that to 10 a day across the full 793-question Terraform Pro 002 bank, with an explanation on every option. Pro removes the daily cap entirely.

Source

Exam structure, domain weights and scoring on this page come from the official Terraform Pro 002 exam guide.