Why a GitHub Status Check Won't Show Up in Branch Protection
Your team uses GitHub Actions for CI/CD. You need to enforce that all pull requests to the main branch pass a required status check that runs a security scan. The security scan is a GitHub Action that runs on pull_request events. However, the status check is not appearing as required in the branch protection rules. What should you do?
Quick Answer
GitHub branch protection matches required status checks by exact name — the workflow's name (or the specific job name within it) as it appears in the Actions UI. If the workflow's declared name doesn't match what's typed into the branch protection rule's required-checks list, GitHub can't find it to offer as an option, even though the check is genuinely running on every pull request.
⚠ Common exam trap
The trap here is that candidates often focus on event triggers or authentication tokens, overlooking the simple but critical requirement that the status check name must exactly match the workflow or job name in the branch protection rule.
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
✓
Ensure the workflow has a name that matches the status check name in the branch protection rule.
GitHub branch protection rules require the status check name to exactly match the workflow name (or the job name within the workflow) as it appears in the GitHub Actions UI. If the names do not match, the check will not appear as an option in the required status checks list. The security scan action runs on pull_request events, so the status check is generated, but the mismatch prevents it from being selectable as a required check.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add 'types: [opened, synchronize]' to the pull_request trigger.
Why it's wrong here
These are default types; adding them explicitly does not solve the issue.
- ✗
Change the trigger from 'pull_request' to 'pull_request_target'.
Why it's wrong here
pull_request_target runs in the context of the base branch and is used for token access, but does not affect status check visibility.
- ✗
Use a GitHub App instead of the default GITHUB_TOKEN for the action.
Why it's wrong here
The token is not related to the visibility of status checks.
- ✓
Ensure the workflow has a name that matches the status check name in the branch protection rule.
Why this is correct
The status check name is based on the workflow name and job name. If the workflow name is different, the check won't match.
Go deeper
Related to this question
Learn chapter
Designing a Security and Compliance Plan
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
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.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways 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 Microsoft Defender XDR to secure Azure DevOps pipelines. You need to ensure that any build pipeline triggered by a pull request automatically runs a security scan and fails if critical vulnerabilities are found. What should you configure?
medium- A.Code scanning alerts in GitHub
- B.Azure Policy for Pipelines
- ✓ C.Branch protection rule with required status check
- D.Pipeline security gate
Why C: Branch protection rules in Azure Repos or GitHub can require a status check from a build pipeline. By configuring a required status check that runs a security scan, the pull request cannot be merged if the scan fails. Option A (Code scanning alerts in GitHub) is for identifying vulnerabilities in code, not blocking merges based on pipeline results. Option B (Azure Policy for Pipelines) enforces governance on Azure resources, not pipeline security scans. Option D (Pipeline security gate) is not a feature in Azure DevOps.
Variation 2. You need to automatically run a security scan on every pull request in GitHub. The scan should block the PR if critical vulnerabilities are found. Which GitHub feature should you use?
easy- ✓ A.GitHub Code Scanning with a CodeQL workflow
- B.Dependabot version updates
- C.Secret scanning
- D.Branch protection rules with required status checks
Why A: GitHub Code Scanning with a CodeQL workflow is the correct choice because it allows you to define a custom security analysis that runs on every pull request. By configuring the workflow to fail on critical-severity alerts, the pull request is automatically blocked, preventing vulnerable code from being merged. This integrates directly with GitHub's checks API to enforce the scan result as a required status check.
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.