Laboratório Técnico: Integrate a virtual hub with a third-party NVA for cloud connectivity
Questões
Questão 1 — Múltipla Escolha
Uma equipe de rede precisa integrar um NVA (Network Virtual Appliance) de terceiros em um Virtual WAN hub para inspecionar o tráfego entre branches e o Azure. O fabricante do NVA confirmou que o appliance é compatível com o programa de integração da Microsoft.
Qual é o requisito fundamental para que um NVA de terceiros possa ser implantado diretamente dentro de um Virtual WAN hub gerenciado?
A) O NVA deve ser implantado manualmente em uma spoke VNet e conectado ao hub via VNet peering, sem necessidade de qualificação adicional.
B) O NVA deve ser uma oferta publicada no Azure Marketplace e aprovada para integração com o Virtual WAN hub pelo programa de parceiros da Microsoft.
C) O NVA deve ser implantado como uma VM standalone e ter uma UDR apontando seu IP privado como next-hop nas route tables do hub.
D) O NVA deve suportar exclusivamente o protocolo BGP sobre IPsec para ser aceito como recurso gerenciado dentro do hub.
Questão 2 — Cenário Técnico
Um engenheiro está configurando um NVA de terceiros integrado a um Virtual WAN hub. Após o provisionamento da NVA infrastructure, ele observa que o tráfego entre duas VNets spoke conectadas ao mesmo hub não está passando pelo NVA, mesmo com as configurações de routing intent habilitadas.
Hub: eastus-vwan-hub
NVA: Deployed (status: Succeeded)
Routing Intent: Private Traffic -> NVA (configured)
Spoke VNet A -> Hub: Connected
Spoke VNet B -> Hub: Connected
Observado: Tráfego Spoke A <-> Spoke B bypassa o NVA
Qual é a causa mais provável para esse comportamento?
A) O NVA não suporta tráfego leste-oeste entre spokes; essa função é exclusiva do Azure Firewall quando usado como next-hop no hub.
B) O Routing Intent foi configurado corretamente, mas as VNets spoke ainda possuem custom route tables com rotas estáticas que sobrepõem as rotas propagadas pelo hub.
C) O NVA integrado ao hub só intercepta tráfego norte-sul entre on-premises e Azure; tráfego entre spokes requer uma topologia hub-spoke clássica separada.
D) O status "Succeeded" do NVA refere-se apenas ao provisionamento da infraestrutura, não à ativação do plano de dados; é necessário reiniciar o recurso manualmente.
Questão 3 — Verdadeiro ou Falso
Quando um NVA de terceiros é integrado a um Virtual WAN hub por meio do Routing Intent, o hub passa a anunciar automaticamente rotas de prefixo /0 para todas as conexões (branches, VNets e ExpressRoute) como next-hop apontando para o NVA, sem necessidade de configuração adicional de BGP ou route tables no NVA em si.
A afirmação acima é verdadeira ou falsa?
Questão 4 — Cenário Técnico
Uma empresa utiliza um Virtual WAN hub com um NVA de terceiros integrado para conectividade de branches via SD-WAN. O time de rede precisa escalar a capacidade do NVA para suportar maior throughput. O arquiteto propõe aumentar o número de instâncias do NVA dentro do hub.
NVA atual: 2 unidades de escala
Necessidade: suportar até 3 Gbps de throughput agregado
Fabricante recomenda: 4 unidades de escala para essa carga
Ao aumentar as scale units do NVA no hub, qual comportamento o engenheiro deve esperar em relação ao roteamento e à disponibilidade?
A) Cada unidade de escala adicional cria uma instância independente com um IP público dedicado; o balanceamento deve ser configurado manualmente via Traffic Manager.
B) O Virtual WAN gerencia automaticamente o balanceamento de carga entre as instâncias do NVA, pois as scale units são abstraídas como um único recurso lógico dentro do hub.
C) Aumentar as scale units exige recriar o recurso NVA no hub do zero, causando interrupção total de conectividade durante a operação.
D) As scale units adicionais funcionam apenas como instâncias de standby; o tráfego só é redistribuído se a instância primária falhar, sem ganho de throughput agregado.
Questão 5 — Múltipla Escolha
Um arquiteto precisa escolher entre duas abordagens para inspecionar tráfego em um ambiente Virtual WAN:
| Abordagem | Descrição |
|---|---|
| A | Implantar o NVA de terceiros diretamente dentro do Virtual WAN hub usando integração nativa |
| B | Implantar o NVA de terceiros em uma spoke VNet dedicada e usar UDRs para redirecionar tráfego |
O requisito principal é que branches conectados via Site-to-Site VPN no hub tenham seu tráfego inspecionado pelo NVA antes de chegar às VNets spoke, com o menor overhead operacional de roteamento possível.
Qual abordagem atende melhor ao requisito e por quê?
A) A Abordagem B, pois UDRs oferecem controle granular por prefixo, evitando dependência de recursos gerenciados pela Microsoft.
B) A Abordagem A, pois o NVA integrado ao hub com Routing Intent intercepta nativamente o tráfego entre branches e spokes sem exigir manutenção manual de UDRs.
C) A Abordagem B, pois NVAs integrados ao hub não suportam inspeção de tráfego originado de conexões Site-to-Site VPN, apenas de peerings de VNet.
D) A Abordagem A, mas somente se o NVA também estiver registrado como BGP peer com o hub usando um ASN privado abaixo de 65000.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Para que um NVA seja implantado como recurso gerenciado dentro de um Virtual WAN hub, ele precisa ser uma oferta publicada no Azure Marketplace e homologada pelo programa de parceiros de integração da Microsoft. Esse processo garante que o NVA exponha as APIs e o modelo de gerenciamento exigidos pelo Virtual WAN para provisionamento, escalonamento e roteamento integrado.
O principal equívoco representado pelos distratores é confundir a integração nativa ao hub com topologias alternativas válidas, porém distintas: implantar o NVA em uma spoke VNet com UDRs (Alternativa A) é uma abordagem legítima, mas não constitui integração ao hub. A dependência exclusiva de BGP sobre IPsec (Alternativa D) é um requisito de conectividade de branches, não de elegibilidade do NVA para integração ao hub.
Escolher a Alternativa A resultaria em uma topologia funcional, mas sem os benefícios de gerenciamento centralizado e Routing Intent disponíveis na integração nativa.
Gabarito — Questão 2
Resposta: B
O Routing Intent instrui o hub a programar rotas que apontam para o NVA como next-hop nas conexões gerenciadas. No entanto, se as VNets spoke possuem custom route tables com rotas estáticas ou associações a route tables que não respeitam as rotas propagadas pelo hub, essas rotas locais têm precedência e o tráfego não é desviado para o NVA.
A Alternativa A está incorreta porque NVAs integrados ao hub com Routing Intent são capazes de interceptar tráfego leste-oeste, não apenas norte-sul. Essa é uma limitação que existia em topologias clássicas sem Routing Intent. A Alternativa C descreve um comportamento que não corresponde à arquitetura atual do Virtual WAN. A Alternativa D é um distrator plausível, mas o status "Succeeded" no plano de controle implica que o plano de dados está operacional; o problema descrito é de conflito de roteamento, não de inicialização do recurso.
Gabarito — Questão 3
Resposta: Falso
A afirmação contém uma imprecisão importante: embora o Routing Intent de fato simplifique o roteamento ao programar automaticamente as conexões do hub para usar o NVA como next-hop, isso não elimina toda necessidade de configuração no NVA. O NVA ainda precisa estar corretamente configurado para processar e encaminhar o tráfego no plano de dados. Além disso, o comportamento de anúncio de rotas /0 ocorre para tráfego de internet (internet traffic policy), enquanto para tráfego privado o hub anuncia prefixos mais específicos, não necessariamente uma rota default agregada única para todos os cenários.
O ponto crítico é que o Routing Intent atua no plano de controle do hub, mas a responsabilidade pelo plano de dados e pela configuração funcional do NVA permanece com o operador. Assumir que a integração é totalmente passiva do lado do NVA é um equívoco comum que leva a falhas silenciosas de inspeção.
Gabarito — Questão 4
Resposta: B
No modelo de integração de NVAs no Virtual WAN hub, as scale units são uma abstração gerenciada: o Virtual WAN trata o conjunto de instâncias como um único recurso lógico e gerencia internamente o balanceamento de carga entre elas. O engenheiro não precisa configurar load balancers externos nem gerenciar IPs individuais por instância.
A Alternativa A descreve o comportamento de recursos não gerenciados implantados em spokes, não de NVAs integrados ao hub. A Alternativa C seria verdadeira em alguns recursos legados, mas NVAs integrados ao hub suportam atualização de scale units sem recriação completa do recurso. A Alternativa D descreve o modelo de alta disponibilidade ativo-passivo, que não corresponde ao comportamento das scale units, projetadas para escalonamento horizontal ativo-ativo.
Gabarito — Questão 5
Resposta: B
A Abordagem A com Routing Intent é a que melhor atende ao requisito porque o Virtual WAN hub programa automaticamente as conexões Site-to-Site VPN para usar o NVA integrado como next-hop. Isso elimina a necessidade de criar e manter UDRs manualmente para cada novo branch ou prefixo adicionado, reduzindo diretamente o overhead operacional.
A Abordagem B (Alternativa A) é tecnicamente viável, mas exige manutenção contínua de UDRs sempre que novos branches ou prefixos são adicionados, o que contradiz o requisito de menor overhead operacional. A Alternativa C está incorreta: NVAs integrados ao hub com Routing Intent inspecionam tráfego originado tanto de conexões VPN quanto de peerings de VNet. A Alternativa D é um distrator que mistura corretamente a necessidade de BGP em alguns cenários de conectividade com um requisito de ASN que não existe como restrição para a integração ao hub.