Laboratório Técnico: Implement VNet Peering
Questões
Questão 1 — Múltipla Escolha
Uma equipe de rede configurou peering entre VNet-A (10.1.0.0/16) e VNet-B (10.2.0.0/16). Posteriormente, foi criado o peering entre VNet-B e VNet-C (10.3.0.0/16). Um desenvolvedor relata que recursos em VNet-A não conseguem se comunicar com recursos em VNet-C, mesmo que ambos os peerings estejam ativos e configurados corretamente.
Qual é a razão técnica para esse comportamento?
A) O peering entre VNet-A e VNet-B precisa ser recriado após a adição de VNet-C para que as rotas sejam propagadas automaticamente.
B) O VNet peering no Azure não é transitivo, portanto a conectividade entre VNet-A e VNet-C exige um peering direto entre elas ou o uso de um recurso intermediário como Azure Virtual WAN ou NVA.
C) O problema está nos intervalos de endereços IP, pois VNets em peering não podem pertencer a espaços de endereçamento da mesma classe.
D) O peering entre VNet-B e VNet-C precisa ter a opção Allow gateway transit habilitada para que VNet-A enxergue VNet-C.
Questão 2 — Cenário Técnico
Um engenheiro está configurando peering entre duas VNets em regiões diferentes (global VNet peering). Após concluir a configuração em ambos os lados, o status do peering exibe Connected no portal, mas o tráfego entre as VMs ainda não flui.
Ao investigar, o engenheiro verifica a seguinte configuração em uma das VMs:
VM: vm-prod-eastus
NSG associado à NIC: nsg-prod
Regra de entrada ativa:
Prioridade: 100 | Porta: 3389 | Origem: 10.1.0.0/16 | Ação: Allow
Prioridade: 200 | Porta: * | Origem: * | Ação: Deny
A VM de origem está em 10.2.0.0/16 e tenta acessar a porta 22 (SSH) de vm-prod-eastus.
Qual é a causa mais provável da falha?
A) O global VNet peering não suporta tráfego SSH entre regiões distintas por restrição de protocolo.
B) O NSG está bloqueando o tráfego SSH originado de 10.2.0.0/16, pois nenhuma regra permite a porta 22 para essa origem antes da regra de negação geral.
C) A regra de prioridade 100 precisa ser reconfigurada para incluir o intervalo 10.2.0.0/16 como destino, e não como origem.
D) O tráfego está sendo bloqueado porque o peering global exige que o Allow forwarded traffic esteja habilitado antes que NSGs possam processar pacotes entre regiões.
Questão 3 — Verdadeiro ou Falso
Ao criar um VNet peering, basta configurar o lado da VNet de origem para que a conectividade bidirecional seja estabelecida automaticamente pelo Azure.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma empresa possui a seguinte topologia:
VNet-Hub (10.0.0.0/16) — contém um VPN Gateway
VNet-Spoke (10.1.0.0/16) — conectada ao Hub via VNet peering
Rede on-premises: 192.168.0.0/24
O objetivo é permitir que recursos na VNet-Spoke alcancem a rede on-premises por meio do VPN Gateway instalado na VNet-Hub, sem instalar um gateway na VNet-Spoke.
O engenheiro configura o peering no lado do Hub e do Spoke, mas os recursos na VNet-Spoke ainda não conseguem atingir a rede on-premises.
Qual é a configuração ausente que resolve o problema?
A) Habilitar Allow gateway transit no peering do lado da VNet-Hub e Use remote gateways no peering do lado da VNet-Spoke.
B) Habilitar Allow forwarded traffic em ambos os lados do peering para que os pacotes da VPN sejam encaminhados corretamente.
C) Instalar um segundo VPN Gateway na VNet-Spoke e configurar uma conexão VNet-to-VNet entre Hub e Spoke.
D) Habilitar Use remote gateways em ambos os lados do peering, pois a opção precisa ser simétrica para funcionar.
Questão 5 — Múltipla Escolha
Dois times distintos de uma organização são responsáveis, cada um, por uma VNet em subscriptions diferentes dentro do mesmo tenant do Microsoft Entra ID. Eles precisam estabelecer VNet peering entre as duas VNets.
Qual afirmação descreve corretamente o requisito de permissão mínimo para que cada time conclua a operação?
A) Apenas o time que inicia o peering precisa de permissão; o Azure propaga a configuração automaticamente para a VNet remota.
B) Ambos os times precisam ter, no mínimo, a função Network Contributor ou uma função personalizada com a ação Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write sobre suas respectivas VNets.
C) Um dos times precisa ter a função Owner na subscription inteira do outro time para que o peering entre subscriptions seja autorizado.
D) O peering entre VNets em subscriptions diferentes não é suportado quando as subscriptions pertencem ao mesmo tenant do Microsoft Entra ID.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O VNet peering no Azure é não transitivo por design. Isso significa que, mesmo que VNet-A faça peering com VNet-B e VNet-B faça peering com VNet-C, o plano de dados do Azure não cria automaticamente uma rota entre VNet-A e VNet-C. Cada peering é uma relação isolada de camada 3.
Para resolver esse cenário, as alternativas válidas incluem criar um peering direto entre VNet-A e VNet-C, usar um Hub-and-Spoke com NVA (Network Virtual Appliance) que encaminha o tráfego, ou adotar o Azure Virtual WAN, que oferece roteamento transitivo gerenciado.
A alternativa D representa um equívoco muito comum: o Allow gateway transit permite que uma VNet spoke use o gateway da VNet hub para alcançar redes externas (como on-premises), mas não resolve a transitividade entre VNets spoke.
Gabarito — Questão 2
Resposta: B
O status Connected confirma que o plano de controle do peering está correto. O problema está na camada de segurança: o NSG associado à NIC da VM de destino possui uma regra de negação geral na prioridade 200 que bloqueia qualquer tráfego não explicitamente permitido antes dela. A única regra de permissão existente cobre a porta 3389 (RDP) para a origem 10.1.0.0/16, sem qualquer regra que permita a porta 22 para 10.2.0.0/16.
O global VNet peering não impõe restrições de protocolo (alternativa A é falsa). A alternativa C confunde os campos de origem e destino da regra NSG. A alternativa D é incorreta: o Allow forwarded traffic é relevante para cenários onde o tráfego entra em uma VNet vindo de fora do peering direto, mas não afeta o processamento de NSGs em si.
Gabarito — Questão 3
Resposta: Falso
O VNet peering no Azure exige configuração em ambos os lados para que o status chegue a Connected e o tráfego flua. Quando apenas um lado é configurado, o status do peering exibe Initiated (ou Not connected), indicando que a relação está incompleta.
Esse comportamento é intencional: garante que o proprietário de cada VNet autorize explicitamente a conectividade, o que é especialmente relevante em cenários de peering entre subscriptions ou tenants diferentes. A ausência de configuração em um dos lados não é apenas uma limitação técnica, mas um controle de governança deliberado.
Gabarito — Questão 4
Resposta: A
Para que uma VNet-Spoke utilize o gateway de outra VNet (o Hub), são necessárias duas configurações complementares e assimétricas:
- No peering do lado do Hub: habilitar Allow gateway transit, sinalizando que esse gateway pode ser usado por VNets remotas.
- No peering do lado do Spoke: habilitar Use remote gateways, sinalizando que essa VNet deve usar o gateway da VNet peered em vez de um gateway próprio.
A alternativa B descreve o Allow forwarded traffic, que resolve um problema diferente: permite que tráfego originado fora de uma VNet seja encaminhado através do peering, útil em topologias com NVA. Não resolve a questão do uso de gateway remoto.
A alternativa D representa o erro conceitual mais comum: aplicar Use remote gateways em ambos os lados é inválido e resultaria em erro, pois apenas a VNet sem gateway pode usar o gateway remoto.
Gabarito — Questão 5
Resposta: B
O VNet peering entre subscriptions é totalmente suportado, inclusive quando ambas pertencem ao mesmo tenant do Microsoft Entra ID (alternativa D é falsa). O requisito de permissão é que cada responsável tenha autorização de escrita sobre o recurso de peering em sua própria VNet, o que é satisfeito pela função Network Contributor ou por uma função personalizada contendo a ação Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write.
A alternativa A é incorreta: o Azure não propaga automaticamente a configuração para a VNet remota, pois exige consentimento explícito de ambos os lados.
A alternativa C representa um exagero de permissão desnecessário. O acesso de Owner sobre a subscription inteira não é exigido; o escopo mínimo é a própria VNet. Conceder mais permissões do que o necessário viola o princípio de menor privilégio, um pilar de segurança relevante em qualquer ambiente Azure.