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

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

Exhibit

{
  "policy": {
    "rules": [
      {
        "type": "required_pull_request_review",
        "parameters": {
          "required_approving_review_count": 2,
          "dismiss_stale_reviews": true,
          "require_code_owner_review": true
        }
      },
      {
        "type": "required_status_checks",
        "parameters": {
          "strict": true,
          "contexts": ["continuous-integration/jenkins/pr-merge", "Azure Policy Check"]
        }
      }
    ]
  }
}

Refer to the exhibit. You are reviewing a branch protection rule for the main branch of a GitHub repository. A developer complains that after pushing new commits to an existing pull request, the existing approvals from two reviewers are dismissed, and the pull request cannot be merged even though the CI checks pass. What is the most likely cause?

⚠ Common exam trap

Many exam-takers confuse the 'dismiss_stale_reviews' behavior with the 'strict' branch requirement, thinking that being out of date causes approval dismissal, when in fact 'strict' only blocks the merge button without affecting existing approvals.

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 'dismiss_stale_reviews' setting is enabled, which dismisses approvals when new commits are pushed.

The 'dismiss_stale_reviews' setting in GitHub branch protection rules automatically dismisses existing pull request approvals when new commits are pushed to the branch. This explains why the developer sees approvals removed after pushing new commits, even though CI checks pass. The setting is designed to ensure that reviewers re-evaluate changes after updates.

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 'dismiss_stale_reviews' setting is enabled, which dismisses approvals when new commits are pushed.
Why this is correct
The 'dismiss_stale_reviews' setting is enabled, which automatically invalidates prior pull request approvals whenever new commits are pushed to the branch. This directly explains why previously granted approvals no longer count, forcing re-review after each update.
✗
The 'strict' setting requires the branch to be up to date with the base branch, which is not the case.
Why it's wrong here
The 'strict' setting enforces that the branch must be up to date with the base branch before merging, but it does not dismiss existing approvals. It only blocks the merge until the branch is synchronized; it is not the cause of the approvals being removed.
✗
The code owner review is required but no code owner has reviewed.
Why it's wrong here
Although a required code owner review can prevent merging if missing, it does not retroactively dismiss approvals that were already submitted. This is a separate merge condition and does not explain why existing approvals were invalidated.
✗
The CI check 'continuous-integration/jenkins/pr-merge' failed.
Why it's wrong here
The premise is contradicted by the exhibit: the status check 'continuous-integration/jenkins/pr-merge' is shown as passing (green), so it cannot be the reason approvals were removed. Beyond that, a failed CI check would block the merge as a failing required status check, but it has no mechanism to invalidate previously submitted reviews. Only the branch protection setting that dismisses stale approvals on new commits would retroactively clear them.

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