Microsoft AZ-700: Monitoramento e Solução de Problemas de Rede — Guia de estudos

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Network Engineer AZ-700 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Ferramentas de observabilidade e fontes de dados

A observabilidade em redes do Azure se concentra no Network Watcher, no Azure Monitor (Log Analytics) e nas configurações de diagnóstico que transmitem telemetria dos recursos para um espaço de trabalho (workspace) central ou uma conta de armazenamento. O Network Watcher oferece captura de pacotes, verificação de fluxo de IP, próximo salto (next hop), solução de problemas de conexão e o Connection Monitor; o Connection Monitor v2 suporta testes multiponto e multiprotocolo e armazena os resultados em um workspace do Log Analytics para telemetria consultável. Os logs de fluxo de NSG (NSG flow logs) são habilitados através do Network Watcher e gravam registros JSON em uma conta de armazenamento; habilitar o Traffic Analytics (que requer logs de fluxo + um workspace do Log Analytics) enriquece esses logs com insights de aplicação/geográficos e visualização. As configurações de diagnóstico no Azure Firewall, Application Gateway/WAF, Front Door e balanceadores de carga devem ser roteadas para o mesmo workspace do Log Analytics para correlacionar os sinais. Armadilhas comuns incluem regras de firewall da conta de armazenamento bloqueando a escrita dos logs de fluxo, esquecer de habilitar o Network Watcher por região em tenants mais antigos e políticas de retenção inconsistentes entre a conta de armazenamento e o Log Analytics. As compensações de custo e capacidade são claras: gravar logs brutos em uma conta de armazenamento para arquivamento de baixo custo versus ingeri-los no Log Analytics para consulta e alertas (custo mais alto, mas valor de diagnóstico muito maior). O Controle de Acesso Baseado em Função (Role-Based Access Control) (Monitor Reader mais Storage Blob Data Reader, quando necessário) deve ser configurado para que os pipelines de diagnóstico possam escrever e os analistas possam ler os logs.

Captura de pacotes, Connection Monitor e diagnósticos aprofundados

Para solução de problemas no nível de pacote, a captura de pacotes do Network Watcher (via portal/CLI/PowerShell) cria arquivos PCAP em uma conta de armazenamento ou em um arquivo local na VM. Configure filtros de captura de pacotes (protocolo, IP de origem/destino, portas) e limites de tamanho/tempo para evitar armazenamento excessivo e impacto no desempenho. Para VMs de alta taxa de transferência com rede acelerada (accelerated networking), a visibilidade de pacotes no lado do host pode ser limitada; use o VNet TAP para espelhar o tráfego para uma VM coletora ou NVA para evitar a perda de pacotes descarregados (offloaded). O Connection Monitor deve ser usado para testes sintéticos ativos: defina os pontos de extremidade de origem e destino (IP, FQDN, porta), escolha a frequência do teste e habilite a latência por salto e a captura de caminho para diagnóstico de múltiplos segmentos. Use o IP Flow Verify para verificar se uma 5-tupla específica é permitida ou negada por NSGs/UDRs, e o Next-hop para confirmar o roteamento efetivo. Fique atento às armadilhas: a captura de pacotes em VMs Windows pode exigir permissões elevadas e ser impactada por descarregamentos (offloads) do sistema operacional; a captura de pacotes pode ser intensiva em CPU/disco, portanto, prefira filtros direcionados e limites de tempo (timeboxes). Para inspeção contínua de pacotes em escala, combine o VNet TAP com um appliance de análise de pacotes ou um SIEM na nuvem que possa ingerir fluxos PCAP.

Logs de fluxo de NSG, Traffic Analytics e diagnósticos de segurança

Os logs de fluxo de NSG (versão 2) fornecem registros de fluxo com carimbos de data/hora (timestamps), 5-tupla, contagem de bytes/pacotes e a decisão (permitido/negado). Eles não contêm o payload, detalhes da sessão da camada de aplicação ou TLS descriptografado. O Traffic Analytics enriquece os logs de fluxo com os principais comunicadores (top talkers), ASNs e mapeamento geográfico, exigindo um workspace do Log Analytics. O Azure Firewall, o Application Gateway/WAF e o Azure Front Door emitem seus próprios diagnósticos; estes devem ser direcionados para o Log Analytics para consulta unificada. Armadilhas de design importantes: regras de NSG aplicadas no nível da NIC têm precedência sobre as regras no nível da sub-rede; existem regras padrão (por exemplo, AzureLoadBalancer, regras de internet) e não podem ser removidas, apenas sobrepostas por regras de maior prioridade. Os logs de fluxo são tão úteis quanto a estratégia de retenção e ingestão — a retenção longa no Log Analytics é cara, enquanto a retenção curta arrisca a perda de evidências forenses. Combine os logs de fluxo de NSG com os logs de diagnóstico do Firewall e regras de Alerta baseadas em consultas Kusto para detectar movimento lateral ou exfiltração de dados. Ao planejar ações de remediação, considere adicionar IPs públicos dedicados ao Azure Firewall para mitigar a exaustão de portas SNAT e utilize as DiagnosticSettings para rotear para os Event Hubs para integração com SIEM se os custos do Log Analytics forem proibitivos.

Padrões de solução de problemas, armadilhas de roteamento e trade-offs de design

Ao solucionar problemas de conectividade, siga uma abordagem em camadas: verifique NSG/UDR no nível do recurso, confira as rotas efetivas e o próximo salto (next hop), use o IP Flow Verify e o Connection Troubleshoot e, se necessário, escale para captura de pacotes ou VNet TAP. As armadilhas de roteamento geralmente surgem com tunelamento forçado (forced tunneling), CIDRs sobrepostos ou UDRs mal configurados que enviam tráfego para a AzureFirewallSubnet sem rotas de retorno apropriadas. Para balanceamento de carga e escala, escolha entre o Azure Standard Load Balancer, o Application Gateway WAF e o Front Door com base nas necessidades de L4 vs. L7 e no gerenciamento de tráfego global vs. regional. Considere estes trade-offs de SKU:

Azure Firewall Standard vs. Premium: O Premium adiciona inspeção de TLS, IDPS e filtragem de URL a um custo mais alto; escolha o Premium quando for necessária uma inspeção profunda de tráfego e controle regulatório.
Azure Front Door Standard vs. Premium: O Premium oferece suporte a recursos avançados de WAF e integrações de private link; o Standard tem um custo menor para CDN global + roteamento típicos.
VNet TAP vs. captura de pacotes: O TAP tem um custo mais alto, mas é necessário para captura sem perdas (lossless) em escala e quando o accelerated networking descarrega pacotes. Os trade-offs se concentram em desempenho, custo e resiliência: os NVAs podem ser mais baratos ou ter mais recursos que o Firewall Premium, mas adicionam sobrecarga de gerenciamento e risco de ponto único de falha, a menos que sejam arquitetados com alta disponibilidade (HA). Planeje a capacidade de SNAT, reserve IPs públicos sobressalentes e organize pipelines de diagnóstico para equilibrar as necessidades de observabilidade com os custos de ingestão.

Problema Prático: Cenário de Caso de Uso

Cenário: A Contoso Electronics opera uma infraestrutura no Azure em duas regiões (EastUS, WestEurope) com VNets hub-and-spoke, um Azure Firewall Standard no hub, múltiplos Application Gateway WAFs nos spokes e um workspace central do Log Analytics para monitoramento. Recentemente, eles implantaram um conjunto de VMs de produção em um spoke que relatam falhas intermitentes para alcançar um cluster SQL on-premises por meio de um circuito ExpressRoute.

Desafio: Conectividade intermitente e alta latência para recursos on-premises sem evidências claras no nível do pacote; os logs de fluxo do NSG existentes estão habilitados, mas mostram fluxos permitidos sem métricas de latência.

Abordagem Recomendada:

Implante o Connection Monitor v2 a partir de VMs representativas para o FQDN e IP do SQL on-premises usando a porta TCP 1433, configure testes a cada 30 segundos e envie os resultados para o workspace central do Log Analytics para capturar a latência por salto e a alcançabilidade.
Habilite a captura de pacotes do Network Watcher em uma VM afetada com filtros para o IP de origem/destino do cluster SQL e a porta 1433, armazene os PCAPs em uma conta de armazenamento com uma política de ciclo de vida; simultaneamente, habilite o VNet TAP na sub-rede do spoke para espelhar o tráfego para uma VM coletora dedicada se o accelerated networking estiver presente.
Configure as configurações de diagnóstico do Azure Firewall (Standard) para enviar logs de aplicativo e de rede para o mesmo workspace do Log Analytics e execute consultas de correlação unindo os resultados do Connection Monitor, logs do firewall e logs de fluxo do NSG para detectar exaustão de SNAT do firewall ou quedas por política.
Use o IP Flow Verify e o Next Hop para uma 5-tupla que está falhando durante um incidente; se houver suspeita de SNAT ou roteamento assimétrico, adicione um IP público adicional ao Azure Firewall ou implante um NAT Gateway no spoke para uma saída previsível e atualize as UDRs para rotear através do hub.

Justificativa: O Connection Monitor fornece alcançabilidade sintética com carimbo de data/hora e latência por salto; a captura de pacotes e o VNet TAP fornecem dados forenses sem perdas quando o descarregamento do SO oculta o tráfego. A correlação dos logs do firewall e do NSG no Log Analytics identifica problemas de política, SNAT ou roteamento assimétrico; adicionar IPs públicos ou um NAT Gateway mitiga a exaustão de portas e estabiliza o comportamento de saída.

← Balanceamento de Carga e Gerenciamento de Tráfego · Todos os domínios · Azure Virtual WAN e Hub-Spoke →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →