Pular para o conteúdo principal

Laboratório Técnico: Use Azure Network Watcher and Connection Monitor

Questões

Questão 1 — Múltipla Escolha

Um administrador precisa capturar todo o tráfego de entrada e saída de uma VM específica durante um intervalo de tempo limitado para análise forense. O arquivo gerado deve ser armazenado em uma conta de armazenamento e analisado posteriormente com uma ferramenta de análise de pacotes.

Qual recurso do Network Watcher é o mais adequado para essa necessidade?

A. Flow Logs do NSG, configurado para capturar tráfego na sub-rede da VM

B. Packet Capture, configurado diretamente na VM com destino à conta de armazenamento

C. Connection Monitor, com um endpoint de origem apontando para a VM

D. IP Flow Verify, executado com os parâmetros de origem e destino da VM


Questão 2 — Cenário Técnico

Uma equipe de operações relata que uma aplicação distribuída em duas regiões do Azure começou a apresentar latência intermitente entre dois endpoints. O time quer monitorar continuamente essa conectividade, receber alertas quando a latência ultrapassar um limiar e visualizar o histórico da degradação ao longo do tempo.

A equipe já tem o Network Watcher habilitado nas duas regiões.

Região A: VM de origem — 10.1.0.4
Região B: endpoint de destino — app.contoso.internal (porta 443)

Qual é a abordagem correta para atender a esse requisito?

A. Configurar o IP Flow Verify periodicamente via Azure Automation para testar a porta 443 entre as regiões

B. Criar um Connection Monitor com o endpoint de origem na Região A, o endpoint de destino na Região B e um test group com verificação TCP na porta 443

C. Habilitar os NSG Flow Logs nas duas regiões e criar alertas baseados em logs no Log Analytics

D. Usar o Network Performance Monitor clássico do Log Analytics, pois o Connection Monitor não suporta endpoints em regiões diferentes


Questão 3 — Verdadeiro ou Falso

O recurso IP Flow Verify do Network Watcher é capaz de identificar qual regra específica de um NSG está bloqueando ou permitindo um fluxo de tráfego, informando o nome da regra aplicada na decisão.

Verdadeiro ou Falso?


Questão 4 — Cenário Técnico

Um administrador executa o Next Hop do Network Watcher para diagnosticar por que o tráfego de uma VM não está chegando ao destino esperado. O resultado retornado é o seguinte:

Next hop type: None
Next hop IP: -
Route table: System

Qual é a interpretação correta desse resultado?

A. O tráfego está sendo encaminhado pela rota padrão do sistema para a Internet

B. Não existe rota válida para o destino informado; o tráfego está sendo descartado pela camada de roteamento

C. O próximo salto é uma NVA (Network Virtual Appliance), mas o endereço IP ainda não foi propagado

D. A VM de origem não possui um adaptador de rede configurado com IP estático, impedindo o cálculo da rota


Questão 5 — Múltipla Escolha

Ao comparar o Connection Monitor com o recurso legado Network Performance Monitor (NPM), qual afirmação descreve corretamente uma capacidade exclusiva ou ampliada do Connection Monitor?

A. O Connection Monitor é o único que permite testes baseados em ICMP entre VMs do Azure

B. O Connection Monitor suporta endpoints externos à rede do Azure, como URLs públicas e endereços fora da VNet, como origem ou destino dos testes

C. O Connection Monitor é o único recurso que requer o agente do Log Analytics instalado nas VMs para funcionar

D. O Connection Monitor substitui o NPM apenas para cenários híbridos; para tráfego exclusivamente dentro do Azure, o NPM ainda é a opção recomendada


Gabarito e Explicações

Gabarito — Questão 1

Resposta: B

O Packet Capture é o recurso do Network Watcher projetado exatamente para capturar pacotes diretamente em uma VM durante um período definido, com saída para uma conta de armazenamento ou para o sistema de arquivos local da VM. Ele instala uma extensão temporária na VM e opera no nível do adaptador de rede, produzindo arquivos .cap compatíveis com ferramentas como Wireshark.

Os distratores representam erros conceituais frequentes: o NSG Flow Logs registra metadados de fluxo (tuplas de 5 campos), não o conteúdo dos pacotes, e opera no nível do NSG, não da VM individualmente. O Connection Monitor monitora conectividade de forma contínua, sem capturar conteúdo de pacotes. O IP Flow Verify testa uma única combinação de fluxo de forma pontual e retorna apenas se seria permitido ou bloqueado, sem capturar nada.

Escolher o NSG Flow Logs nesse cenário resultaria em dados insuficientes para análise forense, pois os logs não contêm o payload nem os headers completos dos pacotes.


Gabarito — Questão 2

Resposta: B

O Connection Monitor é o recurso correto porque foi projetado exatamente para monitoramento contínuo de conectividade entre endpoints, com suporte a alertas baseados em limiares de latência e perda de pacotes, histórico persistido no Log Analytics e suporte nativo a endpoints em regiões diferentes do Azure, incluindo destinos por hostname e porta específica.

A alternativa A descreve um processo manual e reativo que não oferece histórico contínuo nem alertas nativos. A alternativa C confunde a finalidade dos NSG Flow Logs, que registram fluxos aprovados ou negados por NSGs, sem medir latência entre endpoints. A alternativa D é factualmente incorreta: o Connection Monitor substitui o NPM e suporta cenários multirregião, sendo o NPM considerado legado.


Gabarito — Questão 3

Resposta: Verdadeiro

O IP Flow Verify não apenas retorna se o tráfego seria permitido ou negado, mas também informa o nome da regra NSG que tomou a decisão. Isso é justamente o que o diferencia de uma simples verificação de conectividade: ele inspeciona a pilha de regras do NSG associado ao adaptador de rede (e ao NSG da sub-rede, se houver) e aponta qual regra específica foi acionada.

Esse comportamento é especialmente útil em diagnósticos porque permite identificar se o bloqueio veio de uma regra explícita criada pelo administrador ou de uma regra padrão do sistema, sem precisar revisar manualmente todas as regras configuradas.


Gabarito — Questão 4

Resposta: B

O resultado Next hop type: None indica que não existe nenhuma rota válida para o prefixo de destino informado. Nesse caso, o Azure descarta silenciosamente os pacotes endereçados a esse destino. Isso pode ocorrer quando o endereço de destino não pertence a nenhuma sub-rede conectada, a nenhuma rota personalizada (UDR) e a nenhuma rota de sistema aplicável.

A alternativa A descreve o comportamento esperado quando o Next hop type retornado é Internet, não None. A alternativa C descreve uma condição diferente, normalmente representada por um Next hop type: VirtualAppliance com um IP associado. A alternativa D é um distrator que mistura configuração de IP da VM com o funcionamento do roteamento de rede, que são camadas independentes: o Next Hop analisa a tabela de rotas efetivas, não a configuração de IP da VM.


Gabarito — Questão 5

Resposta: B

O Connection Monitor expande significativamente o escopo de endpoints suportados em relação ao NPM. Ele permite que tanto a origem quanto o destino sejam recursos fora da VNet do Azure, incluindo URLs públicas, endereços IP externos e endpoints on-premises, o que o torna adequado para monitorar a experiência de conectividade de ponta a ponta em cenários híbridos e de múltiplas nuvens.

A alternativa A é incorreta porque tanto o Connection Monitor quanto o NPM suportam ICMP. A alternativa C inverte a lógica: o Connection Monitor pode usar tanto o agente do Log Analytics quanto o Network Watcher Agent, e em alguns casos não exige agente nenhum para endpoints externos. A alternativa D é incorreta porque o Connection Monitor é a solução recomendada para todos os cenários, tendo o NPM sido marcado como legado pela Microsoft independentemente do tipo de tráfego monitorado.