Question 530 of 823
Reducing Merge Conflicts in a Monorepo with Trunk-Based Development
Your team uses a monorepo in Azure Repos with multiple microservices. Developers frequently report merge conflicts due to long-lived feature branches. Which branching strategy minimizes merge conflicts while supporting continuous integration?
Quick Answer
Trunk-based development with short-lived feature branches merged frequently into main is what actually shrinks merge conflicts in a monorepo — the shorter each branch lives, the less its code diverges from everyone else's before merging back. It also plays well with continuous integration, since every frequent merge to main can trigger an automated build and test run for fast feedback.
⚠ Common exam trap
The trap here is that candidates often associate GitFlow (Option B) with structured branching and mistakenly believe it reduces conflicts, but in reality, its long-lived feature branches increase conflict frequency and hinder continuous integration, making trunk-based development (Option D) the correct choice for minimizing conflicts and supporting CI.
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 trunk-based development with short-lived feature branches and frequent merges to main
Trunk-based development with short-lived feature branches (typically lasting less than a day) minimizes merge conflicts by ensuring that changes are integrated into the main branch frequently, often multiple times per day. This approach reduces the divergence between branches, making conflicts less likely and easier to resolve. It also supports continuous integration by triggering automated builds and tests on every merge to main, aligning with the team's need for rapid feedback and reduced integration overhead.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use release branches for all development work and merge to main only at release time
Why it's wrong here
Release branches are for stabilization, not daily development.
- ✗
Use GitFlow with separate develop and main branches, and long-lived feature branches
Why it's wrong here
GitFlow with long-lived feature branches increases merge conflicts.
- ✗
Use a forking workflow where each developer works in a personal fork and submits pull requests
Why it's wrong here
Forking is intended for external contributions, not internal team collaboration.
- ✓
Use trunk-based development with short-lived feature branches and frequent merges to main
Why this is correct
Trunk-based development minimizes conflicts by integrating small changes often.
Visual reference
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Your organization is adopting a trunk-based development strategy with short-lived feature branches. Which branch policy should you enforce to ensure that code is integrated frequently and conflicts are minimized?
easy- A.Allow direct pushes to main branch for senior developers
- ✓ B.Require a minimum number of reviewers and enforce a squash merge strategy
- C.Create release branches for each production deployment
- D.Require all merges to be fast-forward only
Why B: In a trunk-based development strategy with short-lived feature branches, the goal is to integrate code frequently and minimize merge conflicts. Requiring a minimum number of reviewers ensures code quality and team awareness, while enforcing a squash merge strategy collapses all feature branch commits into a single commit on the main branch, keeping the history linear and clean. This approach reduces the risk of complex merge conflicts and supports continuous integration by encouraging small, frequent merges.
Variation 2. Your team uses Git with a trunk-based development strategy. They want to ensure that all code changes are integrated into the main branch at least once a day, and that branch lifetimes are short. Which practice best supports this?
easy- A.Developers use GitFlow with develop and feature branches, merging to develop daily and to main at release.
- B.Developers commit directly to a release branch, and then the release branch is merged to main at the end of the sprint.
- C.Developers work on long-lived feature branches and merge to main only after all features are complete.
- ✓ D.Developers work on short-lived feature branches (less than a day) and merge to main via pull requests after successful CI.
Why D: Trunk-based development emphasizes short-lived feature branches (typically less than a day) that are merged into the main branch via pull requests after passing continuous integration (CI) checks. This ensures all code changes are integrated at least daily, keeping branch lifetimes short and reducing merge conflicts.
Last reviewed: Jun 25, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.