Preventing Broken Merges with Required Status Check Branch Protection
A development team is using Git for source control. They have a main branch that should always be deployable. Developers work on feature branches and create pull requests to merge into main. Recently, a feature branch with incomplete work was accidentally merged into main, causing build failures. What is the best Git branch strategy to prevent this in the future while maintaining fast feedback?
Quick Answer
Requiring status checks — the CI build and test suite — to pass before a pull request can merge into main is the direct fix: it blocks any PR whose code doesn't build or pass tests from ever reaching main, while still letting the CI pipeline give developers fast feedback on every push.
⚠ Common exam trap
Watch out — candidates often confuse process controls (like requiring pull requests or code reviews) with automated quality gates (like status checks), mistakenly believing that human review alone is sufficient to catch all integration issues.
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 branch protection on main to require status checks (CI build and tests) to pass before merging.
Configuring branch protection on main to require status checks (CI build and tests) to pass before merging directly prevents incomplete or broken code from being merged. This enforces that every pull request must pass automated validation, ensuring main remains deployable while still allowing fast feedback through the CI pipeline.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Require at least one code reviewer approval for all pull requests into main.
Why it's wrong here
Manual reviews may miss integration issues and do not enforce automated checks.
- ✓
Configure branch protection on main to require status checks (CI build and tests) to pass before merging.
Why this is correct
This ensures that only branches with passing builds and tests can be merged into main.
- ✗
Adopt a GitFlow-like branching model with a separate release branch for stable code.
Why it's wrong here
This adds complexity but does not prevent merging incomplete feature branches into main directly.
- ✗
Disable direct pushes to main and enforce all merges through pull requests.
Why it's wrong here
This alone does not prevent merging a failing feature branch; PRs can still merge incomplete code.
- ✗
Require a linear history on main by enabling 'Rebase and merge' for all pull requests.
Why it's wrong here
Linear history does not enforce quality checks; it only affects commit history.
Go deeper
Related to this question
Learn chapter
Source Control Strategy Design
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
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 →
Same concept, more angles
1 more way 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 team follows trunk-based development. The main branch should always be deployable. Which two practices must you implement? (Choose two.)
easy- A.Require manual approval for every pull request.
- ✓ B.Use feature flags to manage incomplete work.
- ✓ C.Keep branches short-lived (less than a day).
- D.Create release branches for each deployment.
- E.Use long-lived feature branches for each feature.
Why B: In trunk-based development, the main branch must always be deployable. Feature flags (B) allow incomplete or work-in-progress code to be merged into the main branch without affecting production behavior, because the new functionality is toggled off until ready. Keeping branches short-lived (C) (typically less than a day) minimizes merge conflicts and ensures that changes are integrated quickly, reducing the risk of long-lived divergence that could break the main branch.
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.