Code review for infrastructure changes in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Identify the output of this Terraform resource configuration

Given the following Terraform configuration for an AWS S3 bucket, what will be the value of the bucket's versioning status after applying?

Terraform

resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket"

  versioning {
    enabled = true
  }
}

output "versioning_status" {
  value = aws_s3_bucket.example.versioning[0].status
}

A "Enabled"

B "Suspended"

C "Disabled"

D null

💡 Hint

Check the versioning block and the output value referencing the status attribute.

The versioning block with enabled = true sets the bucket versioning status to "Enabled". The output references this status correctly.

❓ security

intermediate

Detect the security risk in this Terraform IAM policy

Review the following Terraform IAM policy attached to an AWS IAM role. Which option correctly identifies the security risk?

Terraform

resource "aws_iam_role_policy" "example_policy" {
  name = "example_policy"
  role = aws_iam_role.example_role.id

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Action = "*",
        Resource = "*"
      }
    ]
  })
}

A The policy restricts access to only read operations, which is too limited for most roles.

B The policy grants full access to all AWS services and resources, which is overly permissive.

C The policy is missing the Version field, causing it to be invalid.

D The policy only allows access to a single resource, which may cause failures.

💡 Hint

Look at the Action and Resource fields in the policy statement.

The policy uses "Action": "*" and "Resource": "*", granting full permissions, which is a security risk.

❓ Architecture

advanced

Determine the number of subnets created by this Terraform module

This Terraform module creates subnets in multiple availability zones. Given the following snippet, how many subnets will be created?

Terraform

variable "availability_zones" {
  default = ["us-east-1a", "us-east-1b", "us-east-1c"]
}

resource "aws_subnet" "example" {
  count = length(var.availability_zones) * 2
  vpc_id = aws_vpc.example.id
  cidr_block = cidrsubnet(aws_vpc.example.cidr_block, 8, count.index)
  availability_zone = var.availability_zones[count.index % length(var.availability_zones)]
}

A 9

B 3

C 6

D 2

💡 Hint

Look at the count expression and how it relates to availability zones.

The count is length of availability zones (3) times 2, so 6 subnets are created.

❓ service_behavior

advanced

Predict the behavior of this Terraform apply with lifecycle ignore_changes

Given this Terraform resource with lifecycle ignore_changes on tags, what happens if tags are changed manually outside Terraform and then terraform apply is run?

Terraform

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

  tags = {
    Environment = "Production"
  }

  lifecycle {
    ignore_changes = ["tags"]
  }
}

A Terraform will not update or revert tag changes made outside Terraform during apply.

B Terraform will throw an error due to conflicting tag changes.

C Terraform will overwrite tags to match the configuration on every apply.

D Terraform will delete the instance if tags differ.

💡 Hint

Consider what ignore_changes does in lifecycle blocks.

ignore_changes on tags means Terraform ignores any manual tag changes and does not revert them.

✅ Best Practice

expert

Identify the best practice violation in this Terraform state management setup

A team uses local state files for their Terraform project shared by multiple engineers. What is the main risk of this approach?

A Using local state files allows seamless collaboration without additional setup.

B The state file will be encrypted automatically, ensuring security.

C Local state files enable automatic locking to prevent concurrent changes.

D State file conflicts and overwrites can occur, causing infrastructure drift or corruption.

💡 Hint

Think about how Terraform state files are shared and locked.

Local state files do not support locking, so multiple users can overwrite state causing conflicts.

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