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
Two runs would require both a pr trigger firing on PR creation and a trigger firing on the merge push; the exhibit does not configure both for this scenario. It is tempting because CI pipelines commonly validate PRs and then rebuild main, and would be correct if both trigger types were properly defined.
- ✗
The pipeline runs automatically on the PR to main, triggered by the pr trigger.
Why it's wrong here
A pr trigger only runs when the pipeline's YAML exists on the target branch and the pr block is configured; the exhibit's pr configuration does not cover this scenario as stated. It is tempting because PR validation builds are exactly what pr triggers provide, and would be correct if the branch policy and pr block matched.
- ✗
The pipeline runs when the PR is merged to main, triggered by the trigger block.
Why it's wrong here
The trigger block fires on pushes to main, including the merge commit, but the question asks about PR creation, where no push to main occurs yet. It is tempting because trigger genuinely governs post-merge CI runs, and would be correct if the question asked what happens after the pull request completes.
- ✓
The pipeline does not run automatically on the PR; it must be triggered manually or via branch policy.
Why this is correct
Without a PR trigger or branch policy configured in the YAML, the pipeline has no event that fires on pull request creation, so it stays idle until manually queued or invoked by a build validation policy.
Go deeper
Related to this question
Learn chapter
Implementing Security and Compliance in Pipelines
Key term
Azure Repos
Azure Repos is a set of version control tools that allow teams to manage their source code, track changes, and collaborate on software projects using Git or Team Foundation Version Control (TFVC) within the Microsoft Azure ecosystem.
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.
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
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 pipeline did not trigger on a commit to the 'develop' branch. The most likely reason is that the YAML pipeline's trigger is configured to only include the 'main' branch, so commits to 'develop' are ignored. Azure Pipelines CI triggers default to all branches unless specified, but if the trigger explicitly includes only 'main', then 'develop' commits won't trigger. Other options are less likely: manual trigger would require explicit run, but the question implies automatic trigger expected; CI trigger disabled would prevent any automatic trigger, but the question specifies 'develop' branch, suggesting other branches might work; pool availability would cause failure after trigger, not prevent trigger.
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.