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
Reviewer approval is a human judgement gate and does not verify that the branch compiles or passes tests, so incomplete work can still merge. It is tempting because peer review catches design and logic defects, and it is the right control when the risk is poor code quality rather than broken builds.
- ✓
Configure branch protection on main to require status checks (CI build and tests) to pass before merging.
Why this is correct
Branch protection blocks merges to main until required status checks — the CI build and tests — pass, so incomplete feature work cannot land and break the deployable main. This directly prevents the accidental merge while keeping fast feedback through pull requests.
- ✗
Adopt a GitFlow-like branching model with a separate release branch for stable code.
Why it's wrong here
A separate release branch delays integration and adds merge overhead, slowing the fast feedback the team needs; main still receives unreviewed merges. It is tempting because GitFlow suits scheduled releases with multiple supported versions, where stabilisation branches genuinely separate shipped code from development.
- ✗
Disable direct pushes to main and enforce all merges through pull requests.
Why it's wrong here
Pull requests alone do not block a merge when the branch is incomplete; without a branch policy requiring a successful build validation, the PR can still complete. It is tempting because PRs provide review and audit trails, and this is the correct first step when no review process exists at all.
- ✗
Require a linear history on main by enabling 'Rebase and merge' for all pull requests.
Why it's wrong here
Rebase and merge rewrites commits onto main but does not verify that the branch's build or tests passed before merging, so incomplete work still lands. It is tempting because linear history aids bisecting and rollback, which suits teams prioritising clean commit graphs over gated validation.
Go deeper
Related to this question
Learn chapter
Designing a Build Pipeline
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 — 696 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.