AZ-400 Practice Question: Design and implement a source control strategy
Your organization uses Azure DevOps for a large-scale e-commerce platform. The source code is stored in a single Azure Repos Git repository with over 100 contributors. The current branching strategy is a modified GitFlow with main, develop, release, and hotfix branches. However, the team is experiencing frequent merge conflicts and long integration periods. You have been asked to redesign the branching strategy to support continuous integration and deployment (CI/CD) while ensuring high-quality releases. The new strategy must reduce merge conflicts, enable fast feedback, and support hotfixes. The team uses feature flags to manage incomplete features. Which branching strategy should you recommend?
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
✓
Implement trunk-based development: developers work on short-lived feature branches (less than a day) and merge to main multiple times a day. Use feature flags to control release of incomplete features. Hotfixes are created from main and merged back quickly.
Trunk-based development with short-lived feature branches (less than a day) and frequent merging to main directly addresses the team's merge conflicts and long integration periods. Feature flags allow incomplete features to be merged safely, enabling continuous integration and fast feedback. Hotfixes from main are simple and quick. Option B is wrong because committing directly to main without branches increases risk of breaking the main branch, even with CI, and does not provide isolation for work-in-progress. Option C is wrong because using release branches introduces long-lived branches and delays integration, contrary to the need for fast feedback and continuous deployment. Option D is wrong because GitFlow's long-lived feature and release branches are the root cause of the frequent merge conflicts and integration delays.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implement trunk-based development: developers work on short-lived feature branches (less than a day) and merge to main multiple times a day. Use feature flags to control release of incomplete features. Hotfixes are created from main and merged back quickly.
Why this is correct
Trunk-based development (TBD) with short-lived feature branches merged multiple times per day minimizes merge conflicts because branches diverge for hours, not weeks; feature flags decouple deployment from release, letting incomplete work ship safely behind toggles, and hotfix branches cut from main can be merged and deployed immediately, keeping main always in a releasable state and enabling continuous integration and continuous delivery.
- ✗
Use a single main branch and allow developers to commit directly to main, but require all commits to be small and pass CI. Hotfixes are committed directly to main.
Why it's wrong here
Committing directly to main bypasses pull request code review and branch protection, even if commits are small and CI passes; without a review gate, defects can propagate to production faster, and there is no isolation for work-in-progress, making it risky for large teams where multiple developers' changes interact unexpectedly.
- ✗
Use a single main branch and create release branches from main for each deployment. Feature branches are merged to release branches, and then release branches are merged to main after deployment.
Why it's wrong here
Creating release branches from main for each deployment re-introduces long-lived branches: feature branches merged to release branches then to main creates a two-stage integration that increases merge conflicts and delays, because fixes and features traverse multiple branches before reaching main, violating the single-source-of-truth principle and slowing CI/CD.
- ✗
Continue using GitFlow but enforce stricter branch policies and require more frequent merges.
Why it's wrong here
GitFlow's inherent structure includes long-lived develop and release branches; enforcing stricter policies or more frequent merges treats symptoms but does not eliminate the merge latency and conflict surface that arise from feature branches living days or weeks, whereas trunk-based development with feature flags is the established pattern for large-scale e-commerce CI/CD.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
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.
Key term
Trunk-based development
Trunk-based development is a version control practice where developers integrate small changes frequently into a single main branch, called the trunk, to avoid merge conflicts and enable continuous delivery.
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.