AZ-400 Practice Question: Design and implement a source control strategy
Which THREE practices are recommended for effective source control in a GitHub monorepo? (Choose three.)
⚠ Common exam trap
Watch out — candidates often confuse 'monorepo best practices' with 'single repo simplicity' and incorrectly assume a single build definition is efficient, when in reality path-filtered, modular CI is essential to avoid unnecessary builds and long feedback loops.
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
✓
Use branch protection rules to enforce CI checks
Branch protection rules (B) enforce required status checks like CI builds and tests before merging, maintaining stability in a monorepo with many contributors. Code owners (D) automatically request reviewers from the responsible teams for changes in their respective paths, ensuring proper review and accountability. Path filters (E) trigger only the CI workflows relevant to the changed code, avoiding unnecessary builds and reducing feedback loops. Storing large binaries in the repo (A) is poor practice, and a single build definition for all projects (C) is inefficient because it forces full builds on every change.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store large binary files directly in the repository
Why it's wrong here
Git repositories store full history of every blob; adding large binaries permanently inflates repo size, making clones and fetches slow for every team member, and can hit storage limits. Use Git LFS or external artifact storage instead.
- ✓
Use branch protection rules to enforce CI checks
Why this is correct
Branch protection rules prevent direct pushes to main and require pull requests to pass required status checks (e.g., CI pipeline) before merging, enforcing quality gates and reducing regressions.
- ✗
Use a single build definition for all projects
Why it's wrong here
A single monolithic build definition forces every project to build on every change, creating long pipelines, unrelated failures, and slow feedback; instead, use separate build definitions or multi-job pipelines with path filters to build only what changed.
- ✓
Use code owners to automatically request reviewers
Why this is correct
CODEOWNERS files let you define which individuals or teams own specific paths, so Azure DevOps automatically requests their review on PRs touching those paths, ensuring the right expertise approves changes.
- ✓
Use path filters to trigger only relevant CI workflows
Why this is correct
Path filters in CI triggers (e.g., include/exclude for directories or file types) allow pipelines to run only when changes affect relevant code, reducing unnecessary builds and resource consumption while preserving fast feedback.
Go deeper
Related to this question
Learn chapter
Source Control Strategy Design
Key term
GitHub
GitHub is a cloud-based platform for storing, tracking, and collaborating on code using Git version control.
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.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.