Monorepo vs multi-repo for Terraform - Hands-On Comparison

Monorepo vs Multi-repo for Terraform

📖 Scenario: You are working as a cloud engineer managing infrastructure as code using Terraform. Your team is deciding how to organize Terraform code: either in a single repository (monorepo) or multiple repositories (multi-repo). This project will guide you through creating simple Terraform configurations to understand the differences between monorepo and multi-repo setups.

🎯 Goal: Build two Terraform configurations: one representing a monorepo setup with multiple modules in one repo, and another representing a multi-repo setup with separate repos for each module. You will create the initial Terraform files, add configuration variables, apply core Terraform logic, and finalize the setup to see how infrastructure is organized differently.

📋 What You'll Learn

Create Terraform configuration files with exact resource names and variables

Use Terraform modules to separate infrastructure components

Configure backend and provider blocks correctly

Demonstrate monorepo and multi-repo structure differences

💡 Why This Matters

🌍 Real World

Organizing Terraform code effectively helps teams manage cloud infrastructure safely and efficiently, especially as projects grow.

💼 Career

Cloud engineers and DevOps professionals often decide between monorepo and multi-repo strategies to balance collaboration, code reuse, and deployment workflows.

1

Create initial Terraform configuration for monorepo

Create a Terraform file named main.tf with a provider block for AWS using region us-east-1. Then create a resource block for an AWS S3 bucket named monorepo-bucket.

Terraform

# Your code here

Hint

Start by defining the AWS provider with the correct region. Then add a resource block for the S3 bucket with the exact name monorepo-bucket.

2

Add a variable for bucket name in monorepo

Create a variable named bucket_name with default value monorepo-bucket in a file named variables.tf. Then update the aws_s3_bucket.monorepo_bucket resource to use this variable for the bucket name.

Terraform

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

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

resource "aws_s3_bucket" "monorepo_bucket" {
  bucket = var.bucket_name
  acl    = "private"
}

# Your code here

Hint

Define the variable with the exact name bucket_name and default value monorepo-bucket. Update the bucket resource to use var.bucket_name.

3

Create a module for S3 bucket in multi-repo setup

Create a new directory named s3_bucket_module. Inside it, create a main.tf file with a resource block for an AWS S3 bucket named multi-repo-bucket. Also create a variable bucket_name with default multi-repo-bucket and use it in the resource.

Terraform

# Create directory s3_bucket_module and inside it create main.tf
# Your code here

Hint

Inside the s3_bucket_module directory, define the S3 bucket resource and variable exactly as specified.

4

Use the S3 bucket module in multi-repo root configuration

In the root main.tf file of the multi-repo setup, add a module block named s3_bucket that uses the local path ./s3_bucket_module. Pass the variable bucket_name with value multi-repo-bucket to the module.

Terraform

# Add module block in root main.tf
# Your code here

Hint

Define the module block with the exact name s3_bucket, source path, and pass the variable as shown.

Practice

1. What is a key advantage of using a monorepo for Terraform code?

easy

A. All Terraform code is stored in one place, making sharing easier

B. Each team works completely independently without any shared code

C. It forces teams to use different Terraform versions per project

D. It automatically splits infrastructure into multiple cloud accounts

Solution

1. Step 1: Understand monorepo concept

   A monorepo stores all Terraform code in a single repository, allowing easy sharing and reuse.

2. Step 2: Compare options

   All Terraform code is stored in one place, making sharing easier correctly describes this advantage. Other options describe multi-repo or unrelated features.

3. Final Answer:

   All Terraform code is stored in one place, making sharing easier -> Option A

4. Quick Check:

   Monorepo = single repo for all code [OK]

Hint: Monorepo means one repo for all Terraform code [OK]

Common Mistakes:

• Confusing monorepo with multi-repo
• Thinking monorepo isolates teams completely
• Assuming monorepo enforces different Terraform versions

2. Which of the following is a correct way to organize Terraform code in a multi-repo setup?

easy

A. Store all Terraform modules and environments in one repository

B. Split Terraform code into separate repositories per environment or team

C. Use a single Terraform state file for all repositories

D. Combine Terraform and application code in the same repository

Solution

1. Step 1: Understand multi-repo structure

   Multi-repo means splitting Terraform code into multiple repositories, often by environment or team.

2. Step 2: Evaluate options

   Split Terraform code into separate repositories per environment or team correctly describes this. Store all Terraform modules and environments in one repository describes monorepo. Use a single Terraform state file for all repositories is incorrect because state files are usually separate per repo. Combine Terraform and application code in the same repository mixes concerns.

3. Final Answer:

   Split Terraform code into separate repositories per environment or team -> Option B

4. Quick Check:

   Multi-repo = multiple repos for Terraform code [OK]

Hint: Multi-repo splits code by team or environment [OK]

Common Mistakes:

• Mixing monorepo and multi-repo definitions
• Assuming one state file for all repos
• Combining unrelated code in Terraform repos

3. Given a monorepo with Terraform code for two environments, what is a likely outcome when running terraform apply in the root directory without specifying a workspace or path?

medium

A. Terraform applies changes only to the default environment

B. Terraform applies changes to both environments at once

C. Terraform throws an error due to multiple state files

D. Terraform automatically detects and applies changes per environment

Solution

1. Step 1: Understand default Terraform behavior in monorepo

   Running terraform apply in root without workspace or path targets the default state and configuration.

2. Step 2: Analyze options

   Terraform applies changes only to the default environment is correct because Terraform applies only the default environment unless configured otherwise. Terraform applies changes to both environments at once is incorrect as Terraform does not apply multiple environments simultaneously by default. Terraform throws an error due to multiple state files is wrong; no error occurs unless misconfigured. Terraform automatically detects and applies changes per environment is false; Terraform does not auto-detect environments.

3. Final Answer:

   Terraform applies changes only to the default environment -> Option A

4. Quick Check:

   Default apply targets one environment [OK]

Hint: Without workspace, Terraform applies default environment only [OK]

Common Mistakes:

• Assuming Terraform applies all environments automatically
• Expecting errors without misconfiguration
• Thinking Terraform auto-detects multiple environments

4. You have a multi-repo Terraform setup but accidentally run terraform apply in the wrong repository. What is the best way to fix this mistake?

medium

A. Delete the entire repository and start over

B. Merge the repositories to avoid confusion

C. Run terraform destroy in that repository to remove unintended resources

D. Ignore it; Terraform will not create any resources without approval

Solution

1. Step 1: Identify the impact of wrong apply

   Running terraform apply in the wrong repo creates resources unintentionally.

2. Step 2: Choose corrective action

   Run terraform destroy in that repository to remove unintended resources is best: running terraform destroy removes those resources safely. Delete the entire repository and start over is extreme and unnecessary. Ignore it; Terraform will not create any resources without approval is wrong; apply creates resources after approval. Merge the repositories to avoid confusion is unrelated to fixing the mistake.

3. Final Answer:

   Run terraform destroy in that repository to remove unintended resources -> Option C

4. Quick Check:

   Destroy removes unintended resources safely [OK]

Hint: Use terraform destroy to undo wrong apply quickly [OK]

Common Mistakes:

• Deleting repos instead of destroying resources
• Ignoring accidental resource creation
• Thinking merging repos fixes mistakes

5. Your team wants to share Terraform modules easily but keep environment configurations isolated. Which approach best balances these needs?

hard

A. Use a monorepo for all code including modules and environments

B. Use a single repo with all environments but duplicate modules in each folder

C. Use multi-repo but copy modules into each environment repo manually

D. Use a multi-repo with one repo for shared modules and separate repos per environment

Solution

1. Step 1: Analyze sharing and isolation needs

   The team wants easy sharing of modules but isolated environment configs.

2. Step 2: Evaluate options for balance

   Use a multi-repo with one repo for shared modules and separate repos per environment fits best: shared modules in one repo, environments isolated in separate repos. Use a monorepo for all code including modules and environments mixes all code, reducing isolation. Use a single repo with all environments but duplicate modules in each folder duplicates modules, causing maintenance issues. Use multi-repo but copy modules into each environment repo manually copies modules manually, risking drift.

3. Final Answer:

   Use a multi-repo with one repo for shared modules and separate repos per environment -> Option D

4. Quick Check:

   Shared modules repo + separate env repos = best balance [OK]

Hint: Share modules in one repo, isolate environments in others [OK]

Common Mistakes:

• Mixing modules and environments in one repo
• Duplicating modules causing maintenance headaches
• Copying modules manually risking drift