Courseiva
Develop a security and compliance planmediumMatchingObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

Match each YAML pipeline trigger to its behavior.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Runs pipeline on code push

Runs pipeline on pull request creation

Runs pipeline at specified times

Runs pipeline after another pipeline completes

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

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

Option-by-option breakdown

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.

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 →

How Courseiva writes practice questions · Editorial policy

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.