A DevOps team wants to deploy a containerized application to a Kubernetes cluster with zero downtime. The team needs to gradually shift traffic from the old version to the new version, monitoring error rates and automatically rolling back if errors exceed a threshold. Which deployment strategy should the team implement?
Canary deployment routes a small percentage of traffic to the new version first, then gradually shifts the remainder while monitoring error rates. If errors exceed the threshold, traffic reverts to the old version, delivering the gradual shift, monitoring and automatic rollback the team requires.
Why this answer
Canary deployment is correct because it introduces the new version to a small subset of users/traffic first, allowing the team to monitor error rates and metrics in production before progressively shifting more traffic. If error thresholds are breached, traffic can be instantly routed back to the stable version, achieving zero-downtime with automated rollback. This matches the requirement for gradual traffic shifting with monitoring and automatic rollback.
Exam trap
The trap here is confusing rolling deployment with canary deployment — both are gradual, but only canary provides percentage-based traffic control with automated metric-driven rollback, which is what the question explicitly requires.
How to eliminate wrong answers
Option A is wrong because blue/green deployment switches all traffic at once between two identical environments, which does not provide gradual traffic shifting or fine-grained monitoring of a small user subset before full cutover. Option B is wrong because rolling deployment replaces pods incrementally but does not offer precise traffic-percentage control or the ability to route a defined slice of users to the new version for canary-style metric comparison. Option C is wrong because recreate deployment tears down the old version before starting the new one, causing downtime and offering no rollback automation.