Why a GitHub Webhook Trigger Never Fires on Pull Request Events
Exhibit
{
"pipelines": [
{
"name": "CI",
"trigger": "none",
"resources": {
"webhooks": [
{
"webhookName": "GitHubPR",
"connection": "GitHubConnection",
"filters": [
{"path": "action", "value": "opened"}
]
}
]
},
"steps": [
{"script": "echo Build triggered via webhook"}
]
}
]
}Refer to the exhibit. You are reviewing an Azure DevOps YAML pipeline. The pipeline is configured with a webhook trigger from GitHub for pull request opened events. However, the pipeline does not trigger when a PR is opened. What is the most likely cause?
Quick Answer
A webhook-triggered pipeline that never fires on pull request events almost always means the webhook subscription itself was never created in GitHub — the Azure DevOps YAML only defines what the pipeline does with an incoming event, but GitHub has to be separately configured to actually send that event over. Without that subscription, Azure DevOps never even hears about the PR being opened.
⚠ Common exam trap
A common mix-up: candidates assume the YAML webhook trigger definition alone is sufficient, but Azure DevOps requires the external webhook subscription to be manually configured in GitHub, which is a common misconfiguration in real-world scenarios.
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 webhook subscription is not configured in GitHub.
The most likely cause is that the webhook subscription is not configured in GitHub. Azure DevOps YAML pipelines with webhook triggers require an explicit webhook to be set up in the GitHub repository to send events (like pull request opened) to Azure DevOps. Without this subscription, Azure DevOps never receives the event, so the pipeline cannot trigger.
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 webhook subscription is not configured in GitHub.
Why this is correct
The YAML defines the webhook, but GitHub needs to be configured to send events to Azure DevOps.
- ✗
The webhook name does not match the service connection.
Why it's wrong here
The name 'GitHubPR' is used; the connection is 'GitHubConnection', which is separate.
- ✗
The pipeline lacks an agent pool specification.
Why it's wrong here
Missing agent pool would cause a different error, not prevent triggering.
- ✗
The webhook filter is incorrect; 'opened' should be 'created'.
Why it's wrong here
'opened' is the correct action for PR opened events.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Pull request
A pull request is a way for a developer to propose changes to a codebase and ask other team members to review and merge them into the main project.
Key term
Repository
A repository is a central storage location where software packages, code, or configuration files are kept, managed, and distributed for use by IT systems.
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. A developer wants to automatically trigger a GitHub Actions workflow when a pull request is opened that targets the 'release' branch. Which trigger should they use?
easy- A.pull_request_target: branches: [release]
- B.push: branches: [release]
- C.workflow_dispatch:
- ✓ D.pull_request: branches: [release]
Why D: The `pull_request` trigger fires when a pull request is opened, and the `branches: [release]` filter restricts it to PRs targeting the `release` branch. `pull_request_target` also fires on PR open events but runs in the base repository context and is intended for workflows requiring secrets or write access, not as the general PR-open trigger. `push` only fires on pushes to branches, not on PR opens. Therefore, D is correct.
Variation 2. Your development team uses GitHub for source control. You want to automatically run a set of tests every time a pull request is opened against the main branch. What should you configure?
easy- ✓ A.Create a GitHub Actions workflow triggered by pull_request events to main
- B.Use the GitHub API to trigger tests when a PR is opened
- C.Set up a webhook to trigger an external CI system
- D.Configure a branch protection rule to require status checks
Why A: GitHub Actions natively supports the `pull_request` event trigger, which can be configured to run workflows automatically when a pull request is opened against a specific branch (e.g., `main`). This allows you to define a YAML-based workflow in the `.github/workflows` directory that executes tests on every PR event, providing immediate feedback to developers without requiring external services or manual API calls.
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.