AZ-400 Design and implement source control Practice Question
You are a DevOps engineer at a company that develops a cloud-based SaaS application. The application consists of multiple microservices, each stored in its own Git repository within a single Azure DevOps project. The team has grown rapidly, and developers frequently need to make changes that span multiple services. They often complain about the overhead of managing multiple pull requests and coordinating merges across repositories. To improve efficiency, the team lead suggests consolidating all microservices into a single monorepo. However, the lead architect is concerned about the impact on build times, as the CI pipeline currently builds each service independently. You are tasked with designing a source control strategy that reduces cross-repository coordination overhead while maintaining fast, independent builds. You propose using a monorepo with a structure that allows selective building. Which approach should you recommend?
⚠ Common exam trap
Many candidates confuse a monorepo with a monolithic build, assuming all code must be built together, when in fact path filters allow selective building to maintain CI speed.
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
✓
Create a single monorepo with a build pipeline that uses path filters to trigger builds only for changed services
Using a single monorepo with path filters in the build pipeline allows you to trigger builds only for the microservices that have changed, reducing cross-repository coordination overhead while maintaining fast, independent builds. Path filters in Azure Pipelines (e.g., `paths` in YAML) enable selective triggering based on file paths, so unchanged services are not rebuilt, preserving CI efficiency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Keep separate repositories but create a meta-repo that references them as submodules
Why it's wrong here
A meta-repo that references service repositories as submodules does not enable atomic commits across services; each service remains a separate repository with its own history and pull request flow. Whenever a change spans multiple services, you must merge multiple pull requests and update submodule pointers, which can easily leave the meta-repo in a broken intermediate state. The extra layer of indirection adds overhead without resolving the fundamental coordination problem that a monorepo solves.
- ✓
Create a single monorepo with a build pipeline that uses path filters to trigger builds only for changed services
Why this is correct
This allows atomic commits across services, while path filters in the pipeline trigger builds only for changed services, preserving build independence and reducing unnecessary builds. It provides the benefits of a monorepo without the cost of building everything.
- ✗
Keep separate repositories but use Git submodules to share code
Why it's wrong here
Git submodules are designed for pinning a shared dependency to a specific commit, not for coordinating a codebase with multiple independently deployable services. Every shared code update requires a commit in the consuming service, plus a separate submodule pointer update; this creates multiple pull requests and makes atomic cross-service changes impossible. Submodules also complicate CI, as each consumer must check out and authenticate multiple repositories, and the classic "dirty pointer" problem makes branch switching and review unreliable.
- ✗
Create a single monorepo with all services and a single build pipeline that builds everything
Why it's wrong here
A single pipeline without path filters triggers a full build, test, and deployment sequence for every commit to any service, even when the change is isolated to one component. This couples the release cadence of all services, because a failing build in one service blocks the entire pipeline, and it wastes compute and time as the number of services grows. A change to a utility library would unnecessarily rebuild all services, defeating the independence that microservices are meant to provide.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Build pipeline
A build pipeline is an automated sequence of steps that compiles source code into a deployable artifact, running tests and checks along the way.
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.