Diagnosing a Missing PR Trigger in Azure Pipelines YAML
Network Topology
Refer to the exhibit. You have this Azure Pipelines YAML definition. The pipeline runs manually, but you want it to automatically trigger on every push to the main branch and also build pull requests targeting main. Which change should you make?
Quick Answer
Replacing triggers: ['none'] with triggers: ['main'] and pr: ['none'] with pr: ['main'] is what turns the pipeline back on — those 'none' values explicitly disable CI and PR triggers, so swapping in the branch name re-enables automatic builds on pushes to main and on pull requests targeting it.
⚠ Common exam trap
Many candidates think removing the trigger sections (Option A) will enable automatic triggers, but in Azure Pipelines YAML, removing them actually enables triggers on all branches, not just main, which is too broad and does not meet the specific requirement.
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
✓
Replace 'triggers: ["none"]' with 'triggers: ["main"]' and 'pr: ["none"]' with 'pr: ["main"]'.
In Azure Pipelines YAML, setting `triggers: ['none']` explicitly disables CI triggers, and `pr: ['none']` disables PR triggers. To enable automatic builds on every push to main and on pull requests targeting main, you must replace these with `triggers: ['main']` and `pr: ['main']`, which configures both CI and PR triggers for the main branch.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove the 'triggers' and 'pr' sections entirely.
Why it's wrong here
Removing them enables default triggers for all branches, not just main.
- ✓
Replace 'triggers: ["none"]' with 'triggers: ["main"]' and 'pr: ["none"]' with 'pr: ["main"]'.
Why this is correct
This enables CI on push to main and PR triggers for PRs targeting main.
- ✗
Set 'triggers' to '["main"]' and 'pr' to '["none"]'.
Why it's wrong here
This enables CI on push to main but disables PR triggers.
- ✗
Set 'triggers' to 'none' and 'pr' to 'none'.
Why it's wrong here
This disables both CI and PR triggers.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
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
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
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
3 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 team uses GitFlow with Azure Repos. You need to ensure that every commit to the 'main' branch is built and deployed to production automatically. Which trigger should you configure in your YAML pipeline?
medium- A.Trigger: none
- ✓ B.trigger: branches: include: - main
- C.schedules: - cron: "0 0 * * *" branches: include: - main
- D.pr: branches: include: - main
Why B: A branch-specific trigger defined with `trigger: branches: include: - main` will automatically run the pipeline on every commit to the 'main' branch. Option A is wrong because `trigger: none` disables CI triggers entirely, so the pipeline will not start on any commits. Option C is wrong because a scheduled trigger (`schedules:`) runs the pipeline at specific times, not in response to commits. Option D is wrong because a PR trigger (`pr:`) runs the pipeline when a pull request is created or updated, not on direct commits to 'main'.
Variation 2. You are configuring a continuous integration (CI) trigger for your YAML pipeline. The trigger should run the pipeline when changes are pushed to the 'main' branch or any release branch matching 'release/*'. Which TWO trigger configurations are valid? (Choose two.)
easy- A.trigger: branches: exclude: - main
- ✓ B.trigger: branches: include: - main
- C.branches: include: - main
- D.trigger: branches: main
- ✓ E.trigger: branches: include: - release/*
Why B: The `trigger` section with `branches: include: - main` explicitly specifies that the pipeline should run on pushes to the `main` branch. Option E is correct because `trigger: branches: include: - release/*` uses the wildcard pattern `release/*` to include all branches matching that pattern, such as `release/v1.0` or `release/2.0`. Both configurations are valid YAML trigger definitions for Azure Pipelines.
Variation 3. Refer to the exhibit. The pipeline will trigger when changes are pushed to which branches?
easy- A.All branches
- ✓ B.The main branch and any branch starting with 'release/'
- C.Only the main branch
- D.Only branches starting with 'release/'
Why B: The pipeline trigger configuration uses a YAML `trigger` block with `branches` and `include` clauses. The `include` list specifies that the pipeline triggers on pushes to the `main` branch and any branch matching the wildcard pattern `release/*`. This is why option B is correct: the pipeline triggers on both the main branch and all branches starting with 'release/'.
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.