Uma equipe de DevOps implanta um aplicativo ECS atrás de um ALB usando o CodeDeploy com blue/green all-at-once. Um lançamento recente causou um grande aumento nos tempos de resposta e exigiu um rollback. A equipe deseja uma abordagem de implantação que permita observar uma nova versão antes de desviar todo o tráfego e fazer o rollback rapidamente se os tempos de resposta aumentarem. Qual combinação de etapas atende a isso?

A equipe precisa de uma estratégia que permita observar a nova versão antes de desviar todo o tráfego e fazer rollback rápido. A opção "Altere a configuração de implantação do CodeDeploy para CodeDeployDefault.ECSCanary10Percent5Minutes" é correta porque a implantação canário desvia uma pequena porcentagem do tráfego (10% neste caso) para a nova versão por um período (5 minutos), permitindo observação antes de desviar o restante. A opção "Crie um alarme do CloudWatch na métrica ALB TargetResponseTime que é acionado quando o tempo de resposta excede o limite. Associe o alarme ao grupo de implantação do CodeDeploy e configure o grupo para fazer rollback quando o limite do alarme for atingido" é correta porque monitora diretamente o tempo de resposta, que foi o problema inicial, e automatiza o rollback. As opções incorretas são: "CodeDeployDefault.ECSLinear10PercentEvery3Minutes" é uma estratégia linear, não canário, e embora desvie o tráfego gradualmente, não foca na observação inicial de uma pequena parte. "Alarme do CloudWatch na métrica ALB UnHealthyHostCount" monitora a saúde dos hosts, mas não o desempenho do aplicativo, que é o problema principal. "Alarme do CloudWatch na métrica ALB TargetConnectionErrorCount" monitora erros de conexão, mas não o tempo de resposta, que é o problema principal.