AZ-400 Design and implement source control Practice Question
A development team uses Git for source control. They want to enforce a branching strategy where all feature work is done in short-lived branches that are merged to main via pull requests. The team also requires that every commit on main builds successfully. Which TWO practices should the team implement?
⚠ Common exam trap
Watch out — candidates often confuse squash merge (which simplifies history) with a practice that ensures build success, or they mistakenly think allowing direct commits for urgent fixes is acceptable when the requirement explicitly demands every commit on main builds successfully.
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
✓
Configure a branch policy on main that requires a successful build before merging.
Option A configures a branch policy on main that requires a successful build before merging, directly ensuring every commit on main has passed a build. Option C requires at least one approver on all pull requests targeting main, which enforces the code review process as part of the pull request workflow, a key practice for maintaining a healthy branching strategy with short-lived feature branches. Together, these two practices enforce both the build-success requirement and the pull-request-based workflow.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure a branch policy on main that requires a successful build before merging.
Why this is correct
Establishing a branch policy on main that requires a successful build before merging ensures that every pull request targeting main must pass a defined build pipeline as a mandatory gate. Azure DevOps blocks the merge until the build succeeds, preventing broken code from integrating into main and enforcing continuous integration at the point of merge.
- ✗
Use squash merge when completing pull requests to main.
Why it's wrong here
Squash merge is an optional merge strategy that compresses all feature branch commits into a single commit on main, which simplifies history but has no effect on whether the changes are validated. It does not ensure a successful build or perform code review, so it is unrelated to the build validation requirement and may be used only after other policies pass.
- ✓
Require at least one approver on all pull requests targeting main.
Why this is correct
Requiring at least one approver on all pull requests targeting main mandates a human code review before the PR can be completed, ensuring that changes are inspected for quality, correctness, and collaboration. This policy complements build validation by adding a manual quality gate, but it does not replace the need for a successful build check.
- ✗
Create feature branches from main and keep them long-lived for stability.
Why it's wrong here
Keeping feature branches long-lived causes them to diverge significantly from main, leading to large merge conflicts and delayed integration. The recommended practice is to use short-lived feature branches that are merged quickly via pull requests, enabling continuous integration and small, reviewable changes.
- ✗
Allow developers to commit directly to main for urgent fixes.
Why it's wrong here
Direct commits to main bypass the pull request process and any configured branch policies, allowing unreviewed and unvalidated code into the main branch. To protect main, developers should be denied direct push permissions, and even urgent fixes should follow a hotfix branch with a pull request that satisfies build and approval policies.
Go deeper
Related to this question
Learn chapter
Source Control Strategy Design
Key term
Code review
A code review is a systematic examination of source code by one or more developers to find defects, improve quality, and enforce coding standards before it is merged into the main codebase.
Key term
Git
Git is a version control system that tracks changes to files so multiple people can work on the same project without overwriting each other's work.
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.