Laboratório Técnico: Design a Virtual WAN architecture, including selecting types and services
Questões
Questão 1 — Múltipla Escolha
Uma empresa multinacional precisa conectar 30 filiais distribuídas em três continentes a uma rede corporativa centralizada no Azure. O requisito principal é que o tráfego entre filiais possa fluir diretamente entre si sem obrigatoriamente transitar pelo hub central, e a equipe de rede não quer gerenciar roteamento manualmente entre os spokes.
Qual tipo de Virtual WAN atende a esse requisito?
A) Virtual WAN Basic, pois suporta conectividade site-to-site com roteamento automático entre branches.
B) Virtual WAN Standard, pois habilita trânsito entre VNets e branches por meio do roteamento gerenciado do hub.
C) Virtual WAN Basic com hubs adicionais por região, pois o roteamento inter-hub é gerenciado automaticamente nesse tier.
D) Virtual WAN Standard com User Defined Routes (UDRs) obrigatórias para viabilizar o tráfego entre branches.
Questão 2 — Cenário Técnico
Um arquiteto está desenhando uma solução de Virtual WAN para uma organização que exige inspeção de tráfego leste-oeste entre VNets conectadas ao mesmo hub. A proposta inclui a integração de um firewall de terceiros (NVA) diretamente no hub.
Hub Virtual WAN (Standard)
├── VNet Spoke A (workloads de produção)
├── VNet Spoke B (workloads de homologação)
└── NVA de terceiro (para inspeção L7)
O arquiteto afirma que qualquer NVA de terceiros pode ser implantada diretamente no hub para realizar essa inspeção. Qual é o erro nessa afirmação?
A) NVAs não podem ser implantadas em hubs de Virtual WAN Standard; a inspeção exige migração para Virtual WAN Basic.
B) Apenas o Azure Firewall pode ser implantado no hub como Secured Virtual Hub; NVAs de terceiros devem ser implantadas em VNets spoke separadas.
C) A inspeção leste-oeste em Virtual WAN exige que o tráfego seja redirecionado manualmente via UDR para um spoke de trânsito com a NVA.
D) Apenas NVAs certificadas pelo programa de parceiros de Virtual WAN podem ser implantadas diretamente no hub.
Questão 3 — Verdadeiro ou Falso
Um Virtual WAN do tipo Basic pode ser convertido para o tipo Standard sem necessidade de recriar o recurso, e essa conversão é bidirecional, permitindo retornar ao tipo Basic posteriormente se necessário.
Questão 4 — Cenário Técnico
Uma organização já possui uma topologia hub-and-spoke tradicional no Azure com VNet peering manual e um hub de VNet central gerenciado pela equipe de rede. O CTO quer avaliar a migração para Virtual WAN Standard. Durante a análise, o arquiteto identifica que diversas VNets spoke já têm peering configurado com a VNet hub existente.
Qual é a implicação direta ao conectar essas VNets spoke ao Virtual WAN hub?
A) As VNets spoke podem manter o peering com a VNet hub tradicional simultaneamente à conexão com o Virtual WAN hub, sem conflito de roteamento.
B) O Virtual WAN hub gerencia o peering automaticamente, mas o peering manual existente com a VNet hub tradicional deve ser removido para evitar roteamento assimétrico.
C) A conexão de VNets spoke ao Virtual WAN exige que elas sejam recriadas, pois o serviço não aceita VNets com peerings preexistentes.
D) O Virtual WAN hub e a VNet hub tradicional podem coexistir sem restrições, pois operam em planos de controle independentes.
Questão 5 — Múltipla Escolha
Ao projetar uma arquitetura de Virtual WAN com múltiplos hubs em regiões diferentes, um arquiteto precisa garantir que o tráfego de uma branch conectada via S2S VPN no hub da região A alcance uma VNet conectada ao hub da região B.
Qual afirmação descreve corretamente o comportamento do Virtual WAN Standard nesse cenário?
A) O tráfego inter-hub não é suportado nativamente; exige configuração de VNet peering global entre os hubs das duas regiões.
B) O tráfego é roteado automaticamente entre hubs via a backbone da Microsoft, sem necessidade de configuração adicional de roteamento.
C) O roteamento inter-hub exige a criação de uma Connection entre os dois hubs por meio de um recurso de VNet de trânsito dedicada.
D) O tráfego inter-hub só é possível se ambos os hubs estiverem na mesma assinatura do Azure e no mesmo Virtual WAN resource group.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Virtual WAN Standard é o único tier que suporta roteamento transitivo completo: branch-to-branch, branch-to-VNet e VNet-to-VNet, incluindo entre filiais conectadas ao mesmo hub ou a hubs diferentes. Esse roteamento é gerenciado automaticamente pelo plano de controle do hub, eliminando a necessidade de configuração manual de UDRs para os fluxos transitivos básicos.
O Virtual WAN Basic suporta apenas conectividade S2S VPN e não habilita trânsito entre branches. A alternativa A é incorreta por essa razão. A alternativa C é falsa porque o roteamento inter-hub automático é exclusivo do tier Standard. A alternativa D introduz uma restrição inexistente: UDRs não são obrigatórias para o trânsito padrão no Virtual WAN Standard.
Gabarito — Questão 2
Resposta: D
O Virtual WAN suporta a implantação de NVAs de terceiros diretamente no hub, mas apenas para parceiros certificados pelo programa de integração de NVA in-hub da Microsoft (como Barracuda, Check Point, Fortinet e outros listados no portal). Esse modelo é distinto do Secured Virtual Hub, que utiliza o Azure Firewall e o Azure Firewall Manager.
A alternativa B representa o equívoco mais comum: confundir o conceito de Secured Virtual Hub (que usa Azure Firewall) com a totalidade das opções de inspeção no hub. NVAs certificadas de terceiros podem, de fato, ser implantadas no hub. A alternativa A é incorreta porque NVAs e firewalls são suportados no Standard, não no Basic. A alternativa C descreve uma topologia válida para NVAs não certificadas, mas não representa o erro da afirmação original.
Gabarito — Questão 3
Resposta: Falso
A conversão de Virtual WAN Basic para Standard é suportada e pode ser realizada sem recriar o recurso. No entanto, a operação é unidirecional: uma vez convertido para Standard, o Virtual WAN não pode ser revertido para Basic. Esse comportamento é relevante no design porque implica uma decisão permanente quanto ao tier, com impacto em custos e capacidades habilitadas.
O principal risco de ignorar essa característica é iniciar com Standard em ambientes de teste e assumir que é possível reduzir o tier posteriormente para controle de custos, o que não é viável.
Gabarito — Questão 4
Resposta: B
Quando uma VNet spoke é conectada ao Virtual WAN hub, o serviço cria automaticamente um peering gerenciado entre a VNet e o hub. Se essa mesma VNet já possuir um peering com uma VNet hub tradicional, os dois peerings coexistirão no nível técnico, mas o roteamento ficará assimétrico ou ambíguo, pois a VNet terá dois caminhos de saída para o restante da topologia.
A solução correta é remover o peering manual com a VNet hub tradicional antes ou logo após conectar a VNet ao Virtual WAN. A alternativa A ignora o conflito de roteamento resultante. A alternativa C é incorreta porque VNets com peerings existentes podem ser conectadas ao Virtual WAN sem recriação. A alternativa D é falsa porque, embora os planos de controle sejam distintos, o plano de dados compartilha a tabela de rotas efetivas da VNet, gerando conflito real.
Gabarito — Questão 5
Resposta: B
No Virtual WAN Standard, a conectividade entre hubs de regiões diferentes é nativa e automática. A Microsoft mantém uma backbone global entre os hubs do mesmo Virtual WAN resource, e o plano de controle propaga as rotas entre eles sem que o arquiteto precise configurar peering global, VNets de trânsito ou recursos adicionais.
A alternativa A descreve o comportamento de uma topologia hub-and-spoke tradicional, não do Virtual WAN. A alternativa C representa uma solução de contorno usada em arquiteturas legadas. A alternativa D introduz uma restrição de assinatura e resource group que não existe no produto: hubs de diferentes assinaturas podem compor o mesmo Virtual WAN e se comunicar entre regiões.