AZ-400 Practice Question: Design and implement a source control strategy
Your team is standardizing on Azure Repos for a new project. Developers must be able to work on features in isolation and merge completed work back into the mainline, while keeping the mainline always buildable. Which branching strategy should you recommend as the baseline?
⚠ Common exam trap
The trap here is equating trunk-based development with committing directly to main; isolation still comes from short-lived feature branches merged via pull requests.
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
✓
Feature branches created from and merged back into main through pull requests.
Feature branches give each developer an isolated workspace, and merging back through pull requests to main keeps the trunk reviewed and continuously releasable. This baseline satisfies both the isolation and always-buildable goals while avoiding the overhead of many long-lived branches. Direct commits to main sacrifice isolation, and fork-based or heavy release-branch models add complexity without benefit for this internal team.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A long-lived develop branch with separate release and hotfix branches per environment.
Why it's wrong here
A develop-plus-release-and-hotfix model adds many long-lived branches, which increases merge complexity and drift between environments. It is heavier than needed for a new project seeking a simple, always-buildable mainline. While it can work at scale, it introduces ceremony and merge overhead that conflicts with keeping the baseline simple and continuously integrated.
- ✗
A fork-per-developer model where each developer pushes to a personal fork and never to the shared repository.
Why it's wrong here
Fork-per-developer is common in open-source or external-contributor scenarios where write access is restricted, but it adds synchronization overhead for an internal team that already has shared repository access. It does not inherently keep the mainline buildable any better than feature branches and complicates collaboration. For a normal internal team, it is unnecessary friction.
- ✓
Feature branches created from and merged back into main through pull requests.
Why this is correct
Short-lived feature branches isolate work in progress, and merging back through pull requests keeps the mainline reviewed and buildable. This is the standard trunk-based-with-feature-branches baseline: main stays releasable, developers avoid interfering with each other, and pull request policies enforce quality. It matches both the isolation and always-buildable requirements without unnecessary long-lived branches.
- ✗
A single shared branch where all developers commit directly to main without branches.
Why it's wrong here
Committing directly to main provides no isolation, so incomplete or broken work can immediately destabilize the mainline. It also removes the natural point for pull request review and validation. While trunk-based development encourages frequent integration, direct unreviewed commits to main conflict with the requirement that the mainline remain always buildable and reviewed.
Go deeper
Related to this question
Learn chapter
Source Control Strategy Design
Key term
Azure Repos
Azure Repos is a set of version control tools that allow teams to manage their source code, track changes, and collaborate on software projects using Git or Team Foundation Version Control (TFVC) within the Microsoft Azure ecosystem.
Key term
Feature
A feature is a distinct unit of functionality that delivers value to the user, often managed and tracked throughout the software development lifecycle.
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.