Pular para o conteúdo principal

Laboratório Técnico: Implement Virtual Network Flow Logs

Questões​

Questão 1 — Múltipla Escolha​

Sua equipe precisa monitorar todo o tráfego IP que atravessa uma rede virtual de produção, incluindo tráfego entre sub-redes e tráfego que passa por recursos como Load Balancers e VMs. O requisito é capturar esse tráfego no nível da VNet, sem precisar configurar monitoramento individualmente em cada NIC ou sub-rede.

Qual recurso do Azure atende diretamente a esse requisito?

A) NSG Flow Logs configurados em cada NSG associado às sub-redes da VNet.

B) Virtual Network Flow Logs habilitados diretamente no recurso da rede virtual.

C) Azure Network Watcher Connection Monitor configurado para a VNet alvo.

D) Diagnósticos de gateway configurados no Virtual Network Gateway da VNet.

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

Um engenheiro executou o seguinte comando para habilitar VNet Flow Logs:

az network watcher flow-log create \
  --name vnet-flowlog-prod \
  --nsg "/subscriptions/.../resourceGroups/rg-prod/providers/Microsoft.Network/virtualNetworks/vnet-prod" \
  --storage-account "/subscriptions/.../storageAccounts/stflowlogs" \
  --enabled true \
  --location eastus \
  --resource-group rg-network

O comando é executado sem erros, mas após 30 minutos nenhum log aparece na conta de armazenamento. O Network Watcher está habilitado na região eastus.

Qual é a causa mais provável da ausência dos logs?

A) O parâmetro --nsg não aceita o resource ID de uma VNet; deve ser usado o parâmetro correto para VNet Flow Logs.

B) VNet Flow Logs exigem que a conta de armazenamento esteja na mesma região que a VNet, e essa condição não foi verificada no comando.

C) O Network Watcher precisa ser explicitamente associado à VNet antes de habilitar o Flow Log.

D) O intervalo de retenção padrão é zero dias, descartando os logs imediatamente após a gravação.

Questão 3 — Múltipla Escolha​

Ao comparar VNet Flow Logs com NSG Flow Logs, qual diferença representa corretamente o escopo de cobertura de cada recurso?

CaracterísticaNSG Flow LogsVNet Flow Logs
Escopo de capturaPor NSG individualToda a rede virtual
Tráfego entre sub-redes na mesma VNetDepende da presença de NSGCapturado nativamente
Tráfego para recursos sem NSG associadoNão capturadoCapturado

Com base nessa comparação, qual afirmação está correta?

A) NSG Flow Logs e VNet Flow Logs podem ser habilitados simultaneamente na mesma VNet sem gerar registros duplicados, pois usam pipelines de captura distintos.

B) VNet Flow Logs substituem completamente os NSG Flow Logs em todos os cenários, tornando estes obsoletos após a habilitação daqueles.

C) NSG Flow Logs capturam tráfego que foi explicitamente avaliado por uma regra de NSG, enquanto VNet Flow Logs capturam o fluxo IP na camada da VNet independentemente da presença de NSG.

D) VNet Flow Logs capturam apenas o tráfego que entra ou sai da VNet via peering ou gateway, excluindo o tráfego interno entre sub-redes.

Questão 4 — Verdadeiro ou Falso​

O Traffic Analytics, quando integrado aos VNet Flow Logs, processa os dados brutos de fluxo em tempo real e os disponibiliza no Log Analytics Workspace com latência inferior a um minuto após a captura.

Verdadeiro ou Falso?

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

Uma organização usa VNet Flow Logs com Traffic Analytics habilitado. O analista de segurança precisa identificar quais endereços IP externos estão gerando o maior volume de tráfego de entrada para VMs de uma sub-rede específica nos últimos 7 dias.

Qual é a abordagem correta para obter essa informação?

A) Fazer download dos arquivos JSON da conta de armazenamento e processar manualmente os campos flowTuples para cada intervalo de tempo.

B) Consultar a tabela NTANetAnalytics ou AzureNetworkAnalytics_CL no Log Analytics Workspace usando KQL, filtrando por sub-rede de destino e direção de fluxo.

C) Usar o Azure Monitor Metrics para a VNet alvo, filtrando pela dimensão de endereço IP de origem.

D) Configurar um alerta no Network Watcher do tipo Connection Monitor para capturar os IPs de maior volume retroativamente.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

VNet Flow Logs são habilitados diretamente no recurso da rede virtual e capturam todo o tráfego IP que flui dentro do escopo daquela VNet, incluindo tráfego entre sub-redes e tráfego envolvendo recursos que não possuem NSG associado. Essa é a distinção central em relação às alternativas.

A alternativa A representa a abordagem anterior ao VNet Flow Logs: era necessário configurar NSG Flow Logs em cada NSG individualmente, criando lacunas de cobertura onde não havia NSG. A alternativa C monitora conectividade ponta a ponta, não captura fluxos IP de forma abrangente. A alternativa D captura métricas de gateway, não fluxos gerais da VNet.

Gabarito — Questão 2​

Resposta: A

O parâmetro --nsg no comando az network watcher flow-log create aceita o resource ID de um NSG, não de uma VNet. Para criar um VNet Flow Log, o recurso alvo deve ser especificado com o parâmetro --target-resource-id apontando para o resource ID da VNet. O uso incorreto do parâmetro pode resultar em execução sem erro aparente, mas sem o comportamento esperado.

A alternativa B descreve uma restrição real de NSG Flow Logs e VNet Flow Logs em relação à conta de armazenamento, mas não é a causa primária aqui, pois o comando em si está estruturalmente incorreto. A alternativa C é falsa: o Network Watcher habilitado na região já é suficiente. A alternativa D descreve um comportamento de retenção que afetaria logs já gravados, não impediria a gravação inicial.

Gabarito — Questão 3​

Resposta: C

NSG Flow Logs registram fluxos que foram processados por uma regra de NSG, o que significa que somente o tráfego avaliado por um NSG existente é registrado. Se uma NIC ou sub-rede não tiver NSG associado, esse tráfego não aparece nos NSG Flow Logs. VNet Flow Logs operam na camada da rede virtual e capturam todos os fluxos IP independentemente da presença ou ausência de NSG.

A alternativa A é incorreta: quando ambos estão habilitados na mesma VNet, podem ocorrer registros duplicados para o mesmo tráfego, o que deve ser considerado no dimensionamento do armazenamento e nos custos. A alternativa B é incorreta porque os dois recursos coexistem e têm casos de uso distintos. A alternativa D inverte o comportamento esperado: VNet Flow Logs cobrem o tráfego interno entre sub-redes, que é exatamente um dos casos não cobertos por NSG Flow Logs em topologias sem NSG interno.

Gabarito — Questão 4​

Resposta: Falso

O Traffic Analytics não opera em tempo real. Ele processa os dados de fluxo em intervalos configuráveis, sendo o mínimo suportado de 10 minutos e o padrão de 60 minutos. Após o intervalo de agregação, os dados são enviados ao Log Analytics Workspace. Portanto, a afirmação de latência inferior a um minuto está incorreta.

Esse comportamento é relevante para decisões de arquitetura: Traffic Analytics é adequado para análise histórica e identificação de padrões, não para detecção de ameaças em tempo real. Para reação imediata, outros mecanismos como Microsoft Defender for Cloud ou Azure Firewall com logging em tempo real são mais adequados.

Gabarito — Questão 5​

Resposta: B

Quando o Traffic Analytics está habilitado, os dados processados são gravados no Log Analytics Workspace nas tabelas NTANetAnalytics ou AzureNetworkAnalytics_CL, dependendo da versão do esquema. A linguagem KQL permite filtrar por campos como sub-rede de destino, direção do fluxo (FlowDirection), e agregar por volume de bytes ou pacotes por IP de origem, respondendo exatamente à necessidade descrita.

A alternativa A é tecnicamente viável mas operacionalmente inviável para 7 dias de dados: os arquivos JSON brutos são fragmentados por intervalo de tempo e exigiriam processamento manual extenso. A alternativa C é incorreta porque Azure Monitor Metrics para VNets não expõe dimensões por endereço IP de origem. A alternativa D confunde Connection Monitor, que monitora conectividade prospectiva, com a capacidade retroativa de análise de fluxos que pertence ao Traffic Analytics.