Uma plataforma de varejo é executada em um Azure Virtual Machine Scale Set (VMSS) para sua camada de API, um App Service para o front-end da web e um Azure SQL Database. Você deve: 1) Alertar quando a CPU média do VMSS exceder 80% por 5 minutos (notificar o plantonista via SMS) e quando exceder 95% por 5 minutos (acionar o SRE via PagerDuty). 2) Transmitir logs de diagnóstico do App Service e do SQL para um workspace do Log Analytics e arquivá-los no Azure Storage por 365 dias. 3) Acionar um alerta quando os logs do App Service contiverem 'OrderTimeoutException' mais de 10 vezes em 5 minutos. O que você deve implementar?

A opção correta aborda todos os requisitos de forma precisa. Duas regras de alerta de métrica são necessárias para a CPU do VMSS, pois os limites e as ações são diferentes (80% para SMS, 95% para PagerDuty). As configurações de diagnóstico são o método padrão para enviar logs e métricas do App Service e do SQL para um workspace do Log Analytics (para análise e alertas) e uma conta de armazenamento (para arquivamento de longo prazo). Um alerta de consulta agendada do Log Analytics é a maneira correta de detectar padrões específicos em logs, como 'OrderTimeoutException' mais de 10 vezes em 5 minutos. As opções incorretas falham em um ou mais requisitos. A segunda opção sugere um alerta de métrica dinâmico entre assinaturas e alertas de Log de Atividades, que não se aplicam ou não são suficientes para os requisitos. A terceira opção propõe o Autoscale para notificações (não é o objetivo principal) e o Azure Policy para coleta de logs (não é a ferramenta principal para isso). A quarta opção sugere Smart Alerts e Event Hubs, que não atendem diretamente aos requisitos de arquivamento e alerta de log específicos. A quinta opção menciona uma regra de ação para severidade e o Azure Defender for Cloud, que não são as ferramentas apropriadas para os alertas e coleta de logs especificados.