Laboratório Técnico: Monitor and Troubleshoot Networks by Using Azure Monitor for Networks
Questões
Questão 1 — Múltipla Escolha
Uma equipe de rede precisa identificar quais fluxos de tráfego estão sendo negados por um Network Security Group em uma subnet específica, sem acessar os logs de cada recurso individualmente. O analista quer uma solução nativa do Azure Monitor for Networks que permita visualizar esse comportamento de forma agregada.
Qual recurso deve ser utilizado?
A) Connection Monitor, configurado com testes de TCP para as portas relevantes da subnet
B) NSG Flow Logs analisados via Traffic Analytics no Azure Monitor for Networks
C) Network Watcher Packet Capture aplicado à NIC de cada VM na subnet
D) Azure Diagnostics Logs enviados ao Log Analytics via configuração de diagnostic settings no NSG
Questão 2 — Cenário Técnico
Um engenheiro analisa a conectividade entre duas VMs em VNets diferentes conectadas por VNet Peering. A VM de origem consegue fazer ping para a VM de destino, mas uma aplicação na porta 8080 falha silenciosamente. O engenheiro executa o seguinte no Network Watcher:
Ferramenta: IP Flow Verify
Origem: 10.1.0.4 (VM-A)
Destino: 10.2.0.5 (VM-B)
Porta: 8080
Protocolo: TCP
Direção: Outbound
O resultado retorna Allow. Qual é a conclusão mais precisa sobre o problema?
A) O IP Flow Verify confirmou que não há bloqueio de NSG na saída da VM-A, mas o problema pode estar em uma regra de NSG na NIC ou subnet de destino
B) O resultado Allow indica que o tráfego chega com sucesso à VM-B, descartando qualquer problema de rede
C) O VNet Peering não está funcionando corretamente, pois o Allow deveria retornar apenas para tráfego dentro da mesma VNet
D) O IP Flow Verify não é capaz de testar portas acima de 1024, tornando o resultado inválido para a porta 8080
Questão 3 — Múltipla Escolha
Uma organização deseja configurar alertas proativos sobre degradação de latência entre uma filial conectada via VPN Gateway e recursos no Azure. A equipe quer que o alerta seja baseado em métricas contínuas de round-trip time, sem depender de análise manual de logs.
Qual combinação de recursos atende corretamente a esse requisito?
A) Network Watcher Packet Capture agendado com exportação para Storage Account, analisado por Azure Functions
B) Connection Monitor com test group configurado entre o endpoint on-premises e o recurso Azure, com alerta baseado em métrica de latência
C) Traffic Analytics com threshold de latência configurado nas políticas de NSG Flow Logs
D) Azure Service Health com alertas de degradação de desempenho para o VPN Gateway na região
Questão 4 — Cenário Técnico
Uma empresa opera uma solução com Application Gateway na frente de um conjunto de VMs. Os usuários relatam falhas intermitentes com HTTP 502. O time de rede acessa o Azure Monitor for Networks e navega até a visão Insights do Application Gateway.
Ao analisar os dados disponíveis, qual informação presente nessa visão é mais relevante para identificar a causa raiz do erro 502?
A) A métrica de throughput total do Application Gateway, que indicaria saturação de banda
B) O status de saúde dos backends no backend health, que mostraria se os servidores estão sendo considerados unhealthy pelo probe
C) Os NSG Flow Logs associados à subnet do Application Gateway, que revelariam bloqueios de entrada
D) O log de atividades do Application Gateway, que registraria mudanças de configuração recentes
Questão 5 — Verdadeiro ou Falso
O Connection Monitor no Azure Monitor for Networks é capaz de monitorar conectividade entre endpoints que incluem máquinas on-premises, desde que o agente do Network Watcher esteja instalado nessas máquinas e haja conectividade de gerenciamento com o Azure.
Verdadeiro ou Falso?
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Traffic Analytics, alimentado pelos NSG Flow Logs, é o recurso projetado exatamente para esse cenário: ele processa os logs de fluxo de forma agregada e apresenta visualizações que distinguem tráfego permitido de negado, por subnet, por NSG e por direção, dentro da interface do Azure Monitor for Networks.
O principal erro dos distratores está na granularidade e no propósito de cada ferramenta. O Connection Monitor (A) testa conectividade ativa, não analisa histórico de bloqueios. O Packet Capture (C) exige ação manual por VM e não oferece visão agregada. Os Diagnostic Logs via diagnostic settings (D) enviam dados ao Log Analytics, mas exigem consultas KQL manuais e não entregam a visão consolidada que o Traffic Analytics já fornece nativamente.
Gabarito — Questão 2
Resposta: A
O IP Flow Verify avalia as regras de NSG aplicadas à NIC e subnet da VM de origem na direção especificada. Um resultado Allow na direção Outbound da VM-A confirma apenas que não há bloqueio saindo dessa VM. Ele não verifica as regras aplicadas à NIC ou subnet da VM-B na direção Inbound. Portanto, o problema pode estar em uma regra de NSG bloqueando a porta 8080 no destino.
A alternativa B representa o equívoco mais perigoso: interpretar Allow como garantia de entrega ponta a ponta. O IP Flow Verify é unidirecional e limitado ao ponto de origem configurado. A alternativa C é incorreta porque o VNet Peering não afeta o comportamento do IP Flow Verify. A alternativa D é falsa: a ferramenta suporta qualquer porta TCP/UDP válida.
Gabarito — Questão 3
Resposta: B
O Connection Monitor é o recurso nativo do Azure Monitor for Networks projetado para monitoramento contínuo e baseado em métricas entre endpoints, incluindo endpoints on-premises. Ele mede latência (round-trip time), perda de pacotes e disponibilidade de forma contínua, e expõe essas métricas no Azure Monitor, permitindo criar alertas automáticos com base em thresholds definidos.
O Packet Capture (A) é uma ferramenta de diagnóstico pontual, não de monitoramento contínuo. O Traffic Analytics (C) não possui configuração de threshold de latência; ele é focado em análise de fluxos e padrões de tráfego. O Azure Service Health (D) monitora a saúde da plataforma Azure, não a latência de conectividade específica de um cliente.
Gabarito — Questão 4
Resposta: B
O erro HTTP 502 no Application Gateway indica especificamente que o gateway recebeu uma resposta inválida ou não recebeu resposta do backend. A visão Insights do Application Gateway no Azure Monitor for Networks expõe o backend health, que mostra o estado de cada servidor backend conforme avaliado pelos health probes. Um backend marcado como unhealthy é a causa direta do 502.
A métrica de throughput (A) indicaria saturação, mas não é a causa típica de 502. Os NSG Flow Logs (C) poderiam revelar bloqueios, mas esse diagnóstico seria secundário e menos direto do que a saúde do backend. O log de atividades (D) registra operações de controle (mudanças de configuração), não o comportamento em tempo de execução do plano de dados, sendo útil para outro tipo de investigação.
Gabarito — Questão 5
Resposta: Verdadeiro
O Connection Monitor suporta endpoints híbridos. Máquinas on-premises podem ser incluídas como origem ou destino nos test groups, desde que o agente do Azure Monitor (anteriormente denominado agente do Log Analytics) ou o agente do Network Watcher esteja instalado na máquina e ela tenha conectividade de gerenciamento com o Azure, seja via ExpressRoute, VPN ou internet.
Esse comportamento é relevante porque distingue o Connection Monitor de ferramentas como o IP Flow Verify e o Packet Capture, que operam exclusivamente sobre recursos dentro do Azure. A capacidade híbrida do Connection Monitor é um diferencial direto para cenários de monitoramento de filiais e ambientes on-premises integrados ao Azure.