Three Settings That Tie Every Main-Branch Commit to a GitHub Issue
Your organization uses GitHub and wants to ensure that all commits to the main branch are associated with a GitHub issue. Which three settings should you configure?
Quick Answer
Requiring pull request reviews before merging is the lever that actually ties commits to issues: every change has to go through a PR, and that PR review process is where issue linkage gets enforced, giving every merged commit clear traceability back to a GitHub issue. Requiring conversation resolution just closes out comment threads — it doesn't confirm an issue link exists.
⚠ Common exam trap
Many candidates think 'Require conversation resolution before merging' ensures issue association, but it only resolves PR discussions. The correct combination involves status checks (custom) and pull request reviews to enforce linking.
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 status checks to pass before merging
Requiring status checks to pass before merging can include a custom status check that validates that a pull request is linked to a GitHub issue, directly enforcing association. Option D is correct because requiring pull request reviews before merging forces all changes to go through a pull request, which must be linked to a GitHub issue to satisfy the review process, ensuring traceability. Option A is incorrect because requiring conversation resolution only ensures comments are resolved, not that commits are associated with an issue. Options C and E are irrelevant to issue association.
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 conversation resolution before merging
Why it's wrong here
Requiring conversation resolution before merging only ensures that all comments on a pull request are resolved, but does not enforce any link to a GitHub issue. This setting does not guarantee issue association.
- ✓
Require status checks to pass before merging
Why this is correct
Requiring status checks to pass before merging is correct because you can configure a custom status check that verifies a pull request references an issue, directly ensuring association.
- ✗
Allow force pushes
Why it's wrong here
Allowing force pushes is incorrect because it can bypass pull request requirements and allow commits without any issue reference or review.
- ✓
Require pull request reviews before merging
Why this is correct
Requiring pull request reviews before merging is correct because it mandates that all changes go through a pull request, which must be linked to an issue to satisfy the review process, ensuring traceability.
- ✗
Allow deletions
Why it's wrong here
Allowing deletions is irrelevant; it does not help enforce issue association.
Visual reference
Go deeper
Related to this question
Learn chapter
Final Review and Exam Preparation
Key term
Check
A Check in Azure DevOps is a gating mechanism that evaluates predefined conditions before allowing a pipeline deployment to proceed to a specific environment.
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.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
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 uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to pass a status check before merging. The status check should be provided by a pipeline that runs when a pull request is created. Which type of trigger should you configure in the pipeline YAML?
medium- A.Push trigger
- B.Manual trigger
- ✓ C.PR trigger
- D.Scheduled trigger
Why C: A PR trigger (pr:) in Azure Pipelines YAML automatically runs the pipeline when a pull request is created or updated against a specified branch. This allows the pipeline to produce a status check that GitHub enforces as a required check before merging, fulfilling the policy requirement.
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.