AZ-400 Configure processes and communications Practice Question
Your team uses GitHub Flow and wants to enforce that all pull requests require at least one approval before merging to the main branch. Which branch protection rule should you configure?
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
✓
Require a pull request before merging with at least 1 approval
It directly enforces the requirement for at least one approval before merging. 'Require a pull request before merging' must be enabled, and within that, 'Required approvals' should be set to 1. Option A (status checks) verifies CI passes, not approvals. Option B restricts who can push to branches, which is unrelated to approval requirements. Option D (linear history) enforces a linear commit history but does not mandate approvals.
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 status checks to pass before merging
Why it's wrong here
This rule ensures specified CI/CD checks (e.g., build, test, or code analysis) must pass before a merge, but it does not require any human code review or explicit approval. It validates automated quality gates only, leaving the approval process unenforced.
- ✗
Restrict who can push to matching branches
Why it's wrong here
This setting limits which users or teams can push directly to the protected branch, controlling write access rather than the pull request approval workflow. Even with tightened push permissions, you can still merge a PR without any reviewer approval unless an approval rule is separately configured.
- ✓
Require a pull request before merging with at least 1 approval
Why this is correct
This branch protection policy forces all changes to go through a pull request and, when 'Require approvals' is set to 1, prevents merging until at least one eligible reviewer has explicitly approved. It directly creates the desired human review gate before any code is integrated.
- ✗
Require linear history
Why it's wrong here
This option enforces a linear commit history by blocking merge commits and requiring rebase or squash merges, but it says nothing about code review or approvals. It helps maintain a clean history for readability and git bisect, yet does not address the requirement for peer sign-off.
Go deeper
Related to this question
Learn chapter
Source Control Strategy Design
Key term
Pull request
A pull request is a way for a developer to propose changes to a codebase and ask other team members to review and merge them into the main project.
Key term
GitHub
GitHub is a cloud-based platform for storing, tracking, and collaborating on code using Git version control.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.