3.3 Branch Policies, Quality Gates & Compliance Restrictions

3.3 Branch Policies, Quality Gates & Compliance Restrictions

Quick Summary: Branch policies in Azure Repos and Branch Rulesets in GitHub represent the automated compliance frontier in modern DevOps. They enforce segregation of duties, automated build and security verification, work item traceability, and code review consensus before any change can touch production-critical branches. In Exam AZ-400, mastery of build validation triggers, path-filtered automatic reviewers, and emergency bypass administration is critical.

---

The Architecture of Server-Side Enforcement

In Git, developers have unrestricted administrative control over their local repositories. They can rewrite history, amend commits, skip local hooks using git commit --no-verify, or delete local branches. Therefore, client-side Git hooks cannot be relied upon for organizational governance or security compliance.

Enterprise compliance requires server-side enforcement mechanisms managed by the Git host (Azure Repos or GitHub). When a developer executes git push, the remote server intercepts the reference update and validates it against active branch policies before writing to the object database.

Server-Side Enforcement Boundary:

[Developer Client]                   [Azure Repos / GitHub Server Boundary]
 git commit --no-verify  ──(push)──► [Branch Policy Interceptor]
 (Bypasses local hooks)                 ├── Check: Direct push allowed? (DENY)
                                        ├── Check: Min 2 reviewers approved?
                                        ├── Check: Submitter self-approved? (DENY)
                                        ├── Check: New push since last vote? (RESET VOTES)
                                        ├── Check: Build validation pipeline passed?
                                        ├── Check: External SonarQube quality gate passed?
                                        └── Check: Work items linked & comments resolved?
                                        │
                                        ├── All Passed ──► Commit Written to Main
                                        └── Any Failed ──► Merge Blocked

---

Deep Dive: Azure Repos Branch Policies

Branch policies in Azure DevOps are configured under Project Settings > Repositories > [Select Repository] > Policies > Branch Policies > [Select Branch, e.g., main].

+-----------------------------------------------------------------------------+
| Azure Repos Branch Policy Configuration Panel (`refs/heads/main`)          |
+-----------------------------------------------------------------------------+
| [x] Require a minimum number of reviewers: [ 2 ]                            |
|     [ ] Allow requestors to approve their own changes (DISABLED FOR SOX)   |
|     [x] Prohibit the most recent pusher from approving their own changes   |
|     [x] Reset code reviewer votes when there are new changes                |
|                                                                             |
| [x] Check for linked work items: [ Required ]                               |
| [x] Check for comment resolution: [ Required ]                              |
| [x] Limit merge types: [x] Squash merge                                     |
|                                                                             |
| Build Validation:                                                           |
|   + Pipeline: 'Core-API-PR-Validation'                                     |
|   + Path filter: '/src/api/*'                                               |
|   + Trigger: Automatic  |  Requirement: Required                            |
|   + Build expiration: Immediately when main is updated                      |
|                                                                             |
| Automatically Included Reviewers:                                           |
|   + Reviewer: '[Project]\Infra-Admins'  | Required: True                    |
|   + Path filter: '/infra/bicep/*'                                           |
+-----------------------------------------------------------------------------+

1. Reviewer Requirements & Segregation of Duties

• Minimum Number of Reviewers: Sets the numeric threshold of approvals required (e.g., at least 2 team members).
• Allow Requestors to Approve Their Own Changes: When this box is checked, the author of the PR can approve their own changes, counting toward the threshold. For regulatory compliance (SOX Section 404, ISO 27001, PCI-DSS), this setting MUST be DISABLED. Enabling self-approval violates the "Four-Eyes Principle" (segregation of duties).
• Prohibit the Most Recent Pusher from Approving: Prevents a reviewer from committing changes to a PR branch and then approving the PR themselves.
• Reset Code Reviewer Votes When There Are New Changes: Critical security setting. If Reviewer A approves a PR, and the developer subsequently pushes an additional commit to the PR branch (even a minor fix or formatting tweak), all prior approval votes are automatically reset to Waiting. This prevents the "approval bait-and-switch" vulnerability, where malicious or untested code is injected after approvals are captured.

2. Traceability: Check for Linked Work Items

• Requirement Setting: Can be set to Required or Optional.
• When set to Required, the PR cannot be completed unless it is linked to at least one Azure Boards work item (User Story, Bug, or Feature).
• Auditing Impact: Enforces end-to-end traceability from business requirement to production commit. In an audit, teams can trace any commit on main back through its PR to the exact approved Azure Boards work item.

3. Check for Comment Resolution

• When enabled as Required, the PR merge button is disabled as long as any discussion comment left by a reviewer remains in an Active or Pending state.
• The author or reviewer must resolve every thread (Resolved, Closed, or Won't Fix) before completion is permitted.

4. Limit Merge Types Allowed

• Prevents repository history pollution by restricting the merge strategies available in the PR completion modal.
• Administrators select permitted options: Basic merge (--no-ff), Squash merge (--squash), Rebase and fast-forward, or Semi-linear merge.
• Exam Pattern: If an organization mandates Trunk-Based Development, administrators check Squash merge only.

5. Build Validation (Automated CI Quality Gate)

Build validation automatically triggers an Azure Pipelines build whenever a PR is created or updated.

• Build Pipeline: The target pipeline containing unit tests, linting, build packaging, and static analysis.
• Trigger Criteria:
  • Automatic: Queues immediately upon PR creation or new commit push.
  • Manual: Must be queued manually by a reviewer (used for expensive, long-running end-to-end test suites).
• Policy Requirement: Required (blocks merge if failed) vs. Optional (reports status without blocking).
• Build Expiration Rules (Crucial Exam Concept):
  • Immediately when <branch> is updated: If another developer merges a different PR into main, the validation build for the current PR immediately expires and becomes invalid. The build must re-run against the newly updated target to ensure no semantic merge conflicts exist.
  • After <n> hours if <branch> has been updated:
  • Never:
• Path Filtering: Scopes the pipeline trigger to specific file patterns using Git globbing. For example, in a monorepo containing /src/api and /src/web, setting a path filter of /src/api/* ensures the backend validation build only runs when backend code is modified, preventing unnecessary pipeline resource consumption when frontend code or /docs are updated.

6. Automatically Included Reviewers & Path-Based Approvals

Allows administrators to automatically attach designated teams to a PR review based on the files modified:

• Path Filter Scoping: You specify file patterns (e.g., /infra/terraform/*, *.bicep, /src/auth/*).
• Requirement: Can be configured as Required (their sign-off is mandatory regardless of the minimum reviewer count) or Optional.
• Realistic Scenario: Changes to database migration scripts under /src/database/migrations/* automatically add the [Project]\Database-Admins group as a Required reviewer, while front-end changes bypass the DBA team.

7. External Status Checks & Webhooks

External security and quality analysis engines (e.g., SonarQube, Snyk, Mend, Checkmarx) communicate validation statuses back to Azure Repos via the REST API:

POST https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=7.1
Content-Type: application/json

{
  "state": "succeeded",
  "description": "SonarQube Quality Gate passed: 0 vulnerabilities, 0 bugs",
  "context": {
    "name": "sonarqube/quality-gate",
    "genre": "continuous-integration"
  }
}

Under Status Checks, administrators add sonarqube/quality-gate as a Required policy. Even if human reviewers approve and the build validation pipeline succeeds, if the SonarQube quality gate fails (posting a state of failed), Azure Repos blocks the merge.

---

Repository Permissions & Emergency "Break-Glass" Administration

Azure Repos uses an Access Control List (ACL) security model for Git repositories:

Azure Repos Git Permission Hierarchy:

[Project Level Permissions] ──► [Repository Level Permissions] ──► [Branch Level Permissions]

Key Branch Permissions for `refs/heads/main`:
├── Read:                                Allow
├── Contribute:                          Allow (Can contribute via PR)
├── Create branch:                       Allow
├── Manage branch policies:              Deny  (Project Administrators only)
└── Bypass policies when completing PR:  Deny  (EXCEPT Break-Glass Security Group)

The Break-Glass Emergency Protocol

In a severe production outage (P1 incident), a critical hotfix may need to be merged immediately when the primary CI build validation pipeline is broken or when designated reviewers are unavailable.

• The Risk: Granting developers the ability to bypass branch policies creates severe compliance violations and invites unauthorized code pushes.
• The AZ-400 Solution:
  1. Create a dedicated security group in Microsoft Entra ID / Azure DevOps named [Project]\Break-Glass-Admins.
  2. Explicitly set Bypass policies when completing pull requests: Allow exclusively for this security group on the main branch.
  3. Set this permission to Deny or Not Set for all other contributor and team groups.
  4. Membership in Break-Glass-Admins must be tightly restricted (e.g., via Microsoft Entra Privileged Identity Management [PIM] with just-in-time activation and manager approval).
  5. Configure Azure Monitor and Azure DevOps Audit Streams to trigger real-time, high-priority security alerts whenever an audit event with action Policy.Bypass is logged.

---

GitHub Branch Protection Rules & Modern Rulesets

GitHub provides equivalent enforcement through Branch Protection Rules and the more modern Repository Rulesets.

Rulesets vs. Classic Branch Protection

• Classic Branch Protection: Applied per repository to individual branch patterns (e.g., main). Difficult to manage across hundreds of repositories in an enterprise organization.
• Repository Rulesets: Can be applied across multiple target repositories simultaneously at the organization level. They support versioning, evaluation mode (testing rules without enforcing), and granular bypass lists based on roles, teams, or GitHub Apps.

Key GitHub Protection Settings

---

Compliance Policy Matrix

This table summarizes how enterprise compliance requirements map directly to platform configurations: