L5. Pull Request Workflows: Branch Policies & Protection Rules

Branch Policies and Protection Rules

Every modern source control system lets you enforce rules on which code can merge to a protected branch. Azure Repos calls these branch policies. GitHub calls them branch protection rules. They serve the same purpose: preventing code from reaching main (or another critical branch) without meeting quality gates.

Azure Repos Branch Policies

Azure Repos branch policies can enforce:

• Minimum number of reviewers (1, 2, or more)
• Linked work items required (every PR must reference a work item)
• Successful build validation (a specific pipeline must pass)
• Comment resolution required (all PR comments must be resolved before merge)
• Blocking direct pushes (enforces code review via PR, no bypassing)
• Automatic reviewer suggestion based on a CODEOWNERS file

Once configured, a PR cannot merge until all policies pass. Policies are configured per branch pattern, so you might require 2 reviewers for main but 1 reviewer for develop.

GitHub Branch Protection Rules

GitHub branch protection rules offer similar enforcement:

• Required pull request reviews (minimum number)
• Required status checks (specific build, test, or security pipelines)
• Dismiss stale PR approvals when new commits are pushed
• Require signed commits (cryptographic verification of commit identity)
• Require linear history (no merge commits, only rebase)
• Restrict push and merge permissions to specific users or teams

Build Validation: The Critical Policy

Build validation ties a specific pipeline to a branch policy. When you set up build validation, the policy does not just run the pipeline on the PR source branch; it runs the pipeline on the merge result (source branch merged into target). This is crucial because it tests whether the code works when merged, not just in isolation.

If build validation is missing, a PR could pass all tests in isolation but break the build after merging to main because of conflicts or incompatibilities with main's current state.

CODEOWNERS: Automatic Reviewer Assignment

A CODEOWNERS file maps file paths to owners. When a PR touches files, GitHub (and similar systems) automatically request review from the designated owner:

# Example CODEOWNERS file
/src/auth/*         @security-team
/docs/*             @tech-writer
/infra/terraform/*  @platform-team

This removes the manual step of figuring out who should review. The system routes PRs to the right people based on what changed.

The Admin Bypass Trap

Here is the exam trap: branch policies and protection rules do not automatically apply to repository administrators unless the setting explicitly includes admins in enforcement. This is a security misconfiguration that appears frequently on the AZ-400 exam.

A team sets up "require 2 reviewers and passing build" but forgets to enable "enforce for administrators." An admin can then bypass both requirements and merge directly to main, defeating the entire policy.

Merge Strategies

The way code merges affects history. Common strategies include:

Exam tip: The AZ-400 exam often tests the admin bypass misconfiguration and the relationship between build validation policies and protecting merge results (not just source branches).