AZ-400 Practice Question: Design and implement build and release 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.

• ✗

  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