Letting Only Release Managers Merge from Develop into Main
Your company uses Azure Repos with a Git branching strategy that includes a main branch, a develop branch, and feature branches. You need to enforce that only designated release managers can merge changes from develop into main, while developers can create feature branches off develop and merge pull requests into develop. What is the best way to implement this?
Quick Answer
Restricting who can merge from develop into main takes two settings working together: branch policies on main requiring a minimum number of reviewers from the release manager group, and the 'Allow users to create pull requests' permission scoped to release managers only. Branch protection rules as a concept belong to GitHub, not Azure Repos, so that option doesn't apply here.
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
✓
Configure branch policies on main to require a minimum number of reviewers from the release manager group, and set the 'Allow users to create pull requests' permission to only include release managers.
By configuring branch policies on the main branch to require a minimum number of reviewers from the release manager group, you ensure that any changes to main are reviewed by designated release managers. Additionally, setting the 'Allow users to create pull requests' permission to only include release managers controls who can initiate pull requests into main. Option B is incorrect because branch protection rules are a GitHub feature, not available in Azure Repos. Option C is incorrect because setting the main branch to read-only would prevent all pushes, including those from release managers, unless they are granted write permissions; however, this approach does not enforce pull request reviews and is less granular. Option D is incorrect because requiring a successful build does not restrict who can merge; it only ensures code quality.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure branch policies on main to require a minimum number of reviewers from the release manager group, and set the 'Allow users to create pull requests' permission to only include release managers.
Why this is correct
This allows only release managers to create pull requests into main, enforcing the desired control.
- ✗
Use GitHub branch protection rules to require pull request reviews from release managers on main.
Why it's wrong here
Azure Repos uses branch policies, not GitHub branch protection.
- ✗
Set the main branch to read-only for all users except release managers using the 'Security' tab in repository settings.
Why it's wrong here
This only prevents direct pushes but does not prevent developers from creating pull requests into main.
- ✗
Require a successful build for all branches and set the build pipeline to only run for release manager commits.
Why it's wrong here
Build requirements do not restrict who can merge.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Feature
A feature is a distinct unit of functionality that delivers value to the user, often managed and tracked throughout the software development lifecycle.
Key term
Pull request
A pull request is a way for a developer to propose changes to a codebase and ask other team members to review and merge them into the main project.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways 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. The YAML pipeline triggers on commits to main and develop branches, and pull requests targeting develop. A developer pushes a commit directly to main. What will happen?
medium- A.The pipeline does not run because the PR trigger requires a pull request.
- ✓ B.The pipeline runs once for the CI trigger.
- C.The pipeline runs twice: once for the CI trigger and once for the PR trigger.
- D.The pipeline runs once for the PR trigger only.
Why B: The pipeline is configured with a CI trigger for both main and develop branches, and a PR trigger only for pull requests targeting develop. When a developer pushes a commit directly to main, the CI trigger fires because the push matches the main branch, causing the pipeline to run once. The PR trigger does not activate because there is no pull request involved.
Variation 2. Your team is adopting GitFlow with a main and develop branch. You need to ensure that hotfix branches are merged into both main and develop, but feature branches only into develop. What branch policy configuration should you implement?
hard- A.Set the main branch to require all merges to come from pull requests, and for develop, allow direct pushes.
- B.Use branch policies on main and develop that allow only certain source branches to merge, using branch naming conventions.
- C.Configure a global policy that requires all branches to have a minimum number of reviewers.
- ✓ D.Use a build validation policy to check the branch name and reject merges that do not follow the pattern.
Why D: Azure Repos branch policies do not provide a native setting to restrict which source branches can merge into a target branch. To enforce the GitFlow workflow, you can add a build validation policy that runs a build (or a simple script) on the PR and fails if the source branch does not match the expected pattern for the target branch. For example, for `main` only `hotfix/*` is allowed, while for `develop` both `hotfix/*` and `feature/*` are allowed. This blocks any PR that violates the rules.
Variation 3. You are a DevOps engineer for a large enterprise that uses GitHub Enterprise Cloud. The development team follows a GitFlow branching strategy with develop, feature, release, and main branches. The release branch is created from develop when a release is ready. After testing, the release branch is merged into main and then tagged. However, the team frequently forgets to merge release branches back into develop, causing hotfixes applied to main to not be in develop. You need to implement an automated process to ensure that after a release branch is merged into main, the changes are also merged back into develop. The solution must not require manual intervention and must handle merge conflicts gracefully by opening a pull request for conflict resolution. Which approach should you use?
hard- A.Configure a branch protection rule on main that requires a pull request to merge into develop.
- ✓ B.Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.
- C.Create a scheduled workflow that runs daily and merges main into develop if there are no conflicts.
- D.Set up a webhook in GitHub that calls an Azure Function to merge main into develop.
Why B: It uses a GitHub Actions workflow triggered on pushes to main to automatically merge main into develop. If conflicts arise, the workflow opens a pull request for manual resolution, ensuring no changes are lost and the process remains automated without manual intervention.
JA
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.