Skip to content

Blue-green and canary rollouts: CAPA practice questions

Argo Rollouts offers two update strategies, and each has its own vocabulary and fields.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Blue-green and canary rollouts covers in CAPA

Argo Rollouts offers two update strategies, and each has its own vocabulary and fields.

A blue-green Rollout runs the new version next to the old one and switches traffic in one move. It needs an activeService, the Service that receives production traffic, and usually a previewService that points at the new version for testing before promotion. When the Pod template changes, the controller creates a new ReplicaSet and points the preview Service at it, while the active Service stays on the old one. Once the new Pods are available, prePromotionAnalysis can run. autoPromotionEnabled defaults to true; set it to false and the Rollout pauses until someone promotes it, or set autoPromotionSeconds to promote after a delay. Promotion switches the active Service selector to the new ReplicaSet, postPromotionAnalysis can then run, and the old ReplicaSet is scaled down after scaleDownDelaySeconds, 30 seconds by default, which gives nodes time to update their routing. previewReplicaCount can run a smaller preview stack before promotion.

A canary Rollout shifts traffic in steps. The steps list combines setWeight, which sets the share of traffic for the canary, pause, which waits for a duration or, without one, indefinitely until promoted, analysis steps, and setCanaryScale, which sets the canary's replica count separately from its traffic weight. Without a traffic router, the controller approximates the weight with replica counts, so 25 percent with four replicas means one canary Pod. With a traffic router, such as Istio, NGINX, AWS ALB, SMI, Traefik or the Gateway API plugin, weights are set exactly and a canaryService and stableService let the router address each version. maxSurge and maxUnavailable control how fast Pods are replaced, and dynamicStableScale can scale the stable version down as the canary takes traffic.

Aborting either strategy sends traffic back to the stable version and scales the new ReplicaSet down, after abortScaleDownDelaySeconds where it applies. Both strategies can attach analysis: a canary in the background or as inline steps, a blue-green before and after promotion. The choice comes down to the risk being managed: blue-green gives an instant switch and an easy return, while a canary limits how many users meet a bad version.

Key points

  • Blue-green uses an activeService and a previewService; autoPromotionEnabled defaults to true.
  • The old blue-green ReplicaSet is scaled down after scaleDownDelaySeconds, 30 by default.
  • A canary pause without a duration waits until the Rollout is promoted.
  • Without a traffic router, canary weights are approximated by replica counts.

Three sample questions

14 CAPA questions on Blue-green and canary rollouts, 14 with explanations. How practice works

Question 1

What is the correct way to specify a blue-green deployment strategy? 
spec:
  strategy:
    blueGreen:
      activeService: active-svc
      previewService: preview-svc
  1. A.The configuration is correct
  2. B.activeService should be currentService
  3. C.Strategy should be under metadata
  4. D.blueGreen should be blue-green

Correct answer: A

For blue-green, strategy.blueGreen sits under the Rollout spec and needs activeService (mandatory) plus the optional previewService. The Argo Rollouts blue-green page shows exactly these two fields under spec.strategy.blueGreen. Why the other options are wrong. "activeService should be currentService": the field is activeService; there is no currentService in the blue-green spec. "Strategy should be under metadata": strategy is a field of the Rollout spec, not of metadata. "blueGreen should be blue-green": the key is blueGreen in camel case; the hyphenated blue-green is not a spec field.

Sources: Argo Rollouts docs: BlueGreen, Argo Rollouts docs: Rollout Specification

Question 2

What is the purpose of the 'autoPromotionEnabled' field in a blue-green deployment?
  1. A.To automatically scale the deployment up or down based on CPU load, as a HorizontalPodAutoscaler would
  2. B.To automatically promote the preview service to active
  3. C.To enable automatic rollbacks when the new ReplicaSet fails its readiness checks
  4. D.To enable progressive delivery

Correct answer: B

With autoPromotionEnabled left at its default, the rollout switches the active service to the new ReplicaSet as soon as it is fully available; setting it to false pauses just before promotion until promoted manually. The field therefore controls automatic promotion of the preview stack. Why the other options are wrong. "To automatically scale the deployment up or down based...": scaling is not what this field does; the spec only has scaleDownDelaySeconds for the old ReplicaSet. "To enable automatic rollbacks when the new ReplicaSet f...": the field controls promotion, not rollback; failed analysis is what aborts an update. "To enable progressive delivery": progressive delivery is the controller's overall capability and is not toggled by this field.

Sources: Argo Rollouts docs: BlueGreen, Argo Rollouts docs: Analysis & Progressive Delivery

Question 3

Which Rollout strategy keeps the previous ReplicaSet running behind a Service switch, so that a quick rollback only points the active Service selector back at it?
  1. A.They all keep the previous version running for the same time after an update
  2. B.Canary
  3. C.Blue-Green
  4. D.Rolling Update

Correct answer: C

In a blue-green Rollout the old ReplicaSet stays up for scaleDownDelaySeconds (30 seconds by default) after the switch. If the old manifest is applied again in that window, the FAQ describes a fast rollback: the controller immediately switches the active Service selector back to the old ReplicaSet. Why the other options are wrong. "They all keep the previous version running for the same...": the strategies differ; the Service switch with a scale-down delay is specific to blue-green. "Canary": a canary shifts traffic by setWeight steps toward the new version; it does not flip an active Service selector. "Rolling Update": a rolling update scales the old version down as the new one comes up, so there is nothing left to switch back to.

Sources: Argo Rollouts docs: FAQ, Argo Rollouts docs: BlueGreen Deployment Strategy, Argo Rollouts docs: Concepts

Practice this topic

Focus mode keeps every question on Blue-green and canary rollouts until you leave it. 10 free guest answers, then a free account; no credit card.

Or open CAPA practice across all topics.

Sources

The explanation above was checked against these official documents.