Courseiva
Configure processes and communicationsmediumMultiple ChoiceObjective-mapped

Why a Pull Request Doesn't Automatically Trigger a Build

Exhibit

Refer to the exhibit.
```yaml
# azure-pipelines.yml
trigger:
  branches:
    include:
      - main
      - release/*
pr:
  branches:
    include:
      - develop

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: '**/*.csproj'
- script: echo "Build completed"
```

Refer to the exhibit. You have this YAML pipeline in an Azure Repos repository. What is the expected behavior when a pull request is created from a feature branch to the main branch?

Quick Answer

Without an explicit pr: trigger block in the YAML, Azure Pipelines won't automatically run when a pull request is opened — the trigger: section only governs CI builds on branch pushes. The pipeline in this scenario has to be started manually or via a branch policy configured separately in the repository settings.

⚠ Common exam trap

Many exam-takers assume the `trigger` block also applies to pull requests, but in Azure Pipelines, `trigger` and `pr` are separate, and omitting `pr` means no automatic PR build occurs.

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 pipeline does not run automatically on the PR; it must be triggered manually or via branch policy.

The YAML pipeline shown does not include a `pr` trigger, and the `trigger` block only applies to CI (continuous integration) builds on branch pushes, not pull requests. Without a `pr` trigger, Azure Pipelines does not automatically run on pull request creation; it must be triggered manually or via a branch policy configured in the repository settings.

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 pipeline runs twice: once on PR creation and once on merge.

    Why it's wrong here

    No trigger is configured for PRs to main.

  • The pipeline runs automatically on the PR to main, triggered by the pr trigger.

    Why it's wrong here

    The pr trigger only includes 'develop' branch, not main.

  • The pipeline runs when the PR is merged to main, triggered by the trigger block.

    Why it's wrong here

    The trigger block runs on push to main, but not on PR creation.

  • The pipeline does not run automatically on the PR; it must be triggered manually or via branch policy.

    Why this is correct

    No automatic trigger for PRs to main; the pr trigger is only for develop.

Go deeper

Related to this question

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 →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

8 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 Azure Pipelines to build and test code. You want to automatically trigger a pipeline when a pull request is created targeting the main branch. Which trigger should you configure?

easy
  • A.PR trigger
  • B.Scheduled trigger
  • C.CI trigger
  • D.Manual trigger

Why A: A PR trigger is the correct choice because Azure Pipelines supports a 'pr' trigger that automatically starts a pipeline when a pull request is created targeting a specified branch (e.g., main). This is distinct from a CI trigger, which runs on commits to a branch, and is essential for validating changes before merging.

Variation 2. Your team needs to automatically run a pipeline whenever a pull request is created in GitHub. Which trigger should you configure in Azure Pipelines?

easy
  • A.Pipeline completion trigger
  • B.Scheduled trigger
  • C.Pull request trigger
  • D.Continuous integration trigger

Why C: Azure Pipelines provides a dedicated pull request trigger that automatically starts a pipeline when a pull request is created or updated in GitHub. This trigger validates proposed changes before merging, ensuring code quality and preventing broken builds from entering the main branch.

Variation 3. Refer to the exhibit. A developer commits code to the 'develop' branch. The pipeline does not trigger. What is the most likely reason?

medium
  • A.The trigger is configured to only run on the 'main' branch.
  • B.The pipeline requires a manual trigger.
  • C.The pipeline has a CI trigger disabled.
  • D.The pool 'ubuntu-latest' is not available.

Why A: The trigger is set to 'main' branch only. Commits to 'develop' will not trigger the pipeline.

Variation 4. You want to trigger a pipeline automatically when a new commit is pushed to the 'develop' branch of your repository. Which trigger configuration should you use in the YAML pipeline?

easy
  • A.schedules: - cron: "0 0 * * *" branches: include: - develop
  • B.pr: branches: include: - develop
  • C.resources: repositories: - repository: self trigger: branches: include: - develop
  • D.trigger: branches: include: - develop

Why C: Both C and D are valid ways to define a CI trigger on a push to the 'develop' branch. The top-level `trigger` (D) is the conventional and recommended syntax. A repository resource with `repository: self` and a `trigger` (C) is also an officially supported alternative. Options A and B are incorrect: A defines a schedule, and B defines a pull request trigger, not a direct push CI trigger.

Variation 5. Your team uses Azure Repos and wants to trigger a pipeline automatically when a pull request is created targeting the main branch. The pipeline should run validations and report the status to the PR. Which trigger type should you configure?

easy
  • A.Path filter
  • B.Scheduled trigger
  • C.PR trigger
  • D.CI trigger

Why C: A PR trigger is the correct choice because it specifically initiates a pipeline when a pull request is created or updated against a target branch (main). This allows the pipeline to run validations (e.g., builds, tests, linting) and report the status back to the PR via the Azure Repos status API, enabling branch protection policies to block merging if checks fail.

Variation 6. Your organization uses GitHub Actions for CI/CD. You need to ensure that workflows are only triggered when changes are pushed to the main branch or when a pull request is opened against main. Which two trigger types should you specify in the workflow?

easy
  • A.pull_request: branches: [ main ]
  • B.push: branches: [ main ]
  • C.release
  • D.workflow_dispatch
  • E.schedule

Why A: The `pull_request` trigger with `branches: [ main ]` ensures the workflow runs when a pull request is opened (or updated) targeting the main branch. Option B is correct because the `push` trigger with `branches: [ main ]` ensures the workflow runs when commits are pushed directly to the main branch. Together, these two triggers cover the exact requirement: changes pushed to main and pull requests opened against main.

Variation 7. Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to ensure that only pull requests from specific branches trigger a build pipeline. Which trigger configuration should you use?

easy
  • A.pr: paths: include: - main - develop
  • B.pr: branches: only: - main
  • C.trigger: branches: include: - main - develop
  • D.pr: branches: include: - main - develop

Why D: The `pr` trigger in Azure Pipelines controls which pull requests trigger a pipeline. By using `branches` with `include`, you specify that only PRs targeting the `main` and `develop` branches should trigger the build. This directly meets the requirement to restrict PR triggers to specific branches.

Variation 8. You need to trigger a pipeline whenever changes are pushed to the 'main' branch of a GitHub repository. Which trigger should you configure in the YAML pipeline?

easy
  • A.trigger: branches: include: - main
  • B.pr: branches: include: - main
  • C.resources: repositories: - repository: self trigger: branches: include: - main
  • D.schedules: - cron: "0 0 * * *" branches: include: - main

Why A: The `trigger` keyword at the root of a YAML pipeline defines the CI trigger that automatically starts a pipeline run when changes are pushed to the specified branch. By including `main` under `branches.include`, the pipeline will trigger on any push to the `main` branch of the GitHub repository, which is the standard way to set up a CI trigger for a single branch.

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.