A team uses feature branches for all new work. They want to ensure that no feature branch is merged without at least one approval and that the build passes. They also want to prevent direct pushes to the main branch. What should they configure?

Branch policies on each feature branch requiring a reviewer and build.

A repository-wide setting that blocks all merges unless the author is a team lead.

A pre-commit hook that runs the build locally before any commit.

Branch policies on main requiring a minimum number of reviewers and a successful build, with the branch set to require pull requests.

A team uses feature branches but is experiencing frequent merge conflicts because branches live too long. They want to reduce conflicts without sacrificing the isolation that feature branches provide. They also want to ensure that no broken code reaches main. Which strategy should they adopt?

Keep feature branches long-lived and merge only at the end of the sprint.

Merge feature branches directly to main without pull requests.

Use a single shared feature branch for all developers.

Keep feature branches short-lived by merging to main frequently, and require branches to be up to date before merging via branch policies.

What is the purpose of implementing restrictions on branch merging?

To prevent any developer from ever merging code into any branch.

To speed up the merging process by bypassing code review.

To automatically resolve merge conflicts without human intervention.

To control how and when changes are integrated into important branches, maintaining stability.

When is a release branch typically created?

When the code on the main branch reaches a state that is ready to be stabilized for a release.

At the beginning of every sprint, before any feature development begins.

Whenever a developer wants to work on a new feature.

Only after the production deployment has been completed successfully.

Which mechanism can be used to restrict merging into a main branch?

Requiring a pull request with a minimum number of approvals before merging.

Allowing any user with write access to push directly to the main branch.

Disabling the main branch so that no one can access it.

Creating a new repository for every merge.

Microsoft Certified:DevOps Engineer Expert

Domain 2Objective 1

Design and Implement Branching Strategies for the Source Code AZ-400 Practice Questions (Page 1)

Part of the Design and implement a source control strategy domain, which makes up ~10% of our current practice bank. Microsoft does not publish an official question count, but from its 140-minute exam (~55–95 total, ~6–10 in this domain), expect 3–5 from this objective — we provide 31 practice questions to prepare you well beyond it. (estimate)

31questions here

7free pages

7concepts

Questions 1–5

1application · medium
A team uses feature branches for all new work. They want to ensure that no feature branch is merged without at least one approval and that the build passes. They also want to prevent direct pushes to the main branch. What should they configure?
Select an answer first
2expert · hard
A team uses feature branches but is experiencing frequent merge conflicts because branches live too long. They want to reduce conflicts without sacrificing the isolation that feature branches provide. They also want to ensure that no broken code reaches main. Which strategy should they adopt?
Select an answer first
3foundation · easy
What is the purpose of implementing restrictions on branch merging?
Select an answer first
4foundation · easy
When is a release branch typically created?
Select an answer first
5foundation · easy
Which mechanism can be used to restrict merging into a main branch?
Select an answer first

Finished these 5 questions?

Review the revealed explanations, or continue through the curriculum.

Next 5 questions →Back to AZ-400

Free Basic Practice is a study aid with revealable answers — not a scored exam. Examers.io is independent and not affiliated with or endorsed by Microsoft. “AZ-400” is a trademark of its owner, used for identification only.