AZ-400 Configure processes and communications Practice Question
Your team uses trunk-based development with short-lived feature branches. You notice that code reviews often delay merging because reviewers are not available. What is the best way to reduce review latency while maintaining quality?
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
✓
Encourage pair programming or mob programming to review code in real-time.
Pair programming or mob programming allows code to be reviewed in real-time during development, reducing the need for asynchronous pull request reviews and thus decreasing review latency while maintaining quality. Option A is incorrect because enabling auto-merge does not address reviewer availability; it still requires a review to be completed. Option B is incorrect because requiring only one reviewer may reduce review depth and quality. Option C is incorrect because creating a separate review team can introduce new bottlenecks and does not solve the issue of reviewer unavailability.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable auto-merge for pull requests that have passed all checks.
Why it's wrong here
Auto-merge only automates the merge action once all branch policies are already satisfied—it does not generate or expedite human approval. If two or more reviewers are required and they have not yet approved, the PR still waits indefinitely, so this does not address the actual review bottleneck.
- ✗
Require only one reviewer instead of two.
Why it's wrong here
Dropping the required reviewer count from two to one reduces the minimum number of approvals, but it still leaves the same asynchronous, wait-on-humans model. It shortens the queue only by increasing risk of defects and does not fundamentally remove the delay between submission and review.
- ✗
Create a separate review team that only handles pull requests.
Why it's wrong here
Creating a separate PR review team centralizes review work into a serialized queue, which can become the new bottleneck and strips context from the feature team members who are most familiar with the code. Instead of enabling real-time collaboration, this increases handoffs and waiting time.
- ✓
Encourage pair programming or mob programming to review code in real-time.
Why this is correct
Pair or mob programming embeds code review into the development process itself—another developer is continuously reviewing as the code is written, so there is no separate async review cycle to wait through at merge time. This directly reduces trunk-based development lead time and eliminates PR queue latency.
Go deeper
Related to this question
Learn chapter
Managing Build Quality and Package Dependencies
Key term
Trunk-based development
Trunk-based development is a version control practice where developers integrate small changes frequently into a single main branch, called the trunk, to avoid merge conflicts and enable continuous delivery.
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 823 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 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.