Laboratório Técnico: Set up alert rules, action groups, and alert processing rules in Azure Monitor
Questões
Questão 1 — Múltipla Escolha
Você precisa criar uma regra de alerta no Azure Monitor que dispare somente quando a utilização de CPU de uma máquina virtual específica ultrapassar 85% por pelo menos 5 minutos consecutivos. Ao configurar a regra, você percebe que há dois campos distintos: Threshold e Aggregation granularity (Period).
Qual é o papel correto do campo Aggregation granularity (Period) nesse cenário?
A. Define o valor percentual que a métrica deve atingir para que o alerta seja disparado.
B. Define o intervalo de tempo sobre o qual os pontos de dados são agregados antes de serem comparados ao threshold.
C. Define a frequência com que o Azure Monitor verifica se a condição do alerta foi violada.
D. Define por quanto tempo o alerta permanece no estado Fired antes de ser resolvido automaticamente.
Questão 2 — Cenário Técnico
Uma equipe de operações configurou a seguinte regra de alerta no Azure Monitor:
Recurso: Virtual Machine — vm-prod-01
Métrica: Percentage CPU
Condição: Maior que 90%
Agregação: Average
Período: 5 minutos
Frequência: 1 minuto
Severidade: Sev 1
Action Group: ag-ops-critical
Durante um incidente real, a CPU da vm-prod-01 ficou acima de 90% por 12 minutos. A equipe recebeu apenas uma notificação, mas esperava receber múltiplas. Qual é a explicação correta para esse comportamento?
A. O action group ag-ops-critical só permite o envio de uma notificação por hora por design.
B. A frequência de avaliação de 1 minuto impede múltiplos disparos enquanto a condição permanece ativa.
C. Enquanto o alerta permanece no estado Fired, ele não dispara novamente até ser resolvido e a condição ser violada novamente.
D. A métrica Percentage CPU tem uma restrição nativa que suprime notificações duplicadas em janelas inferiores a 15 minutos.
Questão 3 — Verdadeiro ou Falso
Um action group pode ser associado a regras de alerta de diferentes tipos, como alertas de métrica, alertas de log e alertas de integridade de serviço, sem necessidade de criar um action group separado para cada tipo.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
A equipe de segurança exige que, durante o período de manutenção programada (todo domingo entre 02:00 e 06:00 UTC), nenhuma notificação de alerta seja enviada para os canais de comunicação, mas os alertas devem continuar sendo avaliados e registrados no histórico do Azure Monitor.
Qual recurso do Azure Monitor deve ser utilizado para atender a esse requisito?
A. Desabilitar temporariamente as regras de alerta antes da janela de manutenção e reabilitá-las após o término.
B. Configurar uma alert processing rule do tipo Suppress notifications com um agendamento recorrente para o período definido.
C. Remover o action group das regras de alerta durante o período de manutenção e reatribuí-lo em seguida.
D. Configurar o action group para incluir um horário de silêncio diretamente nas propriedades de cada canal de notificação.
Questão 5 — Múltipla Escolha
Você está projetando um sistema de resposta a incidentes e precisa garantir que, quando um alerta de Sev 0 for disparado, as seguintes ações ocorram automaticamente:
- Envio de e-mail para a lista de plantão
- Criação de um ticket no ServiceNow via webhook
- Execução de um runbook de remediação no Azure Automation
Qual é a abordagem correta para configurar isso em um único action group?
A. Criar três action groups separados, um para cada tipo de ação, e associar todos à regra de alerta.
B. Criar um único action group contendo três action types distintos: Email/SMS/Push/Voice, Webhook e Automation Runbook.
C. Criar um único action group com uma ação do tipo Logic App, que internamente orquestra o e-mail, o webhook e o runbook.
D. Adicionar três regras de alerta idênticas, cada uma com um action group de ação única, para garantir execução paralela.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O campo Aggregation granularity (Period) define a janela de tempo usada para agregar os pontos de dados coletados antes de comparar o resultado ao threshold. No cenário descrito, os dados de CPU coletados ao longo de 5 minutos são agregados pela função escolhida (média, máximo etc.) e o valor resultante é então comparado ao limite de 85%.
O principal equívoco representado pelos distratores é confundir esse campo com o campo Evaluation frequency (alternativa C), que controla com que periodicidade o Azure Monitor executa a verificação da condição, e com o threshold em si (alternativa A). A alternativa D descreve o comportamento do estado do alerta, que é uma propriedade independente da janela de agregação.
Escolher errado aqui leva a configurar janelas inadequadas: uma janela muito curta pode gerar falsos positivos por picos momentâneos, enquanto uma janela muito longa pode atrasar a detecção de problemas reais.
Gabarito — Questão 2
Resposta: C
O Azure Monitor implementa o conceito de stateful alerts para alertas de métrica. Quando uma regra de alerta entra no estado Fired, ela permanece nesse estado enquanto a condição violadora persistir. Um novo disparo e uma nova notificação só ocorrem depois que o alerta retorna ao estado Resolved e a condição é violada novamente.
Esse comportamento é intencional para evitar notification storms, ou seja, o envio massivo de notificações repetidas durante um único incidente contínuo.
A alternativa B representa um equívoco comum: a frequência de avaliação define apenas com que regularidade a condição é verificada, não quantas notificações são enviadas. As alternativas A e D descrevem restrições fictícias que não existem na plataforma.
Gabarito — Questão 3
Resposta: Verdadeiro
Um action group é um recurso independente e reutilizável no Azure Monitor. Ele pode ser associado a qualquer tipo de regra de alerta suportada pela plataforma, incluindo alertas de métrica, alertas baseados em log (Log Analytics), alertas de Activity Log e alertas de integridade de serviço do Azure Service Health.
Esse design promove reuso e consistência operacional: a equipe mantém um conjunto centralizado de action groups e os associa a múltiplas regras de alerta de tipos diferentes, sem duplicação de configuração.
O equívoco oposto, acreditar que cada tipo de alerta exige seu próprio action group, levaria à proliferação desnecessária de recursos e aumentaria a probabilidade de inconsistências na resposta a incidentes.
Gabarito — Questão 4
Resposta: B
As alert processing rules (anteriormente chamadas de action rules) são o mecanismo correto para suprimir notificações sem interferir no ciclo de vida das regras de alerta. Ao configurar uma alert processing rule do tipo Suppress notifications com um agendamento recorrente, os alertas continuam sendo avaliados e registrados no histórico, mas as ações associadas aos action groups são bloqueadas durante a janela definida.
As alternativas A e C atendem ao requisito de silêncio superficialmente, mas introduzem riscos operacionais: desabilitar regras ou desvincular action groups manualmente exige intervenção humana, é suscetível a erros e pode resultar em alertas não registrados ou na falha em restabelecer a configuração original.
A alternativa D é incorreta porque os action groups não possuem configuração nativa de horário de silêncio por canal. Esse controle pertence à camada de alert processing rules.
Gabarito — Questão 5
Resposta: B
Um único action group suporta múltiplos action types configurados simultaneamente. No cenário descrito, os três requisitos mapeiam diretamente para tipos nativos disponíveis: Email/SMS/Push/Voice para a notificação à lista de plantão, Webhook para a integração com o ServiceNow, e Automation Runbook para a execução do runbook de remediação.
Todos os action types configurados em um action group são executados em paralelo quando o alerta é disparado, tornando desnecessária qualquer das abordagens das alternativas A e D.
A alternativa C é plausível em cenários de orquestração complexa, mas adiciona uma camada de indireção desnecessária quando os tipos nativos já cobrem os requisitos. Além disso, ela concentra a lógica em uma Logic App externa, aumentando a dependência e a complexidade operacional sem benefício técnico justificável nesse contexto.