Using dependsOn: [] to Run Pipeline Stages in Parallel
You are implementing a multi-stage YAML pipeline in Azure Pipelines for a microservices application. You need to ensure that the 'deploy' stage only runs if the 'build' stage succeeds and that the 'test' stage runs in parallel with 'build' for different services. How should you structure the pipeline?
Quick Answer
Setting dependsOn: [] on the test stage removes its default dependency on the previous stage, so it starts in parallel with build instead of waiting for it. Leaving deploy's dependsOn: build in place ensures it still only runs once build succeeds. Stages without an explicit dependsOn run sequentially by default, so this override is what actually creates the parallelism.
⚠ Common exam trap
A common mix-up: candidates assume stages always run sequentially by default and overlook the `dependsOn: []` syntax to break the implicit dependency chain, leading them to choose options that enforce sequential execution or incorrect conditions.
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 stages 'build', 'test', 'deploy' with 'dependsOn: []' on 'test' and 'dependsOn: build' on 'deploy'
Setting `dependsOn: []` on the 'test' stage removes any implicit dependency, allowing it to run in parallel with the 'build' stage (since stages without explicit dependencies default to running sequentially after the previous stage). The 'deploy' stage with `dependsOn: build` ensures it only runs after the 'build' stage succeeds, as Azure Pipelines stages by default only run if all dependencies succeed. This structure meets the requirement: 'test' runs in parallel with 'build' for different services, and 'deploy' depends on 'build' success.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Define stages 'build', 'test', 'deploy' with 'dependsOn: []' on 'test' and 'dependsOn: build' on 'deploy'
Why this is correct
test runs in parallel with build because it has no dependencies; deploy runs after build.
- ✗
Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy' but use 'condition: always()' on test
Why it's wrong here
condition: always() does not change parallelism; test still depends on build.
- ✗
Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy'
Why it's wrong here
This makes test sequential after build, not parallel.
- ✗
Define stages 'build', 'test', 'deploy' with no dependsOn; by default they run sequentially
Why it's wrong here
Default is sequential, so test runs after build, not parallel.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Azure Pipelines
Azure Pipelines is a cloud-based CI/CD service from Microsoft that automatically builds, tests, and deploys code to any platform or cloud.
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 →
Same concept, more angles
4 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. You are designing a multi-stage YAML pipeline for a .NET Core application. The pipeline must build, test, and deploy to a staging environment. You want to ensure that the deployment stage only runs if the build and test stages succeed, and that the staging deployment uses the exact same bits that were built. Which strategy should you use?
medium- A.Set up a release pipeline that uses the same build artifact and requires manual approval.
- ✓ B.Create separate stages for build, test, and deploy. Use the 'dependsOn' keyword and publish artifact in build stage, download in deploy stage.
- C.Use a build trigger on the staging branch to deploy after each commit, ignoring test results.
- D.Define the pipeline with a single stage and use a condition to skip test on failure.
Why B: Using separate stages with 'dependsOn' ensures the deployment stage only runs after successful build and test stages. Publishing the build artifact in the build stage and downloading it in the deploy stage guarantees that the exact same compiled bits are used for deployment, maintaining consistency across environments.
Variation 2. You are creating a YAML pipeline that builds a .NET Core application. The pipeline must use a multi-stage build with separate stages for 'Build', 'Test', and 'Deploy'. The 'Deploy' stage should only run if both 'Build' and 'Test' succeed. Which two conditions can you use to achieve this? (Select all that apply.)
hard- ✓ A.In the Deploy stage, set 'dependsOn: [Build, Test]'
- B.In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'
- ✓ C.In the Deploy stage, set 'condition: succeeded()' and 'dependsOn: [Build, Test]'
- D.In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''
Why A: Setting 'dependsOn: [Build, Test]' in the Deploy stage ensures that the Deploy stage only starts after both the Build and Test stages have completed. By default, a stage runs only if all its dependencies succeed, so this alone meets the requirement without needing an explicit condition. This is the standard way to enforce sequential execution in multi-stage YAML pipelines.
Variation 3. You have a multi-stage YAML pipeline with stages: Build, Test, and Deploy. The Deploy stage requires approval from a specific user group. You want to ensure that the approval request is sent only after the Test stage completes successfully. Which configuration should you use?
hard- A.Add a manual validation task in the Deploy stage.
- ✓ B.Define an environment with required approvers and reference it in the Deploy stage.
- C.Use the 'condition' keyword: condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
- D.Configure branch policies on the main branch.
Why B: Azure Pipelines environments allow you to define required approvers (user groups) that must approve a deployment before it proceeds. By referencing the environment in the Deploy stage, the approval request is automatically triggered only after the preceding Test stage completes successfully, since stages execute sequentially by default.
Variation 4. Your team uses a multi-stage YAML pipeline. The 'Build' stage compiles the code and runs unit tests. The 'Deploy' stage deploys to a staging environment. You notice that if the 'Build' stage fails, the 'Deploy' stage still starts because it depends on a condition that always evaluates to true. How should you modify the pipeline to prevent the 'Deploy' stage from running if the 'Build' stage fails?
medium- ✓ A.Add 'condition: succeeded()' to the Deploy stage.
- B.Add 'condition: eq(variables['Build.Succeeded'], 'true')' to the Deploy stage.
- C.Add 'condition: and(succeeded(), eq(variables['Build.Succeeded'], 'true'))' to the Deploy stage.
- D.Add 'dependsOn: Build' to the Deploy stage.
Why A: The `succeeded()` function in Azure Pipelines evaluates whether all previous stages (or jobs, depending on context) have completed successfully. By adding `condition: succeeded()` to the Deploy stage, the stage will only run if the Build stage (its implicit or explicit dependency) succeeded. This directly prevents the Deploy stage from starting when the Build stage fails.
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.