Skip to content
Cheat sheets

002 · Domain 6: Advanced Module Usage and Registry Practices · 10% of the exam

Task 6.4: Validate modules with Terraform unit tests

terraform test for module authors: run blocks with plan or apply, assertions, expect_failures, variables in test files, mock providers and overrides, and what each run leaves behind.

Study it

  • terraform test: run blocks, assertions, expected failures and mocks

    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

A module test checks that an invalid instance type is rejected: run "rejects_unknown_type" { variables { instance_type = "m1.xlarge" } expect_failures = [var.instance_type] } The variable's validation block rejects the value, yet terraform test reports this run as failed. What should the author change?

  1. AList the validation block itself, var.instance_type.validation, in expect_failures
  2. BAdd an assert block whose condition is false to make the run expect an error
  3. CUse a mock_provider for the run to keep the failure away from a real API
  4. DAdd command = plan to the run; under the default command = apply, a condition failing at plan fails the run
Show the answer and why

  • AList the validation block itself, var.instance_type.validation, in expect_failures

    Incorrect

    expect_failures takes checkable objects such as the input variable; it is already listed correctly.

  • BAdd an assert block whose condition is false to make the run expect an error

    Incorrect

    A failing assertion is a test failure; it does not mark the validation failure as expected.

  • CUse a mock_provider for the run to keep the failure away from a real API

    Incorrect

    Variable validation runs during planning and does not depend on the provider; mocking does not change the outcome.

  • DAdd command = plan to the run; under the default command = apply, a condition failing at plan fails the run

    Correct

    A run with command = apply that expects a failure fails overall when the condition fails during plan; expected failures are best tested with command = plan.

Run blocks default to command = apply. Terraform only expects failures in the operation the run performs, so validation failures that occur at plan time are tested with command = plan.

HashiCorp documentation

Task 6.4Report a problem with this question

Question 2 · choose 1

A test file uses mock_provider "aws" {} so that tests run without credentials. One assertion checks that startswith(aws_s3_bucket.logs.arn, "arn:aws:s3:::") is true, and it fails. Nothing else is wrong. What explains the failure, and what fixes it?

  1. AMocked providers leave computed attributes null; add override_during = plan so they are generated
  2. BA computed string gets a random 8-character value; set arn in a mock_resource defaults block
  3. CAssertions cannot read attributes of mocked resources; move the check into a check block
  4. DThe arn is not known until apply; set command = apply in the run block
Show the answer and why

  • AMocked providers leave computed attributes null; add override_during = plan so they are generated

    Incorrect

    Mocked providers do generate values for computed attributes, so the arn is not null; it exists but has the wrong shape.

  • BA computed string gets a random 8-character value; set arn in a mock_resource defaults block

    Correct

    Mock providers do not know the format of computed attributes, so strings are random; mock_resource defaults supply a specific value.

  • CAssertions cannot read attributes of mocked resources; move the check into a check block

    Incorrect

    Assertions can reference values from mocked resources; they behave like real resources inside the test.

  • DThe arn is not known until apply; set command = apply in the run block

    Incorrect

    Run blocks already default to apply, and the generated value would still not match the format.

Mocked providers produce placeholder data: random strings, zero numbers, false booleans and empty collections. When a test depends on a value's shape, give it explicitly with mock_resource, mock_data or an override.

HashiCorp documentation

Task 6.4Report a problem with this question

Question 3 · choose 1

A module keeps its test files in integration/ instead of tests/. How does terraform test find them?

  1. AIt finds them anywhere in the repository
  2. BWith -test-directory=integration
  3. CWith -filter=integration
  4. DBy renaming them to .tf files
Show the answer and why

  • AIt finds them anywhere in the repository

    Incorrect

    Terraform looks in the configuration directory and the test directory.

  • BWith -test-directory=integration

    Correct

    -test-directory overrides the default tests directory; test files in the main configuration directory are always loaded.

  • CWith -filter=integration

    Incorrect

    -filter selects specific test files.

  • DBy renaming them to .tf files

    Incorrect

    Test files use .tftest.hcl or .tftest.json.

Keep the default tests directory unless a layout requires otherwise.

HashiCorp documentation

Task 6.4Report a problem with this question

Question 4 · choose 1

A test file sets bucket_prefix = "unit" in its variables block. The CI job also exports TF_VAR_bucket_prefix=ci and passes -var bucket_prefix=cli. Which value do the run blocks see?

  1. Acli, from the command-line flag
  2. Bci, from the environment variable
  3. Cunit, from the .tftest.hcl
  4. DTerraform errors on the conflict
Show the answer and why

  • Acli, from the command-line flag

    Incorrect

    Test file variables override command-line input.

  • Bci, from the environment variable

    Incorrect

    Environment variables rank lower still.

  • Cunit, from the .tftest.hcl

    Correct

    Variables defined in test files take the highest precedence.

  • DTerraform errors on the conflict

    Incorrect

    Precedence resolves it.

Precedence among other sources stays the same within tests.

HashiCorp documentation

Task 6.4Report a problem with this question

Question 5 · choose 1

A test file has a setup run that creates a bucket, then a run that writes objects into it. In what order does cleanup happen?

  1. AIn reverse run order, the later run's state first
  2. BIn run order, setup first
  3. CIn parallel, all at once
  4. DNever; test resources stay
Show the answer and why

  • AIn reverse run order, the later run's state first

    Correct

    Terraform destroys resources in reverse run block order at the end of the test file.

  • BIn run order, setup first

    Incorrect

    That would try to delete a bucket that still holds objects.

  • CIn parallel, all at once

    Incorrect

    Order matters, so cleanup follows reverse run order.

  • DNever; test resources stay

    Incorrect

    Terraform attempts to destroy what it created.

Cleanup order explains why setup modules must allow their dependents to be removed first.

HashiCorp documentation

Task 6.4Report a problem with this question

Question 6 · choose 1

A team wants to run a module's tests remotely in HCP Terraform with terraform test -cloud-run. What must the option point to?

  1. AAny public registry module source
  2. BA workspace name
  3. CA local path to the module
  4. DA private registry module, after terraform login
Show the answer and why

  • AAny public registry module source

    Incorrect

    Public registry modules are not accepted.

  • BA workspace name

    Incorrect

    The option takes a module source.

  • CA local path to the module

    Incorrect

    Remote runs associate with a registry module.

  • DA private registry module, after terraform login

    Correct

    -cloud-run accepts a private registry module source, and you must run terraform login first.

-junit-xml is not compatible with remote execution through -cloud-run.

HashiCorp documentation

Task 6.4Report a problem with this question

Practice domain 6 →Practice all domains →