Drag a concept onto its matching description — or click a concept then click the description.
Runs pipeline on code push
Runs pipeline on pull request creation
Runs pipeline at specified times
Runs pipeline after another pipeline completes
Match each YAML pipeline trigger to its behavior.
Drag a concept onto its matching description — or click a concept then click the description.
Runs pipeline on code push
Runs pipeline on pull request creation
Runs pipeline at specified times
Runs pipeline after another pipeline completes
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
CI trigger: Triggers a pipeline when a push occurs on the specified branch
In Azure Pipelines YAML, each trigger type has a distinct purpose: CI for push events, PR for pull requests, Schedules for cron-based runs, and Pipeline for cross-pipeline dependencies. Common confusions mix the behaviors of CI/PR or PR/Pipeline triggers.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
CI trigger: Triggers a pipeline when a push occurs on the specified branch
Why this is correct
A CI trigger is authored under the YAML 'trigger:' key and fires only when a commit is pushed to a repository branch that matches the configured branch filters. It automatically queues a new run on a push event, independent of any pull request activity. Branch-level include/exclude rules and path filters allow precise control over when a pipeline runs on code changes.
PR trigger: Triggers a pipeline when a pull request is opened or updated
Why this is correct
The PR trigger, defined with the 'pr:' key in YAML, activates when a pull request is opened, reopened, or when new commits are pushed to the PR's source branch. It is integral to branch policy validation because it builds and tests the merged code before it reaches the target branch. You can scope it to target branches or paths, but the event itself is always a pull request lifecycle event, not a plain push.
Schedule trigger: Triggers a pipeline at scheduled times using cron syntax
Why this is correct
A schedule trigger uses the 'schedules:' keyword with a cron expression and a companion branch name to execute the pipeline at predetermined times, such as a nightly build. It is time-driven, so it runs even when no code or repository changes exist, making it suitable for periodic integration or maintenance tasks. The cron expression controls the exact minute, hour, day-of-month, month, and weekday, and the schedule is evaluated in the organization's time zone.
Pipeline trigger: Triggers a pipeline on the completion of another pipeline
Why this is correct
A pipeline trigger is declared inside the 'resources.pipelines' section of the YAML and references another pipeline in the same project. When that upstream pipeline completes a run that matches the specified branch criteria, it automatically starts a run of the dependent pipeline. This allows you to chain pipelines, but keep in mind that by default the trigger fires on any completion status; you need an explicit condition such as 'succeeded()' to require a successful upstream run.
CI trigger: Triggers a pipeline when a pull request is opened
Why it's wrong here
This description is incorrect because CI triggers respond to push events, not to the opening of a pull request. A CI trigger will run when you push a commit to a branch, including the source branch of a pull request, but the event that starts the run is still a push, not the PR open event. The YAML construct that handles pull request opened/updated events is 'pr:', so this behavior actually belongs to a PR trigger.
PR trigger: Triggers a pipeline on completion of another pipeline
Why it's wrong here
This description is incorrect because PR triggers listen for pull request events like open, synchronize, and update; they have no mechanism to detect whether another pipeline has finished. The action described here is exactly what a pipeline completion trigger does, using 'resources.pipelines' to reference an upstream pipeline and start the current pipeline when that upstream run concludes. Confusing these two would lead you to add a 'pr:' block when you actually intend to chain pipeline runs.
Go deeper
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
YAML pipeline
A YAML pipeline is a text-based file written in YAML format that defines an automated series of steps for building, testing, and deploying software in a continuous integration and continuous delivery (CI/CD) system.
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
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.