Design and implement a source control strategy →mediumMultiple Choice

Why a Direct Push to a Protected Main Branch Is Blocked

Exhibit

Refer to the exhibit.

```json
{
  "repositorySettings": {
    "defaultBranch": "main",
    "requireLinearHistory": false,
    "allowForcePush": false,
    "branchPolicies": [
      {
        "branchName": "main",
        "requiredReviewers": 2,
        "checkForLinkedWorkItems": true,
        "buildValidation": {
          "buildDefinitionId": 123,
          "displayName": "CI Build",
          "manualQueueOnly": false
        }
      }
    ]
  }
}
```

Refer to the exhibit. An Azure DevOps administrator has configured the branch policy for the main branch as shown. A developer attempts to push a commit directly to the main branch. What will happen?

Quick Answer

A direct push to a protected main branch gets rejected outright when the branch policy requires pull requests — Azure Repos enforces this at the server level, blocking the push before it's even accepted, well before any build validation or other checks would have a chance to run.

⚠ Common exam trap

It's easy for candidates to assume build validation or other policies are the primary gate, when in fact the 'Require a pull request before merging' setting is the first and most restrictive policy that blocks direct pushes regardless of other policy states.

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

✓

The push is rejected because branch policies require a pull request

The branch policy for the main branch requires that all changes be submitted via a pull request. When a developer attempts to push a commit directly to main, Azure Repos enforces this policy by rejecting the push. The push is blocked at the server level before any build validation or other checks occur.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The push triggers the build validation pipeline
Why it's wrong here
Build validation policies queue a pipeline run against the pull request's merge commit; they do not gate direct pushes to the branch. The push succeeds unless a required-reviewer or status policy blocks it. Build validation is tempting because it enforces quality on pull requests, which is its actual purpose.
✗
The push is allowed because allowForcePush is false
Why it's wrong here
AllowForcePush governs whether history can be rewritten on the branch, not whether ordinary commits may be pushed; with it false, force pushes are rejected but a normal fast-forward push still succeeds. It is tempting because force-push settings appear in the same security policy, and disabling them is correct when protecting a branch from history rewriting.
✓
The push is rejected because branch policies require a pull request
Why this is correct
A branch policy requiring a pull request blocks direct pushes to main. Azure DevOps rejects the developer's push at the server, because commits must arrive through a completed pull request that satisfies the configured reviewers and build validation, rather than bypassing the policy via a local commit.
✗
The push is allowed because requireLinearHistory is false
Why it's wrong here
RequireLinearHistory only forbids merge commits on the target branch; it does not block direct pushes, which are governed by the separate Require a minimum number of reviewers policy. It is tempting because linear history is often enforced alongside push restrictions, but it is the correct control when the goal is preventing merge commits rather than direct commits.

Go deeper

1 more way this is tested on AZ-400

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. Refer to the exhibit. You are migrating repository policies from Azure Repos to GitHub. The JSON shows a branch protection rule you plan to apply to the main branch. A developer pushes a hotfix directly to main without a pull request. What happens?

medium

A.The push is blocked because required status checks are not met.
B.The push is blocked because enforceAdmins is true.
✓ C.The push succeeds because no push restriction is defined.
D.The push is rejected because lockBranch is false.

Why C: The branch protection rule shown does not include a push restriction (such as 'Restrict who can push to matching branches'), so a developer with write access can push directly to main. Required status checks and enforceAdmins only apply to merges/pushes that go through the protected path; without an explicit push restriction, the direct push succeeds.

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.

Why a Direct Push to a Protected Main Branch Is Blocked

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question

1 more way this is tested on AZ-400