AZ-400 Configure processes and communications Practice Question
Your company uses GitHub Enterprise for source control and GitHub Actions for CI/CD. The development team is distributed across three time zones. You are designing a process to improve communication and collaboration for code reviews. The team currently uses email notifications for pull request reviews, which often get missed. You want to implement a more efficient system that integrates with Microsoft Teams and provides real-time updates. Additionally, you need to ensure that critical pull requests (e.g., those affecting production) are escalated if not reviewed within 4 hours. You also want to automatically assign reviewers based on the files changed. Which combination of actions should you take?
⚠ Common exam trap
It's easy for candidates to choose Option A because it seems comprehensive, but they overlook that GitHub's built-in code owners feature is the recommended and simpler approach for automatic reviewer assignment, and that a scheduled workflow (cron) is necessary for time-based escalation rather than relying on event-driven triggers.
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
✓
Use GitHub's built-in code owners feature to automatically request reviews based on file patterns. Create a GitHub Action that posts a notification to Microsoft Teams via webhook when a pull request is opened. For escalation, create a scheduled workflow (e.g., using cron) that runs every 30 minutes to identify pull requests older than 4 hours and sends an alert to Teams.
It uses GitHub's built-in code owners feature for automatic reviewer assignment based on file patterns, which is native and requires no third-party app. It then uses a GitHub Action with a webhook to post real-time notifications to Microsoft Teams when a pull request is opened. For escalation, a scheduled workflow (cron) running every 30 minutes checks pull request age and sends an alert to Teams if older than 4 hours, meeting the real-time and escalation requirements without manual intervention.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a GitHub App (e.g., Pull Request Assigner) to automatically assign reviewers based on file patterns. Create a GitHub Action that sends a message to Microsoft Teams via webhook when a pull request is opened. Set up a second GitHub Action that runs every hour and checks pull request age, sending an escalation to Teams if older than 4 hours.
Why it's wrong here
Using a GitHub App like Pull Request Assigner for reviewer assignment can work, but the escalation approach is suboptimal: a separate GitHub Action running every hour introduces unnecessary overhead and a longer detection delay than needed for a 4-hour threshold. A scheduled workflow with a cron expression (e.g., every 30 minutes) would be more efficient and catch aging pull requests sooner, without creating an extra action that consumes CI minutes on a coarse interval. The GitHub App itself also lacks the native file-pattern recognition that CODEOWNERS provides out of the box.
- ✓
Use GitHub's built-in code owners feature to automatically request reviews based on file patterns. Create a GitHub Action that posts a notification to Microsoft Teams via webhook when a pull request is opened. For escalation, create a scheduled workflow (e.g., using cron) that runs every 30 minutes to identify pull requests older than 4 hours and sends an alert to Teams.
Why this is correct
This is the correct approach because CODEOWNERS natively assigns reviewers automatically based on file patterns (e.g., requiring the frontend team for .tsx changes), which is reliable and free. A GitHub Action triggered on pull_request opened sends an immediate webhook notification to Microsoft Teams, giving the team instant visibility. For escalation, a scheduled workflow using cron (e.g., every 30 minutes) queries open pull requests and alerts Teams for any PR older than 4 hours, providing timely detection without constant polling or wasted CI minutes. This combination leverages built-in GitHub features, avoids external services, and ensures stale reviews are automatically escalated.
- ✗
Configure GitHub branch protection rules to require pull request reviews. Create a Microsoft Teams webhook connector and add it to the repository to post notifications. Instruct team leads to manually tag reviewers based on file changes.
Why it's wrong here
Enforcing branch protection to require reviews is a good guardrail, but this option fails to address reviewer assignment and escalation. Adding a Microsoft Teams webhook connector to the repository only enables outbound notifications; it does not assign reviewers or track pull request age. Manually tagging team leads based on file changes is error-prone and does not scale, and with no automated escalation, stale pull requests could sit indefinitely until a human notices. This option lacks both the automatic assignment and the time-based alerting needed for a robust review workflow.
- ✗
Use a third-party service like PullRequest.com to manage code reviews. Configure GitHub Actions to send notifications to Teams. For escalation, use a GitHub Action that triggers on pull request review request and uses conditional logic to escalate after 4 hours.
Why it's wrong here
Integrating a third-party service like PullRequest.com introduces unnecessary cost, extra complexity, and an external dependency for what can be handled entirely within GitHub and Teams. The escalation workflow is fundamentally flawed: it triggers on the pull_request review_requested event, meaning it will not fire if no review request is ever made, so unassigned or never-requested pull requests will never be escalated. Even after a request, the conditional logic to wait 4 hours runs from that event and may not account for the total age of the PR, leaving gaps in escalation coverage.
Go deeper
Related to this question
Learn chapter
Source Control Strategy Design
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.
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.
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.