AZ-400 Develop a security and compliance plan Practice Question
Your team uses GitHub repositories and wants to ensure that all code changes are signed by a verified contributor before merging. Which branch protection rule should you enable?
⚠ Common exam trap
Test-takers frequently confuse identity verification (signed commits) with access control (restrict pushes) or process approval (pull request reviews), leading candidates to pick a rule that controls who can push rather than what cryptographic proof is required.
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
✓
Require signed commits
Requiring signed commits ensures that each commit is cryptographically verified using a GPG or S/MIME key linked to the contributor's GitHub account. This enforces non-repudiation and confirms the identity of the author, directly addressing the requirement that all code changes be signed by a verified contributor before merging.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Require signed commits
Why this is correct
Requiring signed commits enforces a branch protection rule that every commit on the protected branch must be signed with a GPG or S/MIME key that GitHub can verify; unsigned commits are blocked, ensuring cryptographically verified authorship.
- ✗
Require pull request reviews before merging
Why it's wrong here
Requiring pull request reviews before merging mandates at least one approved reviewer and often additional checks, but it never inspects the cryptographic signature of individual commits; thus unsigned or unverified commits can still be merged after formal review.
- ✗
Require linear history
Why it's wrong here
Requiring linear history protects only the shape of the commit graph by blocking merge commits and enforcing a fast-forward or squash-and-rebase workflow. It never inspects the cryptographic signature or verifies the identity of each commit's author, so an authorized user could still push unsigned commits that pass the linearity rule. Squash or rebase operations can even collapse multiple unsigned or unverified commits into a single new commit, which still satisfies the topology check but provides zero assurance of cryptographic provenance.
- ✗
Restrict who can push to matching branches
Why it's wrong here
Restricting who can push to matching branches limits write access to specific identities, apps, or teams, but this does not require each pushed commit to be signed; even authorized users could push unsigned or falsely attributed commits if no signing rule is set.
Go deeper
Related to this question
Learn chapter
Managing Infrastructure as Code Using Azure
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
Key term
GitHub
GitHub is a cloud-based platform for storing, tracking, and collaborating on code using Git version control.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
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.