Two Conditions That Trigger a Stage Only After Main Branch Success
You are implementing a release pipeline with multiple stages. You want to automatically trigger the next stage only if the previous stage succeeds and the build is from the 'main' branch. Which TWO conditions should you configure?
Quick Answer
Two settings work together here: setting the stage trigger to 'After stage' pointed at the previous stage ensures it only runs once that stage succeeds, and a separate condition checking Build.SourceBranch against refs/heads/main restricts execution to builds from main. succeeded() alone only checks prior-stage success — it says nothing about which branch triggered the build.
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 a condition that checks if the source branch is 'main'.
The correct answers are A and B. To automatically trigger the next stage only when the previous stage succeeds and the build is from the 'main' branch, you need two configurations: first, set the stage trigger to 'After stage' and select the previous stage (option B), which ensures the stage runs after the previous stage completes successfully. Second, add a condition that checks the source branch—Option A correctly identifies this need, though the exact expression should be `eq(variables['Build.SourceBranch'], 'refs/heads/main')`. Option D is incorrect because `succeeded()` only checks that all previous stages succeeded but does not enforce the branch condition. Option C is wrong due to incorrect syntax (missing 'refs/heads/'). Option E is also incorrect because the syntax shown is not correct; the correct syntax requires 'refs/heads/main'.
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 a condition that checks if the source branch is 'main'.
Why this is correct
Required to restrict to main branch.
- ✓
Set the trigger on the stage to 'After stage' and select the previous stage.
Why this is correct
This ensures the previous stage succeeded.
- ✗
Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' to the stage.
Why it's wrong here
Missing 'refs/heads/main' syntax.
- ✗
Add a condition: 'succeeded()' to the stage.
Why it's wrong here
This only checks success, not branch.
- ✗
Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' with correct syntax.
Why it's wrong here
Correct syntax is 'refs/heads/main'.
Go deeper
Related to this question
Learn chapter
Source Control Strategy Design
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
Key term
Release pipeline
A Release pipeline is an automated sequence of steps that takes software from code commit to production deployment, ensuring quality and consistency.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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 configuring a multi-stage YAML pipeline that builds a .NET Core application and deploys it to Azure Kubernetes Service (AKS). The build stage produces a container image that is pushed to Azure Container Registry (ACR). The deploy stage needs to use the image from ACR. How should you pass the image tag from the build stage to the deploy stage?
medium- A.Write the image tag to a file and publish it as a build artifact, then read it in the deploy stage.
- B.Define a pipeline variable at the top level and set it in the build stage.
- ✓ C.Use the 'stageDependencies' syntax to retrieve the output variable of a job in the build stage.
- D.Use the 'Azure CLI' task in the deploy stage to query the ACR for the latest image tag.
Why C: Azure DevOps supports cross-stage output variables, allowing a job in the build stage to set a variable (e.g., imageTag) that can be consumed in the deploy stage using the stageDependencies syntax. This avoids the overhead of artifacts or external queries and ensures the exact tag produced during the build is used in deployment.
Variation 2. Your organization has a multi-stage YAML pipeline that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The pipeline uses environment approvals for the production stage. You need to ensure that the container image deployed to production is the same as the one that passed all previous stages. Which strategy should you implement?
hard- ✓ A.Publish the container image as a pipeline artifact and reference it from each stage.
- B.Use the same image tag in all stages, updating the tag as needed.
- C.Enable immutable tags on the container registry to prevent overwrites.
- D.Rebuild the container image in each stage to ensure freshness.
Why A: Publishing the container image as a pipeline artifact ensures that the exact same image (by digest, not just tag) is available to all stages. By referencing the artifact in each stage, you guarantee that the image deployed to production is identical to the one that passed testing, avoiding any risk of tag mutation or rebuild inconsistencies.
Variation 3. Your team uses Azure Pipelines to deploy a Docker container to Azure Kubernetes Service (AKS). The pipeline builds a Docker image, pushes it to Azure Container Registry (ACR), and then runs a deployment to AKS. You want to ensure that the deployment uses the exact image that was built in the same pipeline run. Which approach should you use?
medium- A.Use two separate pipelines: one for build/push, one for deploy, and share the image tag via a variable group.
- B.Use a single task for build and push, and rely on ACR's internal pull-through cache.
- ✓ C.Generate a unique tag (e.g., Build.BuildId) and pass it to both the Docker build and Kubernetes manifest via variable substitution.
- D.Tag the image as 'latest' and reference it in the Kubernetes manifest.
Why C: Using a unique tag like Build.BuildId ensures that the exact image built in the pipeline is referenced in the Kubernetes manifest. This prevents deployment from accidentally using a stale or overwritten image, as the tag is unique per run and passed consistently via variable substitution from the Docker build to the deployment YAML.
Variation 4. You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to dynamically set the image tag based on the build number. Which predefined variable should you use?
easy- A.$(System.JobId)
- B.$(System.TeamProject)
- ✓ C.$(Build.BuildNumber)
- D.$(Build.BuildId)
Why C: The `$(Build.BuildNumber)` variable represents the build number, which is the name of the completed build. It's often customized to include versioning information, and it's the appropriate variable to use when tagging Docker images based on the build number. `$(Build.BuildId)` is a unique numeric ID for the build record, but it is not the build number.
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.