Code review for infrastructure changes in Terraform - Commands & Configuration

Introduction

When you change infrastructure code, you want to check it carefully before applying. Code review helps catch mistakes and ensures the changes are safe and correct.

When you add a new server or resource to your cloud setup

When you update network settings like firewalls or load balancers

When you change storage or database configurations

When you want to avoid accidental downtime from wrong changes

When working in a team to share responsibility and knowledge

Commands

This command sets up Terraform in your project folder. It downloads necessary plugins and prepares the environment for running plans and applies.

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!

This command shows what changes Terraform will make to your infrastructure without applying them. It saves the plan to a file for review and later application.

Terminal

terraform plan -out=tfplan

Expected Output

An execution plan has been generated and is saved to tfplan.



To perform exactly these actions, run the following command to apply:

    terraform apply "tfplan"

→

-out=tfplan - Saves the plan to a file for later use

This command converts the saved plan into a JSON file. This file can be used for detailed code review or automated checks.

Terminal

terraform show -json tfplan > plan.json

Expected Output

No output (command runs silently)

→

-json - Outputs the plan in JSON format

After reviewing the plan, this command applies the changes to your infrastructure exactly as planned.

Terminal

terraform apply tfplan

Expected Output

terraform apply tfplan



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

Key Concept

If you remember nothing else from this pattern, remember: always generate and review a plan before applying infrastructure changes.

Common Mistakes

Running 'terraform apply' without first running 'terraform plan'

You might apply unintended changes that cause downtime or errors.

Always run 'terraform plan' to see what will change before applying.

Not saving the plan to a file and applying directly

You cannot review or reuse the exact plan, risking inconsistent changes.

Use 'terraform plan -out=tfplan' to save the plan and apply it later.

Ignoring the JSON plan output for automated or detailed review

Misses the chance to catch subtle errors or policy violations before applying.

Export the plan to JSON with 'terraform show -json' and review or use tools to analyze it.

Summary

Initialize Terraform with 'terraform init' to prepare your environment.

Generate and save a plan with 'terraform plan -out=tfplan' to see changes.

Export the plan to JSON for detailed review using 'terraform show -json tfplan > plan.json'.

Apply the reviewed plan safely with 'terraform apply tfplan'.

Practice

1. What is the main purpose of running terraform plan before applying changes?

easy

A. To apply the changes directly to the cloud resources

B. To preview the changes Terraform will make to the infrastructure

C. To delete all existing infrastructure

D. To create a backup of the current infrastructure state

Solution

1. Step 1: Understand the role of terraform plan

   This command shows what changes Terraform will perform without making any actual changes.

2. Step 2: Differentiate from other commands

   terraform apply makes changes, while terraform plan previews them safely.

3. Final Answer:

   To preview the changes Terraform will make to the infrastructure -> Option B

4. Quick Check:

   Preview changes = terraform plan [OK]

Hint: Remember: plan previews, apply executes changes [OK]

Common Mistakes:

• Confusing plan with apply
• Thinking plan deletes resources
• Assuming plan creates backups

2. Which of the following is the correct syntax to initialize a Terraform working directory?

easy

A. terraform init

B. terraform start

C. terraform setup

D. terraform configure

Solution

1. Step 1: Identify the initialization command

   terraform init sets up the working directory by downloading providers and preparing backend.

2. Step 2: Verify other options

   Commands like terraform start, terraform setup, and terraform configure do not exist in Terraform CLI.

3. Final Answer:

   terraform init -> Option A

4. Quick Check:

   Initialize = terraform init [OK]

Hint: Init means start setup in Terraform [OK]

Common Mistakes:

• Using non-existent commands
• Confusing init with apply
• Assuming configure is a Terraform command

3. Given this Terraform snippet:

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
}

output "instance_id" {
  value = aws_instance.example.id
}

What will terraform apply output after successful deployment?

medium

A. The ID of the created AWS instance

B. The AMI ID used in the instance

C. The instance type string

D. An error because output is missing

Solution

1. Step 1: Understand the output block

   The output named instance_id returns the ID of the created AWS instance resource.

2. Step 2: Confirm output value

   The value is set to aws_instance.example.id, which is the unique instance ID assigned by AWS.

3. Final Answer:

   The ID of the created AWS instance -> Option A

4. Quick Check:

   Output shows instance ID = The ID of the created AWS instance [OK]

Hint: Output shows resource attributes, not input values [OK]

Common Mistakes:

• Confusing output value with input AMI
• Expecting instance type as output
• Thinking output block is missing or invalid

4. You see this Terraform code snippet in a pull request:

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-unique-bucket-name"
  acl    = "public-read"
}

What is the main concern during code review before applying?

medium

A. The bucket name might not be unique globally

B. The code is missing a region specification

C. The resource type is incorrect for S3 buckets

D. The ACL setting makes the bucket publicly readable, which may be a security risk

Solution

1. Step 1: Analyze the ACL setting

   The ACL is set to public-read, which allows anyone on the internet to read bucket contents.

2. Step 2: Consider security best practices

   Making buckets public can expose sensitive data; this should be reviewed carefully before applying.

3. Final Answer:

   The ACL setting makes the bucket publicly readable, which may be a security risk -> Option D

4. Quick Check:

   Public ACL = security risk [OK]

Hint: Watch for public access settings in code reviews [OK]

Common Mistakes:

• Ignoring security implications of ACL
• Assuming bucket name uniqueness is the main issue
• Thinking region is mandatory in resource block

5. A team wants to share Terraform infrastructure changes for review before applying. Which practice best supports safe collaboration?

hard

A. Send raw Terraform files via email for manual review

B. Run terraform apply directly on the main branch without review

C. Share terraform plan output in a pull request for team feedback

D. Apply changes first, then notify the team

Solution

1. Step 1: Understand collaboration best practices

   Sharing terraform plan output in pull requests allows the team to see proposed changes safely before applying.

2. Step 2: Evaluate other options

   Applying changes without review or sending raw files lacks safety and clarity; notifying after applying is risky.

3. Final Answer:

   Share terraform plan output in a pull request for team feedback -> Option C

4. Quick Check:

   Plan + PR = safe collaboration [OK]

Hint: Use plan output in PRs for safe team review [OK]

Common Mistakes:

• Skipping review before apply
• Sharing raw files without context
• Applying changes before team agreement