Two Conditions That Trigger a Stage Only After Main Branch Success
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?
⚠ Common exam trap
Candidates often assume artifacts are the only way to pass data between stages, overlooking the built-in cross-stage variable feature that is more efficient and purpose-built for this scenario.
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
✓
Use the 'stageDependencies' syntax to retrieve the output variable of a job in the build stage.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Write the image tag to a file and publish it as a build artifact, then read it in the deploy stage.
Why it's wrong here
Writing the image tag to a file and publishing it as a build artifact introduces unnecessary I/O and artifact management overhead for a single string value. In a multi-stage YAML pipeline, the correct mechanism is to use pipeline variables (via `task.setvariable` or the `variables` directive) to pass the tag directly between stages in memory. This option is tempting because publishing build artifacts is the standard method for sharing compiled binaries or configuration files across stages, and it would be correct if the deploy stage needed to consume a full configuration file or binary output rather than a single runtime value.
- ✗
Define a pipeline variable at the top level and set it in the build stage.
Why it's wrong here
Pipeline variables defined at the top level are compile-time constants in Azure Pipelines; they cannot be reassigned during a pipeline run. Even if you attempt to set a variable from within a build job using `task.setvariable`, that only creates a job-scoped runtime variable, and a later stage will not see the updated value because the pipeline-level variable remains immutable. The only supported way to propagate a value from one stage to another is to mark it as an output variable (`isoutput=true`) and reference it through the `stageDependencies` context, not by assigning to a top-level pipeline variable.
- ✓
Use the 'stageDependencies' syntax to retrieve the output variable of a job in the build stage.
Why this is correct
Output variables are the intended mechanism for sharing a value between stages: a job in the build stage sets the variable with `task.setvariable` and `isoutput=true`, making it available in the job's output context. A subsequent stage's job can then retrieve that exact value at runtime using the syntax `$[stageDependencies.buildStage.buildJob.outputs['imageTag']]` in a variable definition, condition, or argument. This guarantees the consuming stage receives the precise tag produced by the build, independent of ordering or naming conventions, and avoids the overhead of publishing artifacts for a single string value.
- ✗
Use the 'Azure CLI' task in the deploy stage to query the ACR for the latest image tag.
Why it's wrong here
Querying the ACR for a tag named `latest` is inherently unreliable because `latest` is a mutable tag that can point to any image, and if multiple builds push images without updating the tag, the deploy stage may deploy the wrong version. Additionally, this approach requires the deploy stage to have the ACR name, image name, and appropriate Azure CLI authentication, adding external dependencies and potential credential-management issues. The correct solution captures the image tag at build time as an output variable and passes it through `stageDependencies`, which is simpler, more secure, and deterministic.
Go deeper
Related to this question
Learn chapter
Implementing a Build Pipeline
Key term
Variables
A variable is a named storage location in a computer program that holds a value which can change during execution.
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
One of 696 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
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. 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 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. 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.