Test file structure in Terraform - Commands & Configuration

Introduction

When working with Terraform, organizing your files clearly helps you manage your infrastructure easily. A good file structure separates variables, resources, and outputs so you can find and update things quickly.

When you start a new Terraform project and want to keep your code clean and easy to understand.

When you want to share your Terraform code with teammates and make it simple for them to follow.

When your infrastructure grows and you need to add more resources without confusion.

When you want to reuse variables and outputs across different parts of your project.

When you want to avoid mistakes by clearly separating configuration parts.

Config File - main.tf

main.tf

terraform {
  required_version = ">= 1.0"
}

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

resource "aws_s3_bucket" "example_bucket" {
  bucket = "example-terraform-bucket-12345"
  acl    = "private"
}

This main.tf file defines the Terraform version, sets the AWS provider with a region, and creates a simple S3 bucket resource. This is the core file where resources live.

Commands

This command initializes the Terraform project by downloading necessary provider plugins and setting up the backend.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/aws...

- Installing hashicorp/aws v4.0.0...

- Installed hashicorp/aws v4.0.0 (signed by HashiCorp)



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure.

This command shows what Terraform will do when you apply your configuration. It previews the changes without making them.

Terminal

terraform plan

Expected Output

An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Terraform will perform the following actions:



  # aws_s3_bucket.example_bucket will be created

  + resource "aws_s3_bucket" "example_bucket" {

      + acl    = "private"

      + bucket = "example-terraform-bucket-12345"

      + id     = (known after apply)

    }



Plan: 1 to add, 0 to change, 0 to destroy.

This command applies the changes to create the resources defined in your configuration. The -auto-approve flag skips the confirmation prompt.

Terminal

terraform apply -auto-approve

Expected Output

aws_s3_bucket.example_bucket: Creating...

aws_s3_bucket.example_bucket: Creation complete after 2s [id=example-terraform-bucket-12345]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approve the apply without asking for confirmation

This command deletes all resources created by Terraform in this project. The -auto-approve flag skips the confirmation prompt.

Terminal

terraform destroy -auto-approve

Expected Output

aws_s3_bucket.example_bucket: Destroying...

aws_s3_bucket.example_bucket: Destruction complete after 1s



Destroy complete! Resources: 1 destroyed.

→

-auto-approve - Automatically approve the destroy without asking for confirmation

Key Concept

If you remember nothing else from this pattern, remember: organize your Terraform files clearly to keep your infrastructure code simple and easy to manage.

Common Mistakes

Putting all Terraform code in one big file without separating variables and resources.

This makes the code hard to read and update, especially as the project grows.

Use separate files like variables.tf for variables, main.tf for resources, and outputs.tf for outputs.

Not running terraform init before other commands.

Terraform needs to download providers and set up the project before planning or applying.

Always run terraform init first when starting or after changing providers.

Summary

Create a main.tf file to define your provider and resources clearly.

Run terraform init to prepare your project before planning or applying.

Use terraform plan to preview changes and terraform apply to create resources.

Organize files to keep your infrastructure code clean and easy to maintain.

Practice

1. What is the main reason to keep Terraform test files separate from production code files?

easy

A. Because Terraform does not support test files inside the main folder

B. To avoid mixing test code with production code and keep the project organized

C. To reduce the size of the Terraform state file

D. Because test files must be written in a different language

Solution

1. Step 1: Understand file organization purpose

   Separating test files helps keep the project clean and easier to manage by not mixing test and production code.

2. Step 2: Recognize Terraform best practices

   Terraform encourages clear separation to avoid confusion and accidental deployment of test code.

3. Final Answer:

   To avoid mixing test code with production code and keep the project organized -> Option B

4. Quick Check:

   Separate test files = organized project [OK]

Hint: Keep test files separate to avoid confusion [OK]

Common Mistakes:

• Thinking test files must be in main folder
• Believing test files affect state size
• Assuming test files require different language

2. Which of the following is the correct folder structure for organizing Terraform files including tests?

easy

A. /main.tf, /variables.tf, /outputs.tf, /test/main_test.tf

B. /main.tf, /variables.tf, /outputs.tf, /modules/tests/test_main.tf

C. /main.tf, /variables.tf, /outputs.tf, /tests/test_main.tf

D. /main.tf, /variables.tf, /outputs.tf, /tests/main_test.tf

Solution

1. Step 1: Identify standard test folder naming

   Tests are usually placed in a separate folder named 'tests' at the root level for clarity.

2. Step 2: Check file naming conventions

   Test files often have '_test' suffix to indicate their purpose, e.g., 'main_test.tf'.

3. Final Answer:

   /main.tf, /variables.tf, /outputs.tf, /tests/main_test.tf -> Option D

4. Quick Check:

   Tests folder with *_test.tf files = correct structure [OK]

Hint: Use 'tests' folder with *_test.tf files [OK]

Common Mistakes:

• Placing tests inside modules folder
• Naming test folder as 'test' instead of 'tests'
• Not using _test suffix for test files

3. Given this Terraform project structure:

/main.tf
/variables.tf
/outputs.tf
/tests/test_main.tf

What will happen if you run terraform apply from the root directory?

medium

A. Terraform will apply infrastructure defined in main.tf and ignore test files

B. Terraform will apply both main.tf and test_main.tf causing errors

C. Terraform will only apply test_main.tf and ignore main.tf

D. Terraform will fail because test files are not allowed

Solution

1. Step 1: Understand Terraform file loading behavior

   Terraform loads *.tf files in the current directory but ignores files in subfolders unless explicitly included.

2. Step 2: Recognize test folder separation effect

   Files inside /tests are not loaded by default during terraform apply, so only main.tf and related files are applied.

3. Final Answer:

   Terraform will apply infrastructure defined in main.tf and ignore test files -> Option A

4. Quick Check:

   Terraform applies root *.tf files only [OK]

Hint: Terraform ignores test folder files by default [OK]

Common Mistakes:

• Assuming terraform applies all .tf files recursively
• Thinking test files run automatically
• Believing terraform apply fails due to test files

4. You have this folder structure:

/main.tf
/variables.tf
/outputs.tf
/tests/test_main.tf

Running terraform apply gives an error about duplicate resource definitions. What is the likely cause?

medium

A. Outputs are missing in outputs.tf

B. Variables are defined twice in variables.tf

C. Terraform is loading test_main.tf and main.tf causing duplicate resources

D. Terraform state file is corrupted

Solution

1. Step 1: Analyze error cause

   Duplicate resource errors usually mean Terraform sees the same resource defined more than once.

2. Step 2: Check file loading

   If test files are accidentally loaded (e.g., by running terraform in /tests), resources duplicate with main.tf definitions.

3. Final Answer:

   Terraform is loading test_main.tf and main.tf causing duplicate resources -> Option C

4. Quick Check:

   Duplicate resources = multiple files loaded [OK]

Hint: Run terraform only in root, not in tests folder [OK]

Common Mistakes:

• Blaming variables or outputs for duplicate resource error
• Ignoring that test files can cause duplicates if loaded
• Assuming state file corruption without checking files

5. You want to reuse infrastructure code in multiple projects and keep tests separate. Which folder structure best supports this using Terraform modules and tests?

hard

A. /modules/network/main.tf, /modules/network/variables.tf, /tests/network_test.tf, /main.tf

B. /network/main.tf, /network/variables.tf, /tests/network_test.tf, /main.tf

C. /modules/network/main.tf, /tests/network/main_test.tf, /main.tf

D. /modules/network/main.tf, /modules/network/tests/network_test.tf, /main.tf

Solution

1. Step 1: Identify module folder best practice

   Modules should be inside a 'modules' folder with their own files for reuse.

2. Step 2: Separate tests outside modules

   Tests should be in a top-level 'tests' folder to avoid mixing with reusable module code.

3. Final Answer:

   /modules/network/main.tf, /modules/network/variables.tf, /tests/network_test.tf, /main.tf -> Option A

4. Quick Check:

   Modules in 'modules', tests in 'tests' folder [OK]

Hint: Keep modules and tests in separate top-level folders [OK]

Common Mistakes:

• Placing tests inside modules folder
• Not using a modules folder for reusable code
• Mixing test files with main project files