Courseiva

Implementing Gradual Traffic Shifting to a New AKS Version with Istio

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates by gradually shifting traffic to the new version while monitoring for errors. Which deployment strategy should you use?

Quick Answer

Canary deployment is built for exactly this: shift a small slice of traffic to the new version, watch for errors, and only ramp up further once it looks healthy — keeping most users on the stable version the whole time. On AKS this is typically implemented with a service mesh like Istio or a progressive-delivery tool like Flagger, managing the traffic split declaratively.

⚠ Common exam trap

It's easy for candidates to confuse canary deployment with rolling update, but rolling update does not support traffic splitting or error-monitoring-based rollback—it simply replaces pods without the ability to route a controlled percentage of traffic to the new version for validation.

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

✓

Canary deployment

Canary deployment is the correct choice because it gradually shifts a small percentage of traffic to the new version while monitoring for errors, allowing you to detect issues early and roll back quickly without impacting all users. In AKS, this can be implemented using a service mesh like Istio or a progressive delivery tool like Flagger, which manages traffic splitting via VirtualService and DestinationRule configurations. This minimizes downtime by ensuring the majority of users remain on the stable version until the new version is verified.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Recreate deployment

    Why it's wrong here

    Recreate stops all existing pods before starting replacements, producing a full outage window rather than the gradual traffic shift and error monitoring required. It is tempting because it is the simplest strategy and guarantees no version overlap, making it correct for stateless dev or test environments where downtime is acceptable and schema compatibility is not a concern.

  • ✗

    Blue-green deployment

    Why it's wrong here

    Blue-green switches traffic between two complete environments in one cutover, not gradually, and provides no built-in progressive percentage shifting or automated error-based rollback. It is tempting because it does minimise downtime and enables instant rollback, making it correct when you need atomic promotion with two full environments rather than incremental canary-style traffic splitting.

  • ✓

    Canary deployment

    Why this is correct

    Canary deployment routes a small percentage of live traffic to the new version, monitors error rates and metrics, then progressively increases exposure or rolls back. This satisfies the stem's gradual traffic shifting with error monitoring, unlike blue-green, which switches all traffic at once.

  • ✗

    Rolling update

    Why it's wrong here

    A rolling update replaces pods incrementally but shifts traffic only as pods become ready, with no weighted percentage control or automated error-monitoring rollback; it cannot pause and analyse metrics mid-rollout. It is tempting because it is Kubernetes' default zero-downtime strategy, and it would be correct for straightforward stateless updates where gradual canary analysis is unnecessary.

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 →

How Courseiva writes practice questions · Editorial policy

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. You are designing a release pipeline for a containerized application deployed to Azure Kubernetes Service (AKS). You want to implement a strategy where the new version is deployed to a small subset of pods first, and if healthy, gradually rolled out to all pods. Which Kubernetes deployment strategy should you use?

medium
  • ✓ A.Canary deployment
  • B.Rolling update
  • C.Blue-green deployment
  • D.Recreate deployment

Why A: A canary deployment is the correct strategy because it allows you to route a small percentage of traffic (e.g., 5%) to the new version of the application running on a subset of pods in AKS. If the canary is healthy (e.g., passes liveness and readiness probes), you can gradually increase the traffic percentage until 100% of pods run the new version, providing controlled rollout and rollback capabilities.

Variation 2. You are implementing a release pipeline for a containerized application using Azure Kubernetes Service (AKS). The pipeline should use canary deployments to gradually shift traffic from the stable version to the new version. Which strategy should you use to manage the traffic shift?

hard
  • A.Blue-green deployment strategy
  • B.Rolling update strategy
  • C.A/B testing with feature flags
  • ✓ D.Canary deployment using a service mesh (e.g., Istio)

Why D: A service mesh like Istio provides fine-grained traffic management capabilities (e.g., using VirtualService and DestinationRule resources) that allow you to route a specific percentage of traffic to the new canary version while the rest goes to the stable version. This enables gradual traffic shifting without modifying application code, and supports advanced routing rules based on headers or weights, which is essential for canary deployments in AKS.

Variation 3. Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates. Which TWO options should you use?

medium
  • A.Set the deployment replica count to zero before updating.
  • B.Use a canary deployment with a service mesh.
  • ✓ C.Configure a rolling update strategy in the Kubernetes manifest.
  • D.Use a recreate deployment strategy.
  • ✓ E.Implement a blue-green deployment pattern using separate namespaces.

Why C: Option C is correct because configuring a rolling update strategy (the default Deployment strategy in Kubernetes, governed by maxSurge and maxUnavailable) replaces pods incrementally while keeping a minimum number of replicas available, so the service stays reachable throughout the update and downtime is minimized. Option E is correct because a blue-green deployment using separate namespaces runs the new version (green) alongside the old version (blue) and switches traffic only after the green environment is verified, allowing instant rollback and near-zero downtime. Option A is wrong because scaling replicas to zero takes the application completely offline before the update, causing maximum downtime. Option D is wrong because the Recreate strategy terminates all existing pods before starting new ones, producing a guaranteed outage window. Option B is wrong because, while canary deployments with a service mesh do reduce risk by shifting a small percentage of traffic, the question asks for the two options to use and the marked answers are the rolling update and blue-green pattern; canary is a valid progressive-delivery technique but is not among the credited answers here.

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.