AZ-400 Practice Question: Design and implement build and release pipelines
Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a pipeline that automatically builds and tests a Python application on every pull request to the main branch, but only if the pull request is from a fork. The pipeline must also publish test results as a build artifact. What should you do?
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
✓
Configure a branch protection rule on main that requires status checks from Azure Pipelines. Set the pipeline trigger to 'Pull request validation' and include a condition to run only if the pull request is from a fork.
It configures a branch protection rule on the main branch that requires status checks from Azure Pipelines. By setting the pipeline trigger to 'Pull request validation' and including a condition to run only if the pull request is from a fork, the pipeline automatically builds and tests the Python application on every pull request from a fork to main. The pipeline can also publish test results as a build artifact. Option A is incorrect because GitHub Actions is not Azure Pipelines; the requirement specifies using Azure Pipelines for CI/CD. Option B is incorrect because a scheduled trigger polling for PRs is inefficient and not the proper way to handle PR events. Option C is incorrect because a pipeline completion trigger runs after a merge, not on pull requests.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use GitHub Actions to build and test the application on PRs, and then trigger Azure Pipelines for deployment.
Why it's wrong here
This does use Azure Pipelines for deployment, but the PR validation itself is performed by GitHub Actions, not Azure Pipelines. Since the requirement is to use Azure Pipelines for validation, this fails because the status check reported to the branch protection rule would come from GitHub Actions, not Azure Pipelines, so the pipeline is not the gatekeeper.
- ✗
Use a scheduled trigger to run the pipeline every hour and check for new PRs from forks.
Why it's wrong here
A scheduled trigger checks for new PRs periodically (e.g., hourly), so it is not event-driven and cannot provide real-time validation status on the PR. Azure Pipelines has no native mechanism to 'discover' PRs on a schedule; you would need to query the GitHub API, and even then the status check would not appear promptly on the PR as required by branch protection.
- ✗
Set up a pipeline completion trigger on the main branch that runs the pipeline after every merge.
Why it's wrong here
A pipeline completion trigger on main runs after a merge to main, which is post-validation and does not affect the PR's mergeability. Branch protection requires a status check to be reported on the pull request itself, before it is merged, so this option cannot enforce validation on incoming fork PRs; it only validates the merged code after the fact.
- ✓
Configure a branch protection rule on main that requires status checks from Azure Pipelines. Set the pipeline trigger to 'Pull request validation' and include a condition to run only if the pull request is from a fork.
Why this is correct
This correctly uses Azure Pipelines as the PR validation engine: setting the pipeline trigger to 'Pull request validation' makes Azure Pipelines run on each PR, and the condition limits it to fork PRs. The branch protection rule on main then requires the Azure Pipelines status check to pass before the PR can be merged, enforcing validation as a merge gate.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Build artifact
A build artifact is the packaged, deployable output created by a build process, such as a compiled binary, ZIP file, or container image, that is stored for later use in testing or release.
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
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 →
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.