Courseiva
Design and implement build and release pipelineseasyMultiple ChoiceObjective-mapped

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

You are responsible for a release pipeline that deploys a containerized application to Azure Kubernetes Service (AKS). The pipeline currently builds and pushes a Docker image to Azure Container Registry (ACR) and then updates the Kubernetes manifest. You need to implement a rollback strategy in case the deployment fails. The rollback should revert to the previous known good version of the application. Which approach should you use?

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 Kubernetes task with the 'rollback' option, which runs 'kubectl rollout undo' on the deployment.

'kubectl rollout undo' is a native Kubernetes feature that automatically reverts the deployment to the previous ReplicaSet, providing a simple and reliable rollback without manual intervention or additional tools. Option A is manual and not automated. Option B re-runs the entire pipeline, which may build a new image and not truly revert to the previous version. Option D uses Helm, which adds complexity when native rollback is sufficient.

Answer analysis

Option-by-option breakdown

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

  • Keep the previous Docker image tag in ACR and update the manifest to point to it manually.

    Why it's wrong here

    Manually pointing the ACR image tag to the previous tag and updating the manifest is a manual, error-prone process that does not automate rollback. It also only changes the image reference, leaving other Kubernetes resource changes (env vars, configmaps, replicas) from the failed release intact, and it bypasses the Deployment controller's revision history.

  • Rerun the previous successful pipeline run.

    Why it's wrong here

    Rerunning a previous successful pipeline run does not restore the previously deployed Kubernetes revision because it re-executes the build and deployment steps, typically producing a new image tag and applying the manifest again. This can create a different pod template (e.g., new commit hash, new tag) and may not match the exact state that was deployed successfully before.

  • Use the Kubernetes task with the 'rollback' option, which runs 'kubectl rollout undo' on the deployment.

    Why this is correct

    The Kubernetes task's 'rollback' option invokes 'kubectl rollout undo deployment/<name>', which instructs the Kubernetes Deployment controller to revert to the previously recorded ReplicaSet revision. This restores the exact previous pod template (image, env vars, labels, etc.) automatically and is the built-in, native rollback mechanism for Deployments.

  • Use Helm to manage releases and rollback using 'helm rollback' command.

    Why it's wrong here

    Helm rollback is valid only if the release was originally deployed with Helm, and this pipeline does not currently use Helm charts. Introducing Helm just for rollback would add significant complexity and require rearchitecting the existing pipeline; the native Kubernetes task already provides a simpler, direct rollback capability.

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 →

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.