Diagnosing a Missing PR Trigger in Azure Pipelines YAML
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.)
⚠ Common exam trap
The trap here is that candidates often forget the `trigger:` keyword (as in Option C) or misuse `exclude` when `include` is needed (as in Option A), and they may also incorrectly assume a simple list syntax like `branches: main` is valid without the `include` keyword.
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
✓
trigger: branches: include: - main
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
trigger: branches: exclude: - main
Why it's wrong here
Using an exclude filter for main is incorrect for this requirement because it explicitly prevents the pipeline from triggering on the main branch; the CI trigger will fire for every other branch, leaving main unpipelined and bypassing your continuous integration validation on the default branch.
- ✓
trigger: branches: include: - main
Why this is correct
This is correct: the trigger block with branches/include and a main entry tells Azure Pipelines to start the CI pipeline only when changes are pushed to main, using the required YAML syntax where branches filters are lists under include or exclude.
- ✗
branches: include: - main
Why it's wrong here
This YAML is invalid as a CI trigger definition because it lacks the root-level 'trigger:' keyword; without that key, the 'branches' element is not recognized as a pipeline trigger and no branch-based CI triggering will occur, so this snippet would be ignored or cause a schema validation error.
- ✗
trigger: branches: main
Why it's wrong here
The syntax is invalid: under the 'trigger:' block, 'branches' must be an object containing 'include', 'exclude', or other defined filters, not a plain scalar like 'main'; this malformed structure will fail YAML schema validation and does not configure any branch trigger, so you must specify branches.include: - main instead.
- ✓
trigger: branches: include: - release/*
Why this is correct
This is a correct and valid configuration if you want CI triggers on all release branches: the wildcard 'release/*' matches any branch whose name starts with 'release/', such as 'release/1.0' and 'release/v2', and the include filter causes the pipeline to trigger on pushes to those branches, using the same syntax as triggering on main.
Visual reference
Go deeper
Related to this question
Learn chapter
Implementing a Release Pipeline
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
Key term
Continuous integration
Continuous integration is a DevOps practice where developers frequently merge their code changes into a shared repository, with each merge triggering an automated build and test process to catch integration errors early.
About these practice questions
This AZ-400 question is part of Courseiva's 696-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
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 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: To automatically build and deploy on every commit to the 'main' branch, you need a CI trigger that includes the 'main' branch. The YAML snippet 'trigger: branches: include: - main' does exactly that. It tells Azure Pipelines to trigger a run whenever a commit is pushed to 'main'. Other options either disable triggers, schedule runs, or trigger on pull requests, none of which meet the requirement of automatic build on commit.
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.