Laboratório de Troubleshooting: Monitor and Troubleshoot Networks by Using Azure Monitor for Networks
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações recebe reclamações de usuários de uma filial conectada ao Azure via VPN Gateway do tipo route-based. A aplicação hospedada em uma VM na VNet principal estava funcionando normalmente até três dias atrás. Agora, conexões TCP na porta 443 falham de forma consistente a partir da filial, enquanto o ping para o mesmo IP de destino retorna com sucesso.
O engenheiro responsável acessa o Connection Monitor e verifica o seguinte estado do test group configurado entre a filial e a VM de destino:
Test Group: branch-to-app
Source: on-premises-agent (10.50.0.10)
Destination: vm-app-prod (10.1.4.20) — Port 443 — TCP
Status: Fail
ChecksFailedPercent: 100
RoundTripTimeMs: 12 (when reachable)
LastUpdated: 2026-03-27T08:14:32Z
Informações adicionais coletadas pelo engenheiro:
- O VPN Gateway apresenta status Connected no portal
- O túnel IPsec mostra IKE Phase 2 estabelecido com sucesso
- O agente do Network Watcher na máquina on-premises foi atualizado há quatro dias
- O NSG associado à subnet da VM de destino foi modificado há três dias por um membro da equipe de segurança
- A VM de destino está com CPU abaixo de 20% e disco sem alertas
Qual é a causa raiz da falha observada?
A) O agente do Network Watcher foi atualizado com uma versão incompatível, corrompendo os testes TCP do Connection Monitor
B) Uma regra de NSG na subnet de destino está bloqueando o tráfego de entrada na porta 443 a partir do range de IP da filial
C) O túnel VPN está com problema de reestabelecimento de IKE Phase 1, causando perda seletiva de tráfego TCP
D) A VM de destino está com o serviço na porta 443 parado, pois o ping funciona mas o TCP falha
Cenário 2 — Sequência de Diagnóstico
Uma VM na subnet app-subnet (10.2.1.0/24) não consegue alcançar um endpoint externo na internet. A VM não possui Public IP associada e o acesso à internet é esperado via NAT Gateway configurado na subnet. O comportamento foi relatado após uma janela de manutenção realizada na noite anterior.
O engenheiro tem acesso aos seguintes passos de investigação disponíveis:
- Executar IP Flow Verify da VM de origem para o IP externo de destino na porta 443
- Verificar no portal se o NAT Gateway está associado à
app-subnet - Consultar o log de atividades do Resource Group para identificar alterações feitas durante a manutenção
- Analisar os NSG Flow Logs via Traffic Analytics para confirmar se o tráfego está sendo negado na saída
- Verificar as rotas efetivas na NIC da VM para confirmar se o next hop para o tráfego de internet aponta para o NAT Gateway
Qual é a sequência de diagnóstico correta para esse cenário?
A) 1 → 4 → 2 → 5 → 3
B) 3 → 2 → 5 → 1 → 4
C) 2 → 1 → 5 → 3 → 4
D) 5 → 3 → 1 → 2 → 4
Cenário 3 — Causa Raiz
Um time de plataforma opera um Application Gateway na frente de três VMs de backend. Usuários relatam que aproximadamente um terço das requisições retorna HTTP 502, enquanto os outros dois terços são atendidos normalmente. O comportamento é intermitente e não está associado a horários de pico.
O engenheiro acessa os Insights do Application Gateway no Azure Monitor for Networks e observa:
Backend Health:
backend-vm-01 (10.3.1.10:8080) — Healthy
backend-vm-02 (10.3.1.11:8080) — Unhealthy
backend-vm-03 (10.3.1.12:8080) — Healthy
Probe: custom-http-probe
Path: /healthz
Interval: 30s
Timeout: 10s
Informações adicionais:
- O Application Gateway foi redimensionado de Standard_v2 para WAF_v2 há cinco dias, sem relatos de problema naquele momento
- A subnet do Application Gateway tem um NSG associado com regras padrão e a regra de entrada para a porta 65200-65535 está presente
- A VM
backend-vm-02tem CPU em 87% de forma contínua nas últimas seis horas - Os logs de acesso do Application Gateway mostram que as requisições com 502 coincidem com tentativas de rotear para
backend-vm-02 - O time de desenvolvimento não alterou o endpoint
/healthznos últimos 30 dias
Qual é a causa raiz dos erros 502 observados?
A) O redimensionamento para WAF_v2 introduziu inspeção adicional que está rejeitando requisições antes de encaminhá-las ao backend
B) O NSG na subnet do Application Gateway está bloqueando o tráfego dos health probes para a backend-vm-02
C) A backend-vm-02 está com alta utilização de CPU, tornando-a incapaz de responder ao health probe dentro do timeout configurado, o que a marca como unhealthy e faz o gateway retornar 502 para as requisições roteadas a ela
D) O health probe está configurado com intervalo muito longo, permitindo que a backend-vm-02 falhe por períodos prolongados sem ser detectada
Cenário 4 — Decisão de Ação
A causa foi identificada: o Traffic Analytics apontou que um NSG aplicado na NIC de uma VM de produção contém uma regra de negação explícita na prioridade 100 bloqueando todo o tráfego de entrada na porta 5432, usada pelo banco de dados PostgreSQL. Essa regra foi criada erroneamente durante um procedimento de hardening realizado pela equipe de segurança. A aplicação está fora do ar há 40 minutos.
Restrições do ambiente:
- A VM de produção atende transações financeiras e qualquer interrupção adicional deve ser minimizada
- A equipe de segurança exige que qualquer alteração em NSGs de produção passe por aprovação formal registrada no sistema de change management, exceto em situações de incidente ativo com P1 declarado
- O incidente foi declarado como P1 há 35 minutos
- A equipe de segurança está disponível no canal de resposta a incidentes
- Existe uma regra de permissão na prioridade 200 que permite a porta 5432 a partir do range correto, mas ela está sendo sobreposta pela regra de negação na prioridade 100
Qual é a ação correta a tomar neste momento?
A) Aguardar a aprovação formal do change management antes de qualquer alteração, pois a política de segurança se aplica independentemente do tipo de incidente
B) Remover a regra de negação na prioridade 100 do NSG imediatamente, sem comunicar a equipe de segurança, para restaurar o serviço o mais rápido possível
C) Remover a regra de negação na prioridade 100 do NSG agora, com o incidente P1 ativo como justificativa, comunicando a equipe de segurança no canal de incidentes e registrando a ação no sistema de change management como emergencial
D) Criar uma nova regra de permissão com prioridade 50 para sobrepor a regra de negação, preservando o histórico de configuração sem deletar nenhuma regra existente
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na correlação temporal: o NSG da subnet de destino foi modificado há três dias, e as falhas começaram há três dias. O Connection Monitor confirma que o tráfego TCP na porta 443 falha com 100% de perda, enquanto o round-trip time registrado indica que há conectividade IP funcional entre origem e destino.
Ping utiliza ICMP, que é tratado por regras de NSG separadas das regras TCP. Se uma regra de negação foi adicionada especificamente para TCP/443, o ICMP continuaria passando, explicando exatamente o sintoma observado: ping com sucesso, TCP/443 falhando.
A informação irrelevante do enunciado é a atualização do agente do Network Watcher. Ela é mencionada explicitamente para atrair a atenção, mas o Connection Monitor ainda funciona e registra os dados corretamente, incluindo o percentual de falha. O agente não é a causa.
O distrator mais perigoso é o A, que culpa o agente. Um engenheiro que foca nessa informação perde tempo investigando o agente enquanto a causa real, uma regra de NSG, permanece ativa bloqueando produção. O distrator C é descartável pelos dados: o VPN Gateway está conectado com IKE Phase 2 estabelecido, e a latência registrada pelo Connection Monitor indica que pacotes chegam ao destino. O distrator D é refutado pelo mesmo raciocínio: ping funciona, o que confirma IP alcançável, mas o serviço na porta 443 poderia estar parado; contudo, a alteração no NSG no mesmo período das falhas é a evidência mais específica e direta.
Gabarito — Cenário 2
Resposta: B
A sequência correta é: 3 → 2 → 5 → 1 → 4.
O raciocínio diagnóstico correto parte do contexto mais amplo para o mais específico:
O primeiro passo é consultar o log de atividades (passo 3) porque houve uma janela de manutenção na noite anterior. Qualquer alteração feita nesse período é a hipótese mais provável para um problema que não existia antes. Identificar o que mudou é anterior a qualquer teste técnico.
Com o histórico em mãos, verifica-se se o NAT Gateway ainda está associado à subnet (passo 2), pois essa é a dependência crítica para o tráfego de saída sem Public IP. Se o NAT Gateway foi desassociado durante a manutenção, toda a investigação subsequente fica contextualizada.
Em seguida, verificam-se as rotas efetivas da NIC (passo 5) para confirmar se o plano de dados reflete o que o portal mostra. Uma associação de NAT Gateway pode aparecer correta no portal e ainda assim não estar refletida nas rotas efetivas por inconsistência temporária.
O IP Flow Verify (passo 1) valida se algum NSG está bloqueando o tráfego de saída antes que ele chegue ao NAT Gateway.
Por último, o Traffic Analytics via NSG Flow Logs (passo 4) é o passo mais demorado e detalhado, utilizado para confirmar padrões e coletar evidências, não para diagnóstico inicial.
As demais sequências invertem a lógica, iniciando por testes técnicos antes de entender o que mudou no ambiente, o que desperdiça tempo em cenários pós-manutenção.
Gabarito — Cenário 3
Resposta: C
O backend health nos Insights do Application Gateway mostra explicitamente que backend-vm-02 está Unhealthy. As requisições com 502 coincidem com tentativas de roteamento para essa VM. O health probe com timeout de 10 segundos e uma VM com CPU em 87% contínuo são os elementos que se conectam: sob alta carga, a VM não processa a requisição ao endpoint /healthz dentro do timeout, o probe falha, o Application Gateway marca o backend como unhealthy e retorna 502 para qualquer requisição roteada a ele.
O padrão de um terço das requisições falhando corresponde exatamente à distribuição round-robin entre três backends, dos quais um está unhealthy.
A informação irrelevante é o redimensionamento para WAF_v2. Ele ocorreu cinco dias antes, sem relatos de problema, enquanto o comportamento atual é recente e correlacionado com a carga da VM. Isso não elimina o WAF como hipótese em outros cenários, mas aqui a evidência direta do backend health torna essa linha desnecessária.
O distrator B (NSG bloqueando probes) é descartado porque: se o NSG bloqueasse os probes para backend-vm-02, a mesma regra provavelmente bloquearia para todas as VMs, pois as três estão na mesma subnet. As outras duas estão Healthy. O distrator D inverte a relação de causa e efeito: um intervalo longo atrasaria a detecção de falha, mas não causaria 502 continuamente enquanto o backend permanece marcado como unhealthy por outra razão.
Gabarito — Cenário 4
Resposta: C
O enunciado estabelece explicitamente que incidentes P1 ativos são a exceção à exigência de aprovação formal prévia. Com o incidente declarado há 35 minutos e a causa identificada com precisão pelo Traffic Analytics, a ação correta é remover a regra bloqueante imediatamente, com comunicação simultânea à equipe de segurança no canal de incidentes e registro emergencial no sistema de change management.
O distrator A ignora a exceção de P1 declarada explicitamente no enunciado. Aplicar a política padrão durante um incidente ativo com exceção prevista prolonga o impacto sem justificativa.
O distrator B comete o erro oposto: age corretamente na modificação técnica, mas descarta a comunicação e o registro. Isso cria um gap de governança e pode gerar conflito com a equipe de segurança sobre o estado do NSG após o incidente.
O distrator D é a alternativa mais tentadora e mais perigosa. Criar uma regra de prioridade 50 parece preservar o histórico, mas deixa a regra de negação na prioridade 100 no lugar. Dependendo do ciclo de vida do incidente e de futuras revisões de NSG, essa regra pode ser removida sem que alguém perceba que a regra de negação ainda está ativa, criando uma configuração ambígua e propensa a regressão.
Árvore de Troubleshooting: Monitor and Troubleshoot Networks by Using Azure Monitor for Networks
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o sintoma geral de falha de conectividade. A cada nó azul, responda objetivamente com o que você observa no ambiente: o Connection Monitor registra falha, o IP Flow Verify retorna Deny, o backend está Unhealthy. Siga o caminho correspondente à sua resposta. Nós laranjas indicam que você precisa coletar uma evidência adicional antes de prosseguir. Ao atingir um nó vermelho, a causa está identificada. O nó verde imediatamente relacionado indica a ação correta. Nunca pule perguntas para chegar mais rápido a uma causa: a árvore é projetada para eliminar hipóteses progressivamente, não para confirmar a primeira suspeita.