AZ-400 Practice Question: Design and implement build and release pipelines
A development team is configuring a YAML-based pipeline in Azure Pipelines. The pipeline must meet the following requirements: - Build only the main branch. - Run integration tests after a successful build. - Deploy to a staging environment only if tests pass. - Handle failures gracefully by sending a notification to the team. You need to define the pipeline structure. Which TWO configurations should you include?
⚠ Common exam trap
A common mix-up: candidates confuse the `deployment` job keyword (which defines a deployment job but does not enforce stage dependencies) with the stage-level `dependsOn` and `condition` needed to gate deployment on test success, or they may mistakenly place the branch trigger in the `resources` section instead of the root `trigger`.
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
✓
Define a stage for 'Deploy' with `dependsOn: Test` and `condition: succeeded('Test')`.
It defines a 'Deploy' stage that depends on the 'Test' stage and uses `condition: succeeded('Test')` to ensure deployment only occurs after tests pass. This satisfies the requirement to deploy to staging only if tests succeed. Option C is correct because `trigger: main` at the pipeline root configures the pipeline to build only the main branch, meeting the first requirement.
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 a `deployment: Staging` job with `displayName: Deploy to staging`.
Why it's wrong here
Using a `deployment: Staging` job defines a deployment job that targets a staging resource, but it does not, by itself, establish any dependency on the Test stage or check whether tests passed. If placed in the same stage as the build job, it will run sequentially after the build job, irrespective of test outcomes, and even if placed in a later stage, it lacks the `dependsOn` and `condition` needed to gate deployment on successful tests. A deployment job is about how to deploy (with lifecycle hooks), not about when to deploy based on validation results.
- ✓
Define a stage for 'Deploy' with `dependsOn: Test` and `condition: succeeded('Test')`.
Why this is correct
The `dependsOn: Test` and `condition: succeeded('Test')` pair explicitly creates a stage dependency, ensuring the Deploy stage only executes if the Test stage completed with a success status. Without this condition, the default stage behavior would run stages sequentially only if previous stages succeeded, but this explicit syntax makes the gate unambiguous and allows for complex dependency graphs. This directly satisfies the requirement to deploy only after passing tests, as the condition checks the status of the Test stage before the Deploy stage starts.
- ✓
Set `trigger: main` at the pipeline root.
Why this is correct
Setting `trigger: main` at the pipeline root is the correct syntax for a branch trigger, which instructs the pipeline to run automatically whenever a commit is pushed to the `main` branch. This is a top-level YAML keyword, distinct from `resources.pipelines` which is used for pipeline resource triggers. By placing it at the root, you ensure the entire pipeline is bound to the main branch, meeting the requirement that the pipeline is triggered from that branch.
- ✗
Add `condition: succeeded()` to the build job.
Why it's wrong here
Adding `condition: succeeded()` to the build job is redundant because a build job runs by default when the pipeline is triggered, and the condition itself does not enforce any dependency on tests or control the deployment stage. The `succeeded()` function evaluates the overall job's status, but since the build job is the first job, it will always run on a valid trigger. This does nothing to gate the Deploy stage on test results, leaving the pipeline without the required post-test deployment check.
- ✗
Define the trigger in the `resources` section using `pipelines`.
Why it's wrong here
Defining a trigger in the `resources` section under `pipelines` is used to trigger this pipeline from another pipeline, not to set the branch trigger. The branch trigger should be set using `trigger:` at the pipeline root.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
Key term
Stage
A stage is a discrete phase in a software development or deployment pipeline where code is built, tested, integrated, or released in a controlled environment.
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 →
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.