AZ-400 Practice Question: Design and implement build and release pipelines
Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). Each microservice has its own pipeline that builds a Docker image and deploys it to a shared AKS cluster. The deployment must support rolling updates with zero downtime. You need to ensure that if a deployment fails (e.g., health check fails), the pipeline automatically rolls back to the previous version. Which deployment strategy should you implement in the pipeline?
⚠ Common exam trap
Test-takers frequently confuse 'monitoring and reporting failure' (Option C) with 'automatically executing a rollback'—the KubernetesManifest task's rollout status option only checks and reports, it does not perform the undo action; you must explicitly add a separate rollback step.
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 a rolling update strategy with the 'kubectl apply' command, and include a post-deployment step that checks the rollout status. If the rollout fails, run 'kubectl rollout undo' to roll back.
It directly implements the required behavior: using `kubectl apply` for a rolling update (which inherently supports zero-downtime by gradually replacing pods), followed by a post-deployment step that checks the rollout status. If the rollout fails (e.g., due to health check failures), the pipeline runs `kubectl rollout undo` to automatically revert to the previous version, ensuring rollback on failure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a canary deployment strategy with a pipeline task that gradually shifts traffic to the new version and monitors error rates. If errors exceed a threshold, the task stops the canary.
Why it's wrong here
Canary deployments incrementally route a small percentage of traffic to the new version and rely on a pipeline task to monitor error rates. When the threshold is breached, the task's only action is to stop the canary—meaning it halts further traffic shifting—but it does not remove the new version's pods or explicitly restore the old ReplicaSet. The previous version never left service, so the environment is not actually rolled back; the new version may still be running and need manual cleanup.
- ✓
Use a rolling update strategy with the 'kubectl apply' command, and include a post-deployment step that checks the rollout status. If the rollout fails, run 'kubectl rollout undo' to roll back.
Why this is correct
The default Kubernetes rolling update strategy, triggered by `kubectl apply`, replaces pods incrementally and waits for readiness probes before continuing, which minimizes downtime. Adding a post-deployment step that checks `kubectl rollout status` allows the pipeline to detect a stuck or failed rollout (e.g., crashlooping pods or failed readiness checks). If that status check returns a failure, running `kubectl rollout undo` reverts the Deployment to its previous ReplicaSet, restoring the last known-good configuration without custom scripting.
- ✗
Use the 'KubernetesManifest' task with the 'rollout status' option, which automatically rolls back if the rollout status indicates failure.
Why it's wrong here
The `KubernetesManifest` task's `rollout status` argument (via `kubectl rollout status`) only waits for and reports the rollout outcome; it does not invoke any rollback operation. When the status indicates failure, the task sets a failed pipeline result, but the broken Deployment remains in place unless you add an explicit follow-up step that calls `kubectl rollout undo` or uses the `undo` action. Relying on that option alone would therefore not restore the previous version automatically.
- ✗
Use a blue-green deployment strategy with two separate AKS clusters. Deploy the new version to the green cluster, run health checks, and then update the load balancer to point to green. If health checks fail, keep pointing to blue.
Why it's wrong here
A blue-green deployment across two separate AKS clusters requires duplicating the entire environment and maintaining a load balancer or DNS that can switch between clusters, which is far more infrastructure than needed for a microservices app. The pipeline would have to manually orchestrate the traffic switch and the decommissioning of the green cluster, and if health checks fail, it can only keep pointing to blue—leaving the deployed green version isolated but still consuming resources. Kubernetes already supports blue-green patterns within a single cluster using services and labels, so this multi-cluster approach adds complexity without any built-in rollback automation.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Azure Pipelines
Azure Pipelines is a cloud-based CI/CD service from Microsoft that automatically builds, tests, and deploys code to any platform or cloud.
Key term
Anthos
Anthos is a Google Cloud platform that lets you run applications consistently across different computing environments, like on-premises data centers and multiple public clouds.
About these practice questions
One of 823 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 →
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.