Monorepo vs multi-repo for Terraform - Practice Questions

Challenge - 5 Problems

❓ Architecture

intermediate

Benefits of a Monorepo for Terraform

Which of the following is a key benefit of using a monorepo approach for managing Terraform code?

A Easier to share and reuse modules across projects without duplication

B Complete isolation of environments with no shared state

C Allows each team to use different Terraform versions without conflict

D Simplifies access control by restricting repository permissions per environment

💡 Hint

Think about how code reuse and consistency are affected when all Terraform code is in one place.

A monorepo centralizes Terraform code, making it easier to share modules and maintain consistency. Options B, C, and D describe benefits more aligned with multi-repo setups.

✅ Best Practice

intermediate

Challenges of Multi-Repo Terraform Management

What is a common challenge when using a multi-repo strategy for Terraform code?

A Increased risk of accidental overwrites in a single shared state file

B Difficulty in coordinating changes across multiple repositories leading to drift

C Harder to enforce different access controls per environment

D Limited ability to use Terraform workspaces for environment separation

💡 Hint

Consider how managing many repositories affects synchronization and consistency.

Multi-repo setups can cause coordination issues because changes spread across repos may not be synchronized, causing configuration drift. Options A, B, and C are incorrect.

❓ security

advanced

Access Control in Monorepo vs Multi-Repo

Which statement best describes access control differences between monorepo and multi-repo Terraform setups?

A Multi-repo allows fine-grained access control per environment, while monorepo requires broader permissions

B Monorepo enforces stricter access control by default compared to multi-repo

C Both monorepo and multi-repo require identical access control configurations

D Monorepo prevents unauthorized changes by isolating state files per environment

💡 Hint

Think about how repository boundaries affect who can change what.

Multi-repo setups let teams restrict access to specific repositories, enabling environment-level control. Monorepos usually require broader permissions since all code is together. Options A, B, and D are incorrect or misleading.

❓ service_behavior

advanced

Terraform State Management in Monorepo vs Multi-Repo

How does Terraform state management typically differ between monorepo and multi-repo approaches?

A Multi-repo always uses a single shared state backend for all environments

B Multi-repo cannot use remote state backends

C Monorepo requires manual state file merging across environments

D Monorepo often uses a single shared state backend, while multi-repo uses separate state backends per repo

💡 Hint

Consider how state files are organized and shared in each approach.

Monorepos often centralize state management, using shared backends for easier coordination. Multi-repos typically isolate state per repo to avoid conflicts. Options A, C, and D are incorrect.

🧠 Conceptual

expert

Choosing Between Monorepo and Multi-Repo for Large Terraform Projects

For a large organization with multiple independent teams managing different cloud environments, which approach is generally more scalable and why?

A Monorepo, because it forces all teams to share the same codebase and state, reducing complexity

B Monorepo, because it eliminates the need for version control systems

C Multi-repo, because it allows teams to work independently with isolated codebases and tailored access controls

D Multi-repo, because it requires all teams to use the same Terraform version and modules

💡 Hint

Think about team independence, access control, and codebase isolation.

Multi-repo setups scale better for large organizations by isolating code and permissions per team, reducing conflicts. Monorepos can become complex and harder to manage at scale. Options B, C, and D are incorrect or misleading.

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