Design and implement build and release pipelines →hardMultiple ChoiceObjective-mapped

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

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?

⚠ Common exam trap

Watch out — candidates often confuse tag-based strategies (like using the same tag or immutable tags) with the artifact-based approach, failing to realize that only publishing the image as a pipeline artifact guarantees the exact same image digest is used across all stages.

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

✓

Publish the container image as a pipeline artifact and reference it from each stage.

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.

Answer analysis

Option-by-option breakdown

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

✓
Publish the container image as a pipeline artifact and reference it from each stage.
Why this is correct
Pipeline artifacts are immutable and can be passed between stages as dependencies, ensuring that the container image built once at the initial stage is exactly the same binary consumed by subsequent stages. This prevents any drift or accidental variation from rebuilding or republishing the image, which is crucial for reproducible deployments.
✗
Use the same image tag in all stages, updating the tag as needed.
Why it's wrong here
Using the same mutable image tag across stages and updating it as needed is unreliable because tags like 'latest' can be overwritten at any time, causing different stages to pull different container images if the tag changes during the pipeline run. This lack of immutability breaks the guarantee that the exact same artifact is deployed to every environment.
✗
Enable immutable tags on the container registry to prevent overwrites.
Why it's wrong here
Enabling immutable tags on a container registry only prevents a tag from being overwritten after it is initially set. It does not establish a dependency graph between pipeline stages, so stages could still reference different tags or different repositories, and there is no guarantee that the same immutable tag resolves to the same image digest across every stage. Immutability also does not help if the tag is created anew or moved by a separate process during the run; the pipeline must explicitly transport the image's digest or a versioned artifact to ensure identical binaries.
✗
Rebuild the container image in each stage to ensure freshness.
Why it's wrong here
Rebuilding the container image in each stage introduces non-determinism because base image updates, dependency version ranges, or build-time variability can produce a different image for each stage, so the artifact tested in an earlier stage may not be the one deployed later. This undermines traceability and defeats the purpose of staged pipelines, which should promote identical artifacts.

Go deeper

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

Why each option matters

Option-by-option breakdown

Related to this question