AZ-400 Practice Question: Design and implement a source control strategy
Which TWO actions should you take to implement Git-based source control for a large enterprise with multiple teams and a single repository (monorepo)? (Select TWO.)
⚠ Common exam trap
AZ-400 often tests the confusion between monorepo best practices and alternative workflows like forking or submodules, which are not suitable for a single repository with multiple teams.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure path-based branch policies
Option D is correct because in a monorepo with multiple teams, path-based branch policies let you scope required reviewers, build validation, and status checks to specific folders or paths, so each team's changes are governed by the right rules without blocking unrelated teams. Option E is correct because a large monorepo produces a huge working tree and history; sparse checkout (git sparse-checkout, often combined with partial clone such as --filter=blob:none) limits the files materialized in the working directory, cutting clone time and disk usage for each developer. Option A is wrong because forcing everyone onto one branch removes isolation and makes concurrent team work and controlled integration impractical. Option B is wrong because submodules are for embedding separate repositories at pinned commits, which fragments the monorepo rather than implementing source control within a single repository. Option C is wrong because a forking workflow creates per-team repository copies, which contradicts the stated single-repository monorepo requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Require all teams to work on a single branch
Why it's wrong here
Requiring all teams to work on a single branch means every commit is intermingled, which inevitably produces frequent merge conflicts and serializes independent releases. This approach destroys the isolation teams need for parallel development in a monorepo and makes it impossible to guarantee that a given change is safe to ship independently.
- ✗
Use Git submodules to separate team code
Why it's wrong here
Using Git submodules to separate team code introduces nested repositories pinned to specific commits, adding significant synchronization overhead and breaking the atomicity of monorepo changes. Submodules make build pipelines more fragile and complicate cross-team refactoring, as a single logical change may require coordinated commits across multiple repositories.
- ✗
Use forking workflow for each team
Why it's wrong here
Forking workflow creates full copies of the repository for each team, which fragments version control history and makes it harder to discover, link, and review pull requests back into the central monorepo. It also duplicates CI/CD infrastructure and complicates permission management, making cross-team collaboration and consistent policy enforcement more difficult.
- ✓
Configure path-based branch policies
Why this is correct
Configuring path-based branch policies in Azure DevOps lets you assign specific reviewers and required checks to changes under particular directories (e.g., src/teamA), so each team enforces its own quality gates while still integrating into a shared trunk. This targets code review and CI to the relevant parts of the monorepo, improving both safety and development velocity.
- ✓
Use sparse checkout to reduce clone time
Why this is correct
Sparse checkout configures the working tree to include only the directories a team actually needs, which dramatically reduces local disk usage and speeds up checkout, status, and branch-switch operations in a large monorepo. Although git still downloads the full object database, sparse checkout makes day-to-day work feel much faster and is a valuable companion to path-based policies.
Go deeper
Related to this question
Learn chapter
Managing Build Quality and Package Dependencies
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
Key term
Repository
A repository is a central storage location where software packages, code, or configuration files are kept, managed, and distributed for use by IT systems.
About these practice questions
One of 696 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.