Configure processes and communications →mediumMultiple ChoiceObjective-mapped

Why an S/MIME Signed Commit Gets Rejected on a GPG-or-SSH Branch Policy

Exhibit

Refer to the exhibit.

```json
{
  "policies": [
    {
      "name": "Require signed commits",
      "enforcementMode": "block",
      "scope": {
        "refNames": ["refs/heads/main"]
      },
      "parameters": {
        "signatureTypes": ["gpg", "ssh"]
      }
    }
  ]
}
```

You applied the above branch policy to a GitHub repository. A developer tries to push a commit to the main branch that is signed with an S/MIME signature. What will happen?

Quick Answer

If a branch policy's allowed signature types list only GPG or SSH, a commit signed with S/MIME gets rejected on push — GitHub's branch protection enforces signature requirements strictly against whatever types are explicitly configured, and S/MIME simply isn't one of them in this policy.

⚠ Common exam trap

Candidates often assume any signed commit is accepted, overlooking that GitHub's branch policy explicitly restricts which signature types are allowed, and S/MIME is not among them.

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 commit is rejected because S/MIME is not in the allowed signature types.

The branch policy in question is configured to allow only GPG or SSH signatures. S/MIME is not listed as an allowed signature type, so the commit is rejected. GitHub's branch protection rules enforce signature requirements based on the allowed signature types specified in the policy.

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 commit is rejected because S/MIME is not in the allowed signature types.
Why this is correct
Only GPG and SSH are allowed.
✗
The commit is accepted because S/MIME is implicitly allowed.
Why it's wrong here
Only explicitly listed types are allowed.
✗
The commit is accepted because it is signed.
Why it's wrong here
The policy restricts signature types.
✗
The commit is rejected because the policy is in 'block' mode, which blocks all pushes.
Why it's wrong here
'Block' mode blocks violations, not all pushes.

Go deeper

1 more way 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. Your organization requires that all code changes be signed using a valid code signing certificate before they can be merged. Which feature in GitHub should you enable to enforce this?

easy

A.Dependabot.
✓ B.Commit signature verification.
C.Code scanning.
D.Secret scanning.

Why B: Commit signature verification in GitHub enforces that commits are signed with a verified GPG or S/MIME key, which meets the requirement of signing code changes. Option A is wrong because Dependabot handles dependency updates, not signature enforcement. Option C is wrong because code scanning analyzes code for vulnerabilities, not for commit signatures. Option D is wrong because secret scanning detects secrets in repositories, not signature enforcement.

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.

Why an S/MIME Signed Commit Gets Rejected on a GPG-or-SSH Branch Policy

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question

1 more way this is tested on AZ-400