Konfigurowane jest wdrożenie blue/green dla istniejącej trójwarstwowej aplikacji działającej na EC2 za ALB z grupami Auto Scaling. Środowiska blue i green mają własne szablony uruchamiania (launch templates), grupy Auto Scaling i grupy docelowe ALB. Ruch dla www.example.com jest obecnie kierowany do ALB. Wdrożenie musi przełączyć cały ruch jednocześnie z blue na green. Jaka sekwencja to osiągnie?

Poprawna odpowiedź to: "Wykonaj restart kroczący (rolling restart) grupy Auto Scaling środowiska green, aby wdrożyć nową wersję na instancjach green. Po zakończeniu restartu użyj AWS CLI, aby zaktualizować ALB do kierowania ruchu do zielonej grupy docelowej." Ta sekwencja jest prawidłowa, ponieważ wdrożenie blue/green wymaga przygotowania nowego środowiska (green) z nową wersją aplikacji, zanim ruch zostanie do niego przekierowany. Restart kroczący grupy Auto Scaling środowiska green zapewnia, że wszystkie nowe instancje zostaną uruchomione z zaktualizowaną aplikacją. Dopiero po upewnieniu się, że środowisko green jest gotowe i działa poprawnie, ALB jest aktualizowany, aby natychmiast przekierować cały ruch z blue na green. Pozostałe opcje są nieprawidłowe: Przekierowanie ruchu przed wdrożeniem nowej wersji spowodowałoby błędy dla użytkowników, ponieważ ruch byłby kierowany do środowiska green, które jeszcze nie ma nowej wersji. Aktualizacja szablonu uruchamiania środowiska blue nie jest metodą blue/green; to byłoby wdrożenie w miejscu (in-place deployment), które nie zapewnia szybkiego wycofania zmian. Zmiana rekordu Route 53 nie jest konieczna, ponieważ ALB jest już punktem końcowym dla www.example.com. Zamiast tego, ALB jest konfigurowany tak, aby kierował ruch do odpowiedniej grupy docelowej (blue lub green).