Design and implement a source control strategy →mediumMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement a source control strategy

Exhibit

{"isDisabled":false,"isLocked":false,"isFrozen":false,"branch":"refs/heads/main","settings":{"scope":[{"refName":"refs/heads/main","matchKind":"Exact","repositoryId":"e6d5f8a1-..."}],"isBlocking":true,"isDeleted":false,"isEnabled":true,"isCommentRequired":true,"isResetOnSourcePush":false,"allowDeletions":false,"allowForcePush":false,"blockLastPusherReview":true,"requireApprovalCount":2,"requireMandatoryReviewers":true,"requireNoMergeConflict":true,"requireSquashMerge":false,"requireTransitionToApproved":true,"requiredReviewerIds":["a1b2c3d4-..."],"buildDefinitionId":1234,"queueOnSourceUpdateOnly":false,"manualQueueOnly":false,"triggeredBuilds":[],"automaticallyLinkedWorkItems":false,"displayName":"Main branch policy"}}

Refer to the exhibit. You have a branch policy JSON for Azure Repos. Which statement about this policy is correct?

⚠ Common exam trap

Many candidates assume the last person who pushed can always approve, but Azure Repos defaults to blocking that unless explicitly overridden, and the policy JSON shown does not include the override setting.

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

✓

At least two reviewers must approve the pull request.

The branch policy JSON specifies `minimumApproverCount: 2`, which enforces that at least two distinct reviewers must approve the pull request before it can be completed. This is a standard Azure Repos branch policy setting that controls the required number of approvals, not the identity of the approvers or the merge strategy.

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 last person who pushed can approve the pull request.
Why it's wrong here
Because blockLastPusherReview is enabled, the most recent pusher of commits to the source branch is blocked from approving the PR, even if they are a valid reviewer. This prevents authors from self-approving their own changes.
✓
At least two reviewers must approve the pull request.
Why this is correct
The branch policy sets requireApprovalCount to 2, meaning that two distinct reviewers (excluding those blocked by policy) must independently approve the PR before it can be completed. This is the correct interpretation of the policy.
✗
Pull requests to main are automatically squash-merged.
Why it's wrong here
The branch policy's requireSquashMerge attribute is set to false, so squash merging is not mandated nor automatically applied when completing a pull request. With this setting, PRs can be completed using any allowed merge type, such as a standard merge commit or rebase, depending on the user's selection. Thus, the claim that PRs to main are automatically squash-merged misreads a false boolean as an enforced behavior.
✗
Approvals are reset when the source branch is updated.
Why it's wrong here
Since isResetOnSourcePush is explicitly set to false, pushing new commits to the source branch does not invalidate approvals that have already been granted. If this flag were true, any new commit would reset all existing approvals and require fresh reviews before completion. Because the policy disables that reset, approvals remain valid across updates, making the statement that approvals are reset when the source branch is updated factually incorrect.

Go deeper

AZ-400 Practice Question: Design and implement a source control strategy

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question