Pular para o conteúdo principal

Laboratório Técnico: Configure monitoring, network diagnostics, and logs in Azure Network Watcher

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de operações precisa verificar se o tráfego na porta 443 entre uma máquina virtual e um endereço IP público externo está sendo bloqueado por alguma regra de NSG aplicada à interface de rede ou à sub-rede. Qual ferramenta do Azure Network Watcher é a mais adequada para esse diagnóstico?

A) Connection Monitor, porque rastreia a latência e a disponibilidade de conexões ao longo do tempo.

B) IP Flow Verify, porque avalia se um pacote com parâmetros específicos seria permitido ou negado pelas regras de NSG aplicadas.

C) NSG Diagnostics, porque exibe o estado de saúde de todos os NSGs associados a uma VNet.

D) Packet Capture, porque intercepta o tráfego real na interface e permite identificar qual regra está atuando.

Questão 2 — Cenário Técnico​

Um engenheiro está analisando a conectividade entre duas VMs em regiões diferentes conectadas por VNet Peering. O Connection Monitor reporta perda de pacotes consistente, mas o IP Flow Verify retorna "Allow" para o tráfego nas duas direções. Considere a configuração abaixo:

Connection Monitor:
  Source: VM-A (East US)
  Destination: VM-B (West Europe), porta 8080
  Protocolo: TCP
  Status: Reachability Failed — Packet loss 100%

IP Flow Verify:
  Direção: Outbound (VM-A -> VM-B:8080) — Allow
  Direção: Inbound (VM-B <- VM-A:8080) — Allow

Qual é a causa mais provável para esse comportamento contraditório?

A) O Connection Monitor está configurado com um agente desatualizado na VM-A, gerando falsos negativos.

B) O IP Flow Verify verifica apenas regras de NSG, enquanto o bloqueio pode estar em uma camada diferente, como o firewall do sistema operacional da VM-B ou uma rota UDR que redireciona o tráfego para um NVA.

C) O VNet Peering entre regiões diferentes não suporta tráfego TCP na porta 8080 por limitação da plataforma.

D) O Connection Monitor requer que ambas as VMs estejam no mesmo workspace do Log Analytics para funcionar corretamente.

Questão 3 — Verdadeiro ou Falso​

O NSG Flow Logs no Azure Network Watcher registra cada pacote individualmente que passa por uma interface de rede, permitindo a reconstrução completa do payload das conexões para fins de auditoria.

Questão 4 — Cenário Técnico​

Uma empresa precisa monitorar de forma contínua e proativa a latência entre um conjunto de VMs no Azure e endpoints SaaS na internet. O SLA interno exige alertas automáticos quando a latência superar 150 ms. A equipe já tem um workspace do Log Analytics provisionado. Qual configuração atende a esse requisito de forma nativa dentro do Azure Network Watcher?

A) Habilitar Packet Capture agendado em todas as VMs de origem e processar os arquivos PCAP com scripts externos para calcular latência.

B) Criar um Connection Monitor com os endpoints SaaS como destinos, definir thresholds de latência e configurar alertas via Azure Monitor integrado ao workspace do Log Analytics existente.

C) Usar Network Performance Monitor no Log Analytics diretamente, pois o Connection Monitor não suporta endpoints externos à VNet.

D) Configurar Topology no Network Watcher para mapear os caminhos de rede e definir alertas de latência sobre o diagrama gerado.

Questão 5 — Múltipla Escolha​

Ao configurar o NSG Flow Logs versão 2, qual é a informação adicional disponível em comparação com a versão 1?

A) O nome da regra de NSG que tomou a decisão de permitir ou negar o fluxo.

B) Os dados de throughput do fluxo, incluindo bytes e pacotes transmitidos.

C) O endereço IP privado do recurso de destino dentro da VNet.

D) O protocolo de camada de aplicação identificado na conexão, como HTTP ou TLS.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O IP Flow Verify foi projetado exatamente para responder à pergunta "esse pacote seria permitido ou negado?". Ele recebe como entrada a direção, o protocolo, o IP de origem, o IP de destino e a porta, e avalia as regras de NSG aplicadas à NIC e à sub-rede naquele momento, retornando qual regra específica tomou a decisão.

O principal equívoco dos distratores está em confundir ferramentas de diagnóstico pontual com ferramentas de monitoramento contínuo. O Connection Monitor monitora disponibilidade e latência ao longo do tempo, não identifica regras de NSG. O Packet Capture intercepta tráfego real, mas exige análise posterior e não responde diretamente sobre qual regra está bloqueando. O "NSG Diagnostics" existe como funcionalidade, mas sua função é diferente de avaliar um fluxo específico com parâmetros determinados.

Gabarito — Questão 2​

Resposta: B

O IP Flow Verify opera exclusivamente na camada de NSG. Quando ele retorna "Allow", significa apenas que nenhuma regra de NSG está bloqueando o fluxo. Existem várias outras camadas que podem causar descarte de pacotes sem que o NSG seja o culpado: firewalls de host no sistema operacional (iptables, Windows Firewall), rotas UDR que redirecionam o tráfego para um NVA que pode estar descartando os pacotes, ou até mesmo políticas de firewall no NVA.

A alternativa A é um distrator plausível, mas o agente desatualizado causaria falha no próprio teste, não perda seletiva. A alternativa C é incorreta, pois o VNet Peering global suporta qualquer porta TCP. A alternativa D confunde um requisito de coleta de dados com um requisito de funcionamento do teste de conectividade.

Gabarito — Questão 3​

Resposta: Falso

O NSG Flow Logs registra metadados de fluxo de rede, não o conteúdo dos pacotes. As informações gravadas incluem tupla de cinco elementos (IPs, portas, protocolo), a decisão de Allow/Deny, e na versão 2, bytes e pacotes por fluxo. Nenhum payload é capturado ou armazenado.

A ferramenta correta para capturar o conteúdo real dos pacotes é o Packet Capture, que gera arquivos no formato PCAP. Confundir essas duas ferramentas é um erro comum e com implicação direta em cenários de conformidade: uma organização que acredita estar capturando payloads via Flow Logs está, na prática, sem cobertura de auditoria de conteúdo.

Gabarito — Questão 4​

Resposta: B

O Connection Monitor é a solução nativa do Azure Network Watcher para monitoramento contínuo de conectividade e latência entre origens e destinos, incluindo endpoints externos à VNet. Ele se integra nativamente ao Azure Monitor e ao Log Analytics, permitindo definir thresholds e disparar alertas automaticamente, sem necessidade de scripts ou processamento externo.

A alternativa A descreve uma abordagem funcional, mas operacionalmente inviável para monitoramento contínuo. A alternativa C está incorreta: o Connection Monitor suporta endpoints externos, e o Network Performance Monitor é uma capacidade legada que o Connection Monitor substituiu. A alternativa D confunde a ferramenta de Topology, que é estática e visual, com uma solução de monitoramento ativo.

Gabarito — Questão 5​

Resposta: B

A diferença central entre as versões 1 e 2 do NSG Flow Logs é que a versão 2 inclui métricas de throughput por fluxo: o número de bytes e pacotes transmitidos em cada direção. Isso permite análises de volume de tráfego e identificação de fluxos anômalos por consumo, não apenas por presença.

A alternativa A é incorreta: nenhuma das versões registra o nome da regra de NSG, apenas a decisão. A alternativa C é incorreta pois o IP de destino já está presente na versão 1 como parte da tupla. A alternativa D é incorreta porque o NSG Flow Logs opera na camada de rede (L3/L4) e não realiza inspeção de protocolo de aplicação, funcionalidade que pertence ao domínio de ferramentas como o Azure Firewall com Premium SKU.