What's changed: Deepened AZ-400 Chapter 2 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
2.2Pull Requests and Code Review
Understand quality gates—pull requests (PRs), branch policies, required reviewers/build validation, and work item linking. Integrate only changes that pass review and automated checks.
The PR is the quality gate before integration. Branch policies enforce required reviews and build validation to block bad changes.
2.2.1PRs and branch policies
- Pull request: a mechanism to review changes before integrating to main.
- Branch policy: protect main, enforcing required reviews/build validation/comment resolution.
- Build validation: run CI on PR trigger, requiring passing tests to merge.
- Work item linking: require linking work items to PRs for traceability.
Common on AZ-400: protect main = branch policy, run CI before merge = build validation, required reviewers, required work item links, required comment resolution. Forbidding direct pushes and forcing PRs ensures quality and traceability.
Use required reviewers (CODEOWNERS-style) to auto-require review of critical paths, and draft PRs for early feedback.
AZ-400 probes designing "protect main and ensure quality and traceability via automated checks and human review." Branch policies combine multiple required conditions on protected branches (e.g., main): minimum reviewers (exclude your own vote, reset approvals on new pushes), required reviewers / path-based required review (specific directories require specific teams’ approval = CODEOWNERS-equivalent), build validation (PR-triggered CI must pass to merge), required work item links, required comment resolution, and merge type limits (e.g., force squash). Direct pushes are forbidden; changes always go through PRs. Status checks integrate external quality gates (SonarQube, vulnerability scans, signature verification), auto-complete merges when conditions are met, and draft PRs provide early feedback. As review culture, small PRs, clear descriptions, and delegating automatable checks to machines so humans focus on design/intent are efficient. These lower DORA change failure rate while work item links establish requirement→deployment traceability. The key is to apply "forbid direct push + require PR + build validation + required review + work item link" to protected branches.
| Policy | Effect | Key point |
|---|---|---|
| Required reviewers | Enforce human approval | Min count; path-based (CODEOWNERS) |
| Build validation | Require CI success to merge | Run tests on PR trigger |
| Required work item link | Ensure traceability | Tie requirement ↔ change |
| Comment resolution / merge type | Complete review; shape history | Block unresolved; force squash |
Scenario: Unreviewed, untested code lands directly on the production branch, causing frequent incidents. → Set a branch policy on main: forbid direct push and require PRs, require build validation (CI build + tests pass), at least 2 reviewer approvals, required work item links, and required comment resolution. For critical infra paths, require the platform team’s approval via path-based required review. This lowers change failure rate and makes each change’s requirement traceable.
FAQ: Build validation vs release gates? Build validation runs CI at the PR stage (before integration), requiring passing tests to merge—a "shift-left" quality gate. Release gates check approvals or external conditions (monitoring health, change management) at the deployment stage (within the release pipeline)—a right-side gate. Build validation on PRs; release gates before production deploy—different stages.
Exam trap: Trying to "protect main" with role permissions (RBAC) alone is insufficient—restricting who can push does not enforce review or tests. Branch policies (required reviews + build validation + work item links) are the answer. Also configure reviewer policy to "exclude the requestor’s vote" so you cannot approve your own PR.
2.2.2Section summary
- Quality gate = PR + branch policy
- Merge conditions = build validation + required reviews + work item links
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Forbid direct pushes to main and require PRs with review for integration. What?
Q2. Before merging a PR, you want CI build/tests run automatically and required to pass. What?
Q3. Require each PR to link a work item so change reasons are traceable. What?