Courseiva
Design and implement build and release pipelinesmediumMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

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?

⚠ Common exam trap

It's easy for candidates to think `dependsOn` alone enforces success, but it only sets the dependency order; without an explicit `condition: succeeded()`, a custom condition that always evaluates to true will still trigger the stage regardless of the dependency's status.

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

Add 'condition: succeeded()' to the Deploy stage.

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.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Add 'condition: succeeded()' to the Deploy stage.

    Why this is correct

    The 'succeeded()' function is a predefined pipeline expression that evaluates to true only if all prior stages and jobs in the pipeline have completed successfully, so adding 'condition: succeeded()' to the Deploy stage ensures it runs only after the Build stage succeeds, which is exactly the desired behavior.

  • Add 'condition: eq(variables['Build.Succeeded'], 'true')' to the Deploy stage.

    Why it's wrong here

    The expression 'variables['Build.Succeeded']' is invalid because 'Build.Succeeded' is not a predefined variable in Azure Pipelines; the correct predefined variable is 'Build.Status' or 'Agent.JobStatus', and even then, such a variable is not evaluated in the stage condition context, which requires the 'succeeded()' expression instead.

  • Add 'condition: and(succeeded(), eq(variables['Build.Succeeded'], 'true'))' to the Deploy stage.

    Why it's wrong here

    This condition is redundant and incorrect: 'succeeded()' already encapsulates the check that all previous stages succeeded, and adding 'eq(variables['Build.Succeeded'], 'true')' introduces an invalid variable reference that is not evaluated in the same context, making the expression both less readable and functionally wrong.

  • Add 'dependsOn: Build' to the Deploy stage.

    Why it's wrong here

    The 'dependsOn: Build' keyword only establishes the dependency order, ensuring the Deploy stage waits for the Build stage to complete, but it does not impose any success condition—so if the Build stage fails, the Deploy stage will still run, which is why a 'condition: succeeded()' is required.

Go deeper

Related to this question

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 →

How Courseiva writes practice questions · Editorial policy

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.