Code review for infrastructure changes in Terraform - Time & Space Complexity

Time Complexity: Code review for infrastructure changes

O(n)

Understanding Time Complexity

When reviewing infrastructure code changes, it's important to understand how the time to check and apply these changes grows as the code grows.

We want to know: how does the review and apply process scale with the number of resources changed?

Scenario Under Consideration

Analyze the time complexity of reviewing and applying changes for multiple Terraform resources.

resource "aws_instance" "example" {
  count         = var.instance_count
  ami           = var.ami_id
  instance_type = "t2.micro"
}

resource "aws_security_group" "example" {
  count       = var.sg_count
  name        = "example-sg-${count.index}"
  description = "Example security group"
}

This code creates multiple instances and security groups based on input counts.

Identify Repeating Operations

Each resource block triggers API calls to create or update resources.

• Primary operation: API calls to provision or update each resource instance.
• How many times: Once per resource instance, repeated for each count.

How Execution Grows With Input

As the number of instances or security groups increases, the number of API calls grows proportionally.

Input Size (n)	Approx. API Calls/Operations
10	About 10 calls for instances + 10 for security groups = 20
100	About 100 calls for instances + 100 for security groups = 200
1000	About 1000 calls for instances + 1000 for security groups = 2000

Pattern observation: The total operations grow directly with the number of resources defined.

Final Time Complexity

Time Complexity: O(n)

This means the time to review and apply changes grows linearly with the number of resources.

Common Mistake

[X] Wrong: "Reviewing or applying changes takes the same time no matter how many resources are changed."

[OK] Correct: Each resource requires separate API calls and checks, so more resources mean more work and time.

Interview Connect

Understanding how infrastructure changes scale helps you plan and communicate about deployments clearly and confidently.

Self-Check

"What if we used modules to group resources instead of individual resource blocks? How would that affect the time complexity?"

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