Terraform test framework (1.6+) - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding Terraform Test Framework Behavior

What will be the result of running a Terraform test that uses the terraform_test block with required_providers specified but the provider version constraint is not met?

Terraform

terraform {
  required_version = ">= 1.6"
}

terraform {
  required_providers = {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0, < 4.50"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "test" {
  bucket = "tf-test-bucket"
}

output "bucket_name" {
  value = aws_s3_bucket.test.bucket
}

A Terraform will ignore the version constraint and run the test with the installed provider version 4.60.0.

B The test will succeed but the output "bucket_name" will be empty.

C Terraform will downgrade the provider automatically to a compatible version and run the test.

D The test run will fail with a provider version constraint error before any resources are created.

💡 Hint

Think about how Terraform enforces provider version constraints during initialization.

Terraform test framework enforces the required_providers version constraints strictly. If the installed provider version does not satisfy the constraint, the test run fails during initialization with a version conflict error.

❓ Configuration

intermediate

Terraform Test Framework Output Verification

Given a Terraform test that creates an AWS S3 bucket and outputs its name, which option correctly verifies the output value in the test code using the Terraform test framework?

Terraform

terraform {
  required_providers = {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0"
    }
  }
}

resource "aws_s3_bucket" "test" {
  bucket = "tf-test-bucket"
}

output "bucket_name" {
  value = aws_s3_bucket.test.bucket
}

// Test code snippet to verify output goes here

A

test "bucket_name" {
  assert_equal(output["bucket_name"], "tf-test-bucket")
}

B

test "bucket_name" {
  assert(output["bucket_name"] = "tf-test-bucket")
}

C

test "bucket_name" {
  assert(output.bucket_name == "tf-test-bucket")
}

D

test "bucket_name" {
  assert_equal(output.bucket_name, "tf-test-bucket")
}

💡 Hint

Check the syntax for accessing outputs and the assertion function in Terraform test framework.

In Terraform test framework, outputs are accessed as a map with string keys. The correct assertion function is assert_equal(actual, expected). Option A uses the correct syntax and function.

❓ Architecture

advanced

Isolating Test Runs with Terraform Test Framework

You want to run multiple Terraform tests in parallel, each creating resources in AWS without interfering with each other. Which approach best ensures isolation of test runs using Terraform test framework 1.6+?

A Use unique random suffixes for resource names in each test and configure separate backend workspaces per test.

B Run all tests in the default workspace and rely on Terraform to isolate resource names automatically.

C Use the same resource names but different AWS regions for each test run without changing backend configuration.

D Run tests sequentially to avoid conflicts instead of parallel execution.

💡 Hint

Think about how Terraform state and resource naming affect test isolation.

To isolate tests, each test should use unique resource names (e.g., with random suffixes) and separate backend workspaces to keep state isolated. This prevents resource conflicts and state overwrites during parallel runs.

❓ security

advanced

Handling Sensitive Data in Terraform Tests

In Terraform test framework 1.6+, you need to test a module that requires sensitive variables like AWS credentials. What is the best practice to handle sensitive data securely during tests?

A Hardcode sensitive values directly in the test configuration for simplicity.

B Store sensitive data in plain text files checked into version control for easy access.

C Use environment variables or Terraform variable files with sensitive flags and avoid printing sensitive outputs.

D Disable sensitive flags on variables to allow easy debugging during tests.

💡 Hint

Consider how Terraform handles sensitive variables and best security practices.

Best practice is to pass sensitive data via environment variables or secure variable files marked as sensitive, and avoid exposing them in outputs or logs. Hardcoding or storing in plain text files risks leaks.

✅ Best Practice

expert

Optimizing Terraform Test Runs for Speed and Reliability

You have a large Terraform test suite using the Terraform test framework 1.6+. Tests create and destroy many resources, causing long execution times. Which strategy best improves test speed and reliability without sacrificing test coverage?

A Run all tests independently with full resource creation and destruction to ensure isolation.

B Group related tests into suites that share setup and teardown steps to reuse resources where possible.

C Skip tests that create expensive resources to save time, even if coverage decreases.

D Use manual resource cleanup after tests instead of Terraform destroy to speed up runs.

💡 Hint

Think about balancing test isolation with resource reuse to optimize performance.

Grouping tests to share setup and teardown reduces redundant resource creation and destruction, speeding up tests while maintaining coverage and reliability. Independent full runs increase time, skipping reduces coverage, and manual cleanup risks state drift.

Practice

1. What is the main purpose of the Terraform test framework introduced in version 1.6+?

easy

A. To monitor cloud resources for performance issues

B. To deploy infrastructure faster without manual approval

C. To write automated tests that check your infrastructure code works as expected

D. To replace Terraform CLI commands with a graphical interface

Solution

1. Step 1: Understand Terraform test framework purpose

   The framework is designed to let you write tests that run your Terraform code and verify resource attributes automatically.

2. Step 2: Compare options with framework purpose

   Only To write automated tests that check your infrastructure code works as expected correctly describes writing automated tests for infrastructure code. Other options describe unrelated features.

3. Final Answer:

   To write automated tests that check your infrastructure code works as expected -> Option C

4. Quick Check:

   Test framework purpose = automated infrastructure tests [OK]

Hint: Focus on testing infrastructure code correctness [OK]

Common Mistakes:

• Confusing testing with deployment speed
• Thinking it replaces CLI commands
• Mixing testing with monitoring

2. Which of the following is the correct syntax to define a Terraform test block in version 1.6+?

easy

A. module "test" { ... }

B. terraform_test "example" { ... }

C. resource "test" "example" { ... }

D. test "example" { ... }

Solution

1. Step 1: Recall Terraform test block syntax

   Terraform 1.6+ uses the test "name" { ... } block to define tests.

2. Step 2: Eliminate incorrect syntax options

   Options B, C, and D use incorrect block types or resource/module keywords not related to tests.

3. Final Answer:

   test "example" { ... } -> Option D

4. Quick Check:

   Test block syntax = test "name" [OK]

Hint: Look for the exact 'test' block keyword [OK]

Common Mistakes:

• Using resource or module instead of test block
• Adding extra prefixes like terraform_test
• Confusing test block with resource block

3. Given this Terraform test snippet, what will the test check?

test "check_instance" {
  config = {
    resource "aws_instance" "example" {
      ami           = "ami-123456"
      instance_type = "t2.micro"
    }
  }
  check { 
    resource = "aws_instance.example"
    attribute = "instance_type"
    equals = "t2.micro"
  }
}

medium

A. It checks if the AMI ID is 't2.micro'

B. It checks if the instance type of aws_instance.example is 't2.micro'

C. It verifies the instance is running

D. It validates the resource name is 'aws_instance.example'

Solution

1. Step 1: Analyze the check block

   The check block specifies resource "aws_instance.example", attribute "instance_type", and expects it to equal "t2.micro".

2. Step 2: Match check with options

   It checks if the instance type of aws_instance.example is 't2.micro' correctly states the test checks the instance_type attribute equals "t2.micro". Other options misunderstand attribute or resource checks.

3. Final Answer:

   It checks if the instance type of aws_instance.example is 't2.micro' -> Option B

4. Quick Check:

   Check attribute equals instance_type = t2.micro [OK]

Hint: Focus on attribute and equals fields in check block [OK]

Common Mistakes:

• Confusing AMI ID with instance type
• Assuming runtime status is checked
• Misreading resource name as attribute

4. This Terraform test code fails to run. What is the most likely error?

test "fail_test" {
  config = {
    resource "aws_s3_bucket" "bucket" {
      bucket = "my-bucket"
    }
  }
  check {
    resource = "aws_s3_bucket.bucket"
    attribute = "name"
    equals = "my-bucket"
  }
}

medium

A. The attribute 'name' does not exist for aws_s3_bucket resource

B. The resource block is missing required 'region' argument

C. The test block name cannot contain underscores

D. The equals value must be a number, not a string

Solution

1. Step 1: Check attribute correctness

   The aws_s3_bucket resource uses 'bucket' as the attribute for bucket name, not 'name'. Using 'name' causes the test to fail.

2. Step 2: Verify other options

   Region is usually set in provider, not required here. Test names can have underscores. Equals can be string. So only attribute error is valid.

3. Final Answer:

   The attribute 'name' does not exist for aws_s3_bucket resource -> Option A

4. Quick Check:

   Attribute must match resource schema [OK]

Hint: Check attribute names match resource documentation [OK]

Common Mistakes:

• Using wrong attribute names
• Assuming region is required in resource block
• Thinking test names have naming restrictions
• Confusing data types in equals

5. You want to write a Terraform test that verifies multiple attributes of an AWS EC2 instance, including instance_type and tags. Which approach correctly uses the Terraform test framework to check both attributes in one test?

hard

A. Use multiple check blocks inside one test block, each checking one attribute

B. Create separate test blocks for each attribute check

C. Combine attributes in one check block using a list for attribute and equals

D. Use a single check block with a map for attribute and equals

Solution

1. Step 1: Understand multiple attribute checks in Terraform tests

   The Terraform test framework allows multiple check blocks inside one test block to verify different attributes separately.

2. Step 2: Evaluate options for correctness

   Using multiple check blocks inside one test block, each checking one attribute, correctly verifies different attributes separately. Combining attributes into a single check block using a list or map is not supported. Creating separate test blocks for each attribute check works but is less efficient.

3. Final Answer:

   Use multiple check blocks inside one test block, each checking one attribute -> Option A

4. Quick Check:

   Multiple checks = multiple check blocks [OK]

Hint: Use one check block per attribute inside test [OK]

Common Mistakes:

• Trying to check multiple attributes in one check block
• Splitting checks into many test blocks unnecessarily
• Using unsupported data structures in check block