Code review for infrastructure changes in Terraform - Mini Project: Build & Apply

Code Review for Infrastructure Changes with Terraform

📖 Scenario: You are part of a cloud team managing infrastructure using Terraform. Before applying any changes, you need to review the Terraform configuration files carefully to ensure they follow best practices and meet the project requirements.This project will guide you through creating a simple Terraform configuration, adding variables for flexibility, writing the main resource block, and finally adding output to review the infrastructure state.

🎯 Goal: Build a Terraform configuration step-by-step that defines an AWS S3 bucket with a variable for the bucket name, includes a resource block to create the bucket, and outputs the bucket ARN for review.

📋 What You'll Learn

Create a Terraform variable for the S3 bucket name

Define an AWS S3 bucket resource using the variable

Add an output block to display the bucket ARN

Use valid Terraform syntax and best practices

💡 Why This Matters

🌍 Real World

Terraform is widely used to manage cloud infrastructure as code. Reviewing configuration files carefully before applying changes helps prevent mistakes and ensures infrastructure is created as intended.

💼 Career

Cloud engineers and DevOps professionals regularly write and review Terraform code to manage infrastructure safely and efficiently. This project builds foundational skills for those roles.

1

Create a Terraform variable for the S3 bucket name

Write a Terraform variable block named bucket_name with type string and default value "my-unique-bucket-12345".

Terraform

# Define a variable for the S3 bucket name
# Your code here

Hint

Use the variable block with type and default attributes.

2

Add a provider configuration for AWS

Add a Terraform provider block for aws with region set to us-east-1.

Terraform

variable "bucket_name" {
  type    = string
  default = "my-unique-bucket-12345"
}

# Add AWS provider configuration below
# Your code here

Hint

The provider block specifies which cloud provider and region Terraform will use.

3

Define an AWS S3 bucket resource using the variable

Create a Terraform resource block named aws_s3_bucket with resource name my_bucket. Set the bucket attribute to use the variable bucket_name.

Terraform

variable "bucket_name" {
  type    = string
  default = "my-unique-bucket-12345"
}

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

# Define the S3 bucket resource below
# Your code here

Hint

Use resource "aws_s3_bucket" "my_bucket" and set bucket = var.bucket_name.

4

Add an output block to display the bucket ARN

Add a Terraform output block named bucket_arn that outputs the ARN of the S3 bucket resource aws_s3_bucket.my_bucket.arn.

Terraform

variable "bucket_name" {
  type    = string
  default = "my-unique-bucket-12345"
}

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

resource "aws_s3_bucket" "my_bucket" {
  bucket = var.bucket_name
}

# Add output block for bucket ARN below
# Your code here

Hint

The output block helps you see important information after Terraform applies changes.

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