Skip to content
Cheat sheets

004 · Domain 3: Core Terraform workflow · 13% of the exam

Task 3.3: Validate a Terraform configuration

terraform validate: syntax and internal consistency checked without contacting remote services, what it needs from init, and what it cannot catch.

Study it

  • terraform validate and what it cannot catch

    Lesson coming

Sample questions

Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.

Question 1 · choose 1

terraform validate passes on a configuration, but the following apply fails because the requested machine type is not offered in the chosen region. Why didn't validate catch it?

  1. Avalidate checks only the root module and skips the resources in child modules
  2. Bvalidate was run without -json, which is needed for the full provider checks
  3. Cvalidate uses cached API results from the last plan, which predated the region change
  4. Dvalidate checks syntax and internal consistency only and never calls provider APIs
Show the answer and why

  • Avalidate checks only the root module and skips the resources in child modules

    Incorrect

    validate covers the whole configuration, including installed child modules.

  • Bvalidate was run without -json, which is needed for the full provider checks

    Incorrect

    -json changes the output format, not what is checked.

  • Cvalidate uses cached API results from the last plan, which predated the region change

    Incorrect

    validate does not read plans or call APIs at all.

  • Dvalidate checks syntax and internal consistency only and never calls provider APIs

    Correct

    validate verifies that the configuration is syntactically valid and internally consistent; it does not validate remote services such as provider APIs.

validate answers "is this a well-formed configuration?", not "will the platform accept it?"; only plan and apply talk to the APIs.

HashiCorp documentation

Task 3.3Report a problem with this question

Question 2 · choose 1

A new CI job checks out a repository and runs terraform validate as its first command. The configuration calls a module from the Terraform Registry and requires two providers. The same command passes on the developer's laptop but fails in the job. What does the job need to do?

  1. ARun terraform plan first, so validate has a plan to compare against
  2. BRun terraform init first, so the module and both providers are installed
  3. CRun terraform get first, which downloads the module and both providers
  4. DCopy in the laptop's state file first, as validate compares against state
Show the answer and why

  • ARun terraform plan first, so validate has a plan to compare against

    Incorrect

    validate does not read plans; it checks the configuration files themselves, and a plan would also need an initialized working directory.

  • BRun terraform init first, so the module and both providers are installed

    Correct

    Validation requires an initialized working directory with any referenced plugins and modules installed, and terraform init installs both.

  • CRun terraform get first, which downloads the module and both providers

    Incorrect

    terraform get downloads modules only and skips the other initialization tasks, so the providers would still be missing.

  • DCopy in the laptop's state file first, as validate compares against state

    Incorrect

    validate checks the configuration regardless of any existing state, so a state file does not help.

A laptop that has run terraform init already has the providers and modules installed; a fresh checkout does not, so the job runs init before validate.

HashiCorp documentation

Task 3.3Report a problem with this question

Question 3 · choose 1

A teammate says terraform fmt has already checked their configuration, so validate is not needed. Why is that wrong?

  1. Afmt runs validate automatically, so the teammate is right
  2. Bfmt fixes layout; validate checks names, types and references
  3. Cvalidate also reformats files, which fmt cannot do
  4. Dfmt only works on child modules, and validate only works on root configurations
Show the answer and why

  • Afmt runs validate automatically, so the teammate is right

    Incorrect

    fmt does not validate configurations.

  • Bfmt fixes layout; validate checks names, types and references

    Correct

    fmt applies style conventions; validate verifies syntax and internal consistency, including attribute names and value types.

  • Cvalidate also reformats files, which fmt cannot do

    Incorrect

    validate never changes files.

  • Dfmt only works on child modules, and validate only works on root configurations

    Incorrect

    Both work on any directory of configuration.

Style and correctness are separate checks; run both.

HashiCorp documentation

Task 3.3Report a problem with this question

Question 4 · choose 1

A resource sets an argument that expects a number to the string "two", and another argument name is misspelled. When are both errors reported?

  1. AOnly during apply, when the provider sends the values to the remote API for the first time
  2. BBy terraform fmt, which rejects files with type errors
  3. CBy terraform validate, which checks names and value types
  4. DNever; Terraform converts every string to the type it needs
Show the answer and why

  • AOnly during apply, when the provider sends the values to the remote API for the first time

    Incorrect

    These are configuration errors that validate catches before any API call.

  • BBy terraform fmt, which rejects files with type errors

    Incorrect

    fmt checks layout, not types.

  • CBy terraform validate, which checks names and value types

    Correct

    validate verifies correctness of attribute names and value types against the provider schema.

  • DNever; Terraform converts every string to the type it needs

    Incorrect

    Terraform converts where it can, but "two" is not a number.

Wrong names and wrong types are the core of what validate is for.

HashiCorp documentation

Task 3.3Report a problem with this question

Question 5 · choose 1

A module team has no environment of its own, only the module's source code. Which check does the validate documentation describe as its primary use?

  1. AGeneral verification of reusable modules
  2. BChecking that a module's resources do not already exist in the target cloud account
  3. CComparing a module's outputs with a previous release
  4. DEstimating the cost of a module before publishing it
Show the answer and why

  • AGeneral verification of reusable modules

    Correct

    The documentation describes validate as primarily useful for general verification of reusable modules, including attribute names and value types.

  • BChecking that a module's resources do not already exist in the target cloud account

    Incorrect

    validate checks the configuration itself, not what already exists anywhere.

  • CComparing a module's outputs with a previous release

    Incorrect

    validate does not compare versions.

  • DEstimating the cost of a module before publishing it

    Incorrect

    Cost estimation is an HCP Terraform feature that runs on plans.

A module without an environment can still be validated; that is what the command is built for.

HashiCorp documentation

Task 3.3Report a problem with this question

Practise domain 3 →Practise all domains →