Pular para o conteúdo principal

Laboratório Técnico: Create and configure virtual network peering

Questões​

Questão 1 — Múltipla Escolha​

Duas redes virtuais do Azure estão configuradas com os seguintes espaços de endereço:

  • VNet-A: 10.1.0.0/16
  • VNet-B: 10.1.128.0/17

Um administrador tenta estabelecer peering entre elas, mas a operação falha.

Qual é a causa raiz da falha?

A) As duas redes estão em regiões diferentes, o que exige o uso de peering global, que requer uma SKU Premium.

B) Os espaços de endereço das duas redes se sobrepõem, o que é uma restrição fundamental do peering.

C) O peering só pode ser criado entre redes que estejam na mesma assinatura do Azure.

D) A sub-rede de gateway não foi configurada em nenhuma das redes antes de iniciar o peering.

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

Um administrador configurou peering entre VNet-Prod e VNet-Shared, onde VNet-Shared contém um gateway de VPN conectado à rede on-premises. O objetivo é permitir que recursos em VNet-Prod acessem a rede on-premises por meio desse gateway.

A configuração atual do peering é:

VNet-Prod --> VNet-Shared
  Allow forwarded traffic: Enabled
  Allow gateway transit:   Disabled
  Use remote gateways:     Disabled

VNet-Shared --> VNet-Prod
  Allow forwarded traffic: Enabled
  Allow gateway transit:   Disabled
  Use remote gateways:     Disabled

O tráfego da VNet-Prod não está chegando à rede on-premises. Qual alteração resolve o problema?

A) Habilitar Allow gateway transit no lado VNet-Prod --> VNet-Shared e Use remote gateways no lado VNet-Shared --> VNet-Prod.

B) Habilitar Allow gateway transit no lado VNet-Shared --> VNet-Prod e Use remote gateways no lado VNet-Prod --> VNet-Shared.

C) Habilitar Allow forwarded traffic em ambos os lados, pois essa é a opção que permite o roteamento através do gateway remoto.

D) Recriar o peering com as duas redes na mesma assinatura, pois o uso de gateway remoto não é suportado entre assinaturas diferentes.

Questão 3 — Verdadeiro ou Falso​

Após a criação de um peering entre VNet-A e VNet-B, se um novo espaço de endereço for adicionado à VNet-A, o peering existente passa automaticamente para o estado Disconnected e deve ser resincronizado manualmente para que o novo espaço de endereço seja reconhecido pela VNet-B.

A afirmação é Verdadeira ou Falsa?

Questão 4 — Múltipla Escolha​

Uma empresa possui três redes virtuais: VNet-A, VNet-B e VNet-C. O peering está configurado entre VNet-A e VNet-B, e entre VNet-B e VNet-C. Um engenheiro assume que recursos em VNet-A conseguem se comunicar com recursos em VNet-C por meio de VNet-B.

Qual afirmação descreve corretamente o comportamento do Azure nesse cenário?

A) A comunicação funciona porque o Azure roteia automaticamente o tráfego entre redes emparelhadas transitivamente.

B) A comunicação não funciona porque o peering no Azure não é transitivo por padrão, sendo necessário um peering direto entre VNet-A e VNet-C ou o uso de um hub com roteamento configurado.

C) A comunicação funciona apenas se VNet-B tiver um gateway de VPN ativo com a opção Allow gateway transit habilitada.

D) A comunicação não funciona porque redes em peering não podem atuar como hub de roteamento, independentemente de qualquer configuração adicional.

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

Um administrador tenta criar um peering entre VNet-Alpha (assinatura A, tenant X) e VNet-Beta (assinatura B, tenant Y). Ao executar o comando abaixo, recebe um erro de autorização:

az network vnet peering create \
  --name Alpha-to-Beta \
  --resource-group rg-alpha \
  --vnet-name VNet-Alpha \
  --remote-vnet /subscriptions/<sub-b>/resourceGroups/rg-beta/virtualNetworks/VNet-Beta \
  --allow-vnet-access

O administrador possui permissão de Network Contributor somente na assinatura A. Qual é a causa do erro e o que deve ser feito para resolvê-lo?

A) O peering entre tenants diferentes não é suportado pelo Azure, independentemente das permissões configuradas.

B) O comando está incompleto pois falta o parâmetro --allow-forwarded-traffic, que é obrigatório em peerings entre tenants.

C) O administrador não possui permissão na assinatura B para criar o peering no lado da VNet-Beta; é necessário que um usuário com permissão adequada na assinatura B crie o peering correspondente, ou que o administrador receba a função necessária lá.

D) O peering entre assinaturas de tenants diferentes exige que ambas as redes estejam na mesma região do Azure antes de ser estabelecido.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O peering entre redes virtuais do Azure exige que os espaços de endereço não se sobreponham de nenhuma forma. No cenário apresentado, 10.1.0.0/16 engloba o intervalo 10.1.128.0/17 integralmente, caracterizando sobreposição direta. O Azure rejeita o peering antes mesmo de qualquer validação de região ou assinatura.

O principal equívoco representado pelos distratores é confundir restrições de topologia de rede (sobreposição de endereços) com restrições de plataforma (região, assinatura, SKU). A restrição de sobreposição é absoluta e não pode ser contornada por configuração. A consequência de ignorá-la seria tentar reestruturar o roteamento antes de identificar o problema real, desperdiçando tempo de diagnóstico.

Gabarito — Questão 2​

Resposta: B

Para que uma rede spoke utilize o gateway de outra rede hub, a configuração deve ser:

  • No lado da rede que possui o gateway (VNet-Shared --> VNet-Prod): habilitar Allow gateway transit.
  • No lado da rede que quer usar o gateway remoto (VNet-Prod --> VNet-Shared): habilitar Use remote gateways.

A alternativa A inverte essa lógica, que é o erro mais comum nesse cenário. A opção Allow gateway transit deve estar no lado que tem o gateway, não no lado que consome. O Allow forwarded traffic controla o tráfego originado fora do peering direto, e não tem relação com o uso de gateways remotos. Quanto à alternativa D, o uso de gateway remoto é suportado entre assinaturas e até entre tenants diferentes.

Gabarito — Questão 3​

Resposta: Verdadeira

Quando o espaço de endereço de uma rede virtual é modificado após o estabelecimento de um peering, o Azure não propaga automaticamente essa mudança para os peers. O peering entra no estado Disconnected, e o administrador precisa executar uma ressincronização manual (opção "Sync" no portal ou via CLI/PowerShell) para que a nova informação de roteamento seja distribuída.

Esse comportamento não é intuitivo porque o Azure gerencia muitos aspectos de rede de forma automática, mas a atualização de espaço de endereço em peerings exige ação explícita. Ignorar esse passo resulta em falha silenciosa de conectividade para os novos intervalos adicionados.

Gabarito — Questão 4​

Resposta: B

O peering de redes virtuais no Azure é não transitivo por design. A existência de peering entre A-B e B-C não implica conectividade entre A e C. Cada par de redes que precisa se comunicar deve ter seu próprio peering direto, ou a transitvidade deve ser implementada explicitamente por meio de uma solução de hub-and-spoke com Azure Virtual WAN, NVA (Network Virtual Appliance) ou Azure Route Server com roteamento adequado.

A alternativa C é um distrator sofisticado porque mistura corretamente o conceito de gateway transit com a ideia de roteamento, mas gateway transit não resolve a transitividade de peering, ele permite apenas o uso de um gateway VPN/ExpressRoute remoto. A alternativa D está incorreta porque, com a arquitetura correta, uma VNet hub pode sim rotear tráfego entre spokes.

Gabarito — Questão 5​

Resposta: C

O peering entre redes virtuais é uma operação bidirecional que requer autorização em ambos os lados. Quando as redes estão em tenants diferentes, não basta ter permissão em uma única assinatura. O administrador precisa de, no mínimo, a função Network Contributor (ou permissão equivalente com Microsoft.Network/virtualNetworks/peer/action) na assinatura B para criar o peering no lado da VNet-Beta.

O peering entre tenants diferentes é suportado pelo Azure, o que invalida a alternativa A. O parâmetro --allow-forwarded-traffic não é obrigatório, apenas opcional, invalidando a alternativa B. A restrição de região não se aplica a peerings entre tenants, invalidando a alternativa D. A causa real é puramente de controle de acesso baseado em função (RBAC) na assinatura remota.