Azure Repos – Branch Policies, Required Reviewers, Build Validation, and Direct Push Restrictions

1. What are Branch Policies in Azure Repos?

Branch Policies are rules configured in Azure Repos to protect important Git branches, such as main, develop, and release.

They help ensure that code changes are reviewed, validated, and approved before being merged into a protected branch.

Simple example

Suppose your ASP.NET Core Web API project has two branches:

• main – Contains production-ready code.

• develop – Contains ongoing development changes.

You want to protect main with these rules:

1. At least 2 reviewers must approve a Pull Request.

2. The build pipeline must succeed before merging.

3. All required review comments must be resolved.

4. Developers must not push code directly to main.

5. Changes must go through a Pull Request (PR).

Azure Repos provides branch policies and branch permissions to implement these requirements.

Important distinction: Branch policies control Pull Request completion. Branch permissions control who can push directly or bypass those policies. Both are necessary for strong protection.

2. Why do we need Branch Policies?

Without branch policies, a developer with sufficient permissions could push incorrect or unreviewed code directly to the production branch.

This can introduce compilation errors, security vulnerabilities, or business logic defects.

Real-time scenario

In a banking application, a developer modifies the fund transfer calculation.

The developer creates a feature branch and submits a Pull Request to main.

Before the PR can be completed, Azure Repos checks whether the required reviewers have approved, the build has passed, and the other configured policies are satisfied.

This reduces the risk of defective code being merged into the production branch.

3. How do Branch Policies work?

If a required policy fails, the Pull Request cannot be completed through the normal workflow.

Users with explicit bypass permissions may be able to override policies, so those permissions must also be restricted.

4. How to configure Branch Policies in Azure DevOps

You generally need Project Administrator access or the appropriate Edit policies permission.

Step 1: Open Branch Policies

1. Open Azure DevOps.

2. Select your Organization and Project.

3. Navigate to Repos → Branches.

4. Find the main branch.

5. Click the three-dot menu (...).

6. Select Branch policies.

Alternatively, use Project settings → Repositories → Select repository → Policies.

Step 2: Require a minimum number of reviewers

Find Require a minimum number of reviewers and enable it.

Recommended configuration:

Example:

Developer A creates a Pull Request.

Developer B approves it, but Developer C has not yet approved.

Because two approvals are required, the PR cannot be completed normally.

Once both reviewers approve and other required policies pass, the PR becomes eligible for completion.

You can also configure Automatically included reviewers to require a particular Tech Lead or security team for changes to specified files.

Microsoft Learn

+1

5. How to enforce Build Validation

Build Validation ensures that the proposed code successfully builds and passes the tests included in the validation pipeline before the PR is merged.

Step 1: Create a validation pipeline

For an ASP.NET Core Web API application, create a YAML pipeline.

File: azure-pipelines.yml

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: UseDotNet@2
    inputs:
      packageType: 'sdk'
      version: '8.0.x'

  - script: dotnet restore
    displayName: 'Restore Packages'

  - script: dotnet build --no-restore -c Release
    displayName: 'Build Application'

  - script: dotnet test --no-restore -c Release
    displayName: 'Run Unit Tests'

This example assumes the solution and projects are compatible with .NET 8.

Step 2: Configure Build Validation policy

Navigate to:

Repos → Branches → main → Branch policies → Build validation

Click + to add a build validation policy.

Save the policy.

Step 3: What happens during a PR?

Developer Creates PR
         ↓
Azure Pipeline Starts
         ↓
dotnet restore
         ↓
dotnet build
         ↓
dotnet test
         ↓
Build Successful?
    /           \
  Yes            No
   ↓              ↓
Policy Passed   Policy Failed
   ↓              ↓
Merge Eligible  Merge Blocked

If the pipeline fails, the developer must correct the code and push the changes.

The validation pipeline runs again according to the configured trigger.

Important: For Azure Repos Git, configuring trigger: main is not sufficient to enforce PR validation. You must associate the pipeline with the target branch through the Build Validation policy.

Microsoft Learn

+1

6. How to prevent direct pushes to main

This is one of the most important interview concepts.

Suppose a developer executes:

git switch main

git add .

git commit -m "Updated Customer API"

git push origin main

You want Azure Repos to reject this direct push and require a Pull Request instead.

Step 1: Configure required branch policies

Enable at least one required branch policy on main, such as:

• Minimum two reviewers.

• Required build validation.

In Azure Repos, a branch with required policies is protected against direct pushes from users who do not have policy-bypass permission.

Step 2: Configure branch security

Navigate to:

Repos → Branches → main → ... → Branch security

Select the Contributors group.

Review the following permissions:

Important: Not set is not always equivalent to Deny, because permissions may be inherited. Check effective permissions for the relevant users and groups.

Also, you do not generally need to deny Contribute to prevent direct pushes. Required policies block normal direct pushes unless the user has bypass permission.

Step 3: Test direct push protection

A developer attempts:

git push origin main

Azure Repos rejects the push because the branch is protected and the developer does not have bypass permission.

The developer must instead:

git switch -c feature/customer-api

git add .

git commit -m "Added Customer API"

git push -u origin feature/customer-api

Then create a Pull Request targeting main.

Step 4: Restrict bypass permissions

Azure Repos has two important permissions:

• Bypass policies when pushing: Allows direct pushes to a protected branch.

• Bypass policies when completing pull requests: Allows authorized users to complete PRs without satisfying all policies.

Keep these permissions restricted to a small group of trusted administrators or emergency release owners.

Microsoft recommends combining branch policies with carefully controlled branch permissions.

Microsoft Learn

+1

7. Recommended Branch Protection Configuration

For a production branch such as main, I would use this configuration:

This provides a practical balance between code quality, traceability, and controlled releases.

8. Branch Policies vs Branch Permissions

Interview point: Branch policies enforce the quality gates; branch permissions enforce access control and prevent unauthorized bypasses.

9. Important Interview Questions and Answers

Q1. What are branch policies in Azure Repos?

Branch policies are rules used to protect important Git branches by enforcing Pull Request reviews, build validation, and other checks before merging code.

Q2. How do you enforce two reviewers?

Open main → Branch policies, enable Require a minimum number of reviewers, and set the count to 2.

Q3. How do you prevent direct pushes to main?

Configure required branch policies and ensure developers do not have Bypass policies when pushing permission.

Q4. What happens if build validation fails?

The Pull Request cannot be completed normally until the required validation succeeds.

Q5. Can an administrator bypass branch policies?

Yes, if the administrator has the appropriate bypass permission. Administrator status alone should not be assumed to grant every bypass permission.

Q6. What happens if new commits are pushed after approval?

Azure Repos reevaluates applicable policies. Depending on the reviewer policy settings, existing approvals may be reset or additional approval may be required.

Q7. Can branch policies be applied to develop as well?

Yes. Branch policies can protect main, develop, release branches, and other important branches.

10. Real-Time Interview Scenario

Question: How do you protect the production branch in Azure Repos?

Sample answer:

In our project, we protect the main branch using Azure Repos branch policies and permissions.

We require at least two reviewers to approve every Pull Request and configure build validation so that the application must compile and automated tests must pass before merging.

We also require review comments to be resolved and link Pull Requests with Azure Boards work items for traceability.

To prevent direct pushes, we enforce required branch policies and restrict the Bypass policies when pushing permission.

Developers work on feature branches and create Pull Requests to merge changes into protected branches.

This ensures that production code is reviewed, tested, and merged through a controlled process.

Key points to remember

• Branch Policies = Rules for protecting branches.

• Minimum Reviewers = Required PR approvals.

• Build Validation = Automated build and test checks.

• Branch Permissions = Control Git access and policy bypass.

• Required Policies = Prevent normal direct pushes to protected branches.

• Bypass Permissions = Allow explicitly authorized exceptions.

• Pull Request = Controlled mechanism for merging code.

One-line interview answer: In Azure Repos, we protect main by configuring branch policies that require reviewer approvals and successful build validation, while restricting policy-bypass permissions to prevent developers from pushing code directly to the production branch.

For the exact configuration options, see Microsoft Learn – Set and manage branch policies.