Configure processes and communications →hardMultiple ChoiceObjective-mapped

AZ-400 Configure processes and communications Practice Question

Exhibit

Refer to the exhibit.
{
  "rules": [
    {
      "name": "Require signed commits",
      "type": "required_signatures",
      "settings": {
        "required_approving_review_count": 1
      }
    },
    {
      "name": "Allow squash merge",
      "type": "allowed_merge_methods",
      "settings": {
        "squash": true,
        "rebase": false,
        "merge": false
      }
    }
  ]
}

You are reviewing a branch protection rule JSON for a GitHub repository. Developers complain that they cannot merge pull requests. What is the most likely cause?

⚠ Common exam trap

Test-takers frequently confuse branch protection rules that block merging (like required signed commits or required status checks) with settings that merely affect merge options (like disabling rebase or restricting merge methods), leading them to incorrectly choose options that do not actually prevent merging.

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 signed commit requirement is enforced but developers are not signing commits.

When a branch protection rule requires signed commits, any pull request containing unsigned commits will be blocked from merging. GitHub verifies commit signatures using GPG or S/MIME, and if developers are not signing their commits, the merge will fail regardless of other settings.

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 signed commit requirement is enforced but developers are not signing commits.
Why this is correct
The branch protection rule enforces signed commits, meaning any push containing unsigned commits will be rejected by GitHub. Because developers are not signing their commits, every push fails the signing requirement, which explains the blocked merges despite other settings being valid.
✗
The required approving review count is set to 1.
Why it's wrong here
Setting the required approving review count to 1 is a valid configuration; it only mandates that at least one reviewer approve the pull request. This does not cause commit rejection, as it affects the merge review process, not the commit signature validation.
✗
Rebase merging is disabled.
Why it's wrong here
Disabling rebase merging simply removes the rebase option from the merge dropdown, but other merge methods such as merge commits or squash remain available. Therefore, this setting does not prevent merges entirely and is not the source of the failure.
✗
Squash merge is the only allowed method.
Why it's wrong here
Allowing squash merge is a standard and valid merge strategy that collapses all commits into one. It does not conflict with the signed commit requirement, as squashing does not remove commit signatures, so this setting is not the cause of the issue.

Go deeper

AZ-400 Configure processes and communications Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question