Using dependsOn: [] to Run Pipeline Stages in Parallel
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.)
⚠ Common exam trap
A common mix-up: candidates confuse the 'succeeded()' function with the ability to check individual stage results, leading them to incorrectly select Option B, or they misremember the exact syntax for accessing stage dependencies in Option D.
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
✓
In the Deploy stage, set 'dependsOn: [Build, Test]'
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
In the Deploy stage, set 'dependsOn: [Build, Test]'
Why this is correct
Setting 'dependsOn: [Build, Test]' is correct because the default stage condition is 'succeeded()', which evaluates to true only if all explicitly listed dependency stages (Build and Test) complete successfully. This ensures Deploy runs only after both stages succeed without requiring an explicit condition.
- ✗
In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'
Why it's wrong here
The condition 'and(succeeded('Build'), succeeded('Test'))' is invalid because the 'succeeded()' function does not accept a stage name as an argument in YAML pipeline conditions. To reference stage results, you must use stage dependencies such as 'stageDependencies.Build.result', not pass names to 'succeeded()'.
- ✓
In the Deploy stage, set 'condition: succeeded()' and 'dependsOn: [Build, Test]'
Why this is correct
Setting both 'condition: succeeded()' and 'dependsOn: [Build, Test]' is technically correct but redundant, as 'succeeded()' is already the default condition when dependencies are specified. The explicit condition adds no additional logic, so the stage still runs only if both Build and Test succeed.
- ✗
In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''
Why it's wrong here
This condition is wrong because it only checks the result of the Build stage (stageDependencies.Build.result) and ignores the Test stage, so Deploy could run even if Test fails. Additionally, a proper multi-stage condition would need to reference both stage results, and relying solely on the default 'succeeded()' with 'dependsOn' is the standard approach.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-400 exam frequently reuses these exact scenarios with slightly different constraints.
✓In the Deploy stage, set 'dependsOn: [Build, Test]'Correct answer▾
Why this is correct
Setting 'dependsOn: [Build, Test]' is correct because the default stage condition is 'succeeded()', which evaluates to true only if all explicitly listed dependency stages (Build and Test) complete successfully. This ensures Deploy runs only after both stages succeed without requiring an explicit condition.
✗In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'Wrong answer — click to see why▾
Why this is wrong here
This syntax is for job conditions; stage conditions do not accept string arguments for succeeded().
✗In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''Wrong answer — click to see why▾
Why this is wrong here
'stageDependencies' is not a valid expression; you would use 'dependencies.Build.result'.
Analysis generated from the official AZ-400blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Implementing a Build Pipeline
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
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
3 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 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 2. 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.
Variation 3. 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.
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.