A city wants near-instant rollback from green back to blue. Blue Pods are still running at reduced scale. What advantage does blue/green offer?
Select an answer to reveal the explanation.
Short Explanation
If blue never left the building, rollback is flipping the Service sign back—fast. You’re not stuck waiting for a slow unroll as long as blue capacity remains. Selectors aren’t carved in stone.
Full Explanation
When a city wants near-instant rollback from green back to blue and blue Pods are still running at reduced scale, blue/green’s advantage is that you can revert the Service selector to blue without waiting for a full rollout undo. Traffic shifts as Endpoints reconcile, restoring the previous municipal site quickly.
Rollback is not impossible until green’s ReplicaSet is garbage-collected—blue can receive traffic while green still exists. Helm rollback is not the only mechanism; Services can switch. kubectl rollout undo is useful for single-Deployment rolls but selectors are not immutable; blue/green rollback is often a selector patch.
Exam caveat: Keep blue warm during soak windows specifically to enable selector-based rollback.
Operational check: patch Service selector back to blue labels; kubectl get endpoints; confirm latency and error rates; scale green to zero after rollback stability. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.