Code review for infrastructure changes in Terraform - Step-by-Step Execution

Process Flow - Code review for infrastructure changes

Developer writes Terraform code

↓

Developer runs 'terraform plan'

↓

Reviewers examine plan output

↓

Reviewers provide feedback

↓

Approve changes

↓

Developer applies

Shows the flow from writing code, planning changes, reviewing, and either approving or requesting updates before applying.

Execution Sample

Terraform

terraform plan
# Shows proposed infrastructure changes
# Reviewers check for errors or risks
terraform apply
# Applies approved changes

This simulates the process of planning and applying infrastructure changes with review steps.

Process Table

Step	Action	Input/Condition	Output/Result	Next Step
1	Developer writes Terraform code	New feature or fix needed	Terraform code ready	Run 'terraform plan'
2	Run 'terraform plan'	Terraform code	Plan output showing changes	Review plan output
3	Review plan output	Plan output	Feedback: Approve or Request changes	If approve -> apply; else -> update code
4	If changes requested	Feedback to developer	Developer updates code	Back to step 2
5	If approved	Approval given	Run 'terraform apply'	Apply changes
6	Run 'terraform apply'	Approved plan	Infrastructure updated	End
7	End	Infrastructure updated	Process complete	None

💡 Process ends after infrastructure is updated successfully.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
Terraform Code	None	Written	Unchanged	May be updated	Updated if requested	Final version	Applied
Plan Output	None	None	Generated	Reviewed	Regenerated if updated	Final approved	None
Review Feedback	None	None	None	Approve or Request	May change	Approved	None
Infrastructure State	Current	Current	Current	Current	Current	Updated	Updated

Key Moments - 3 Insights

Why do we run 'terraform plan' before applying changes?

Because 'terraform plan' shows what changes will happen without making them, so reviewers can check for mistakes or risks before anything is applied. See execution_table step 2 and 3.

What happens if reviewers request changes after seeing the plan?

The developer updates the Terraform code and runs 'terraform plan' again to generate a new plan for review. This loop continues until approval. See execution_table steps 3 and 4.

Can we apply changes without review?

Best practice is to always review the plan output before applying to avoid unintended changes. Skipping review risks errors. See execution_table step 3.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output after running 'terraform plan'?

A Plan output showing changes

B Terraform code ready

C Infrastructure updated

D Feedback: Approve or Request changes

💡 Hint

Check execution_table row with Action 'Run terraform plan' (Step 2) for output.

At which step does the developer update the Terraform code after feedback?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look for the step where 'Developer updates code' happens in execution_table.

If the developer skips review and applies changes immediately, which step is missed?

A Step 5

B Step 2

C Step 3

D Step 6

💡 Hint

Review happens at 'Review plan output' step in execution_table.

Concept Snapshot

Code review for infrastructure changes:
1. Write Terraform code.
2. Run 'terraform plan' to see proposed changes.
3. Review plan output carefully.
4. Provide feedback: approve or request changes.
5. Apply changes only after approval.
This prevents errors and ensures safe updates.

Full Transcript

This visual execution shows how infrastructure changes are managed with Terraform code review. First, the developer writes code and runs 'terraform plan' to generate a preview of changes. Reviewers then examine this plan to catch errors or risks. They either approve or request changes. If changes are requested, the developer updates the code and repeats the plan and review steps. Once approved, the developer runs 'terraform apply' to update the infrastructure. This process ensures safe, controlled infrastructure updates.

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