Pular para o conteúdo principal

Laboratório Técnico: Create a virtual hub in Virtual WAN

Questões​

Questão 1 — Múltipla Escolha​

Ao provisionar um virtual hub dentro de um Azure Virtual WAN, um arquiteto precisa definir o espaço de endereço do hub. Qual afirmação descreve corretamente o comportamento esperado desse espaço de endereço?

A) O espaço de endereço do hub pode ser alterado livremente após a criação, sem impacto nas conexões existentes.

B) O espaço de endereço do hub deve ser um prefixo de no mínimo /24, e não pode se sobrepor aos endereços das redes spoke conectadas.

C) O espaço de endereço do hub é usado exclusivamente para os recursos de gateway internos do hub e não precisa ser roteável pelas redes spoke.

D) O espaço de endereço do hub é atribuído automaticamente pelo Azure e não pode ser definido pelo usuário no momento da criação.

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

Uma equipe de rede criou um Virtual WAN do tipo Standard e adicionou um virtual hub na região East US. Após a criação do hub, a equipe tenta conectar uma VNet spoke ao hub, mas a opção de associar a VNet está indisponível no portal. O hub foi criado há menos de 10 minutos.

Qual é a causa mais provável desse comportamento?

A) O Virtual WAN Standard não suporta conexões de VNet diretamente ao hub; é necessário utilizar um VPN Gateway dentro do hub.

B) O virtual hub ainda está no estado de provisionamento, e conexões de VNet só podem ser adicionadas após o hub atingir o estado Succeeded.

C) A VNet spoke está em uma assinatura diferente do Virtual WAN, o que exige uma configuração de peering manual antes de qualquer associação.

D) O hub na região East US requer que um Routing Intent seja configurado antes de aceitar conexões de VNet.

Questão 3 — Verdadeiro ou Falso​

Um virtual hub do tipo Basic pode ser atualizado para o tipo Standard após a criação sem necessidade de recriar o hub ou as conexões existentes, e essa atualização é irreversível.

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

Uma empresa precisa de conectividade entre filiais via Site-to-Site VPN e também roteamento seguro entre VNets, tudo gerenciado pelo mesmo virtual hub. Durante o planejamento, o arquiteto avalia qual SKU de Virtual WAN utilizar.

Considere a configuração abaixo:

Virtual WAN
  Tipo: Basic
  Hub: hub-eastus
    - Site-to-Site VPN Gateway: habilitado
    - VNet connections: 3 VNets spoke

Qual problema essa configuração apresenta em relação aos requisitos descritos?

A) O tipo Basic não suporta Site-to-Site VPN Gateway; esse recurso exige o tipo Standard.

B) O tipo Basic suporta Site-to-Site VPN, mas não permite conexões de VNet spoke ao hub, impossibilitando o roteamento entre VNets.

C) O tipo Basic suporta tanto VPN quanto conexões de VNet, mas o roteamento entre VNets spoke requer o tipo Standard.

D) O tipo Basic permite no máximo 2 conexões de VNet, tornando inviável conectar 3 VNets ao mesmo hub.

Questão 5 — Múltipla Escolha​

Um engenheiro precisa implantar um virtual hub com suporte a ExpressRoute, VPN Site-to-Site e User VPN (Point-to-Site) na mesma região. Qual combinação de afirmações descreve corretamente as restrições de gateway nesse cenário?

A) Cada tipo de gateway (ExpressRoute, VPN S2S, User VPN) deve ser implantado em hubs separados; um único hub não suporta os três simultaneamente.

B) Um único hub Standard suporta os três gateways simultaneamente, mas cada gateway precisa ser criado de forma independente e tem seu próprio processo de provisionamento.

C) O gateway de User VPN e o gateway de VPN Site-to-Site compartilham a mesma instância de recurso dentro do hub, sendo necessário criar apenas um dos dois.

D) Um hub Standard suporta os três gateways, mas o ExpressRoute Gateway só pode ser adicionado se o hub foi criado originalmente com essa opção habilitada.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O espaço de endereço do virtual hub deve ser um bloco CIDR de no mínimo /24. Esse range é reservado pelo Azure para alocar os componentes internos do hub, como os gateways e os Network Virtual Appliances (NVAs). Além disso, ele não pode se sobrepor aos endereços das VNets conectadas nem a outros hubs dentro do mesmo Virtual WAN, pois isso causaria conflitos de roteamento.

O principal erro representado pelos distratores é confundir o espaço do hub com um range meramente administrativo ou com algo gerenciado de forma totalmente automática. Na prática, a escolha errada desse range no momento da criação tem consequências sérias: o espaço de endereço do hub não pode ser alterado após a criação, tornando necessário recriar o hub para corrigir um erro de planejamento.

Gabarito — Questão 2​

Resposta: B

Após a criação de um virtual hub, o Azure executa um processo interno de provisionamento que pode levar vários minutos. Enquanto o hub estiver no estado Provisioning, operações como adicionar conexões de VNet, gateways ou políticas de roteamento ficam bloqueadas. Somente quando o status transita para Succeeded o hub está pronto para receber configurações adicionais.

Os demais distratores exploram equívocos legítimos: o Virtual WAN Standard sim suporta conexões diretas de VNet (eliminando A); diferenças de assinatura podem exigir aprovação, mas não bloqueiam a opção no portal desta forma (eliminando C); e o Routing Intent não é pré-requisito para conectar VNets (eliminando D). Agir prematuramente sobre um hub recém-criado é um erro operacional frequente em ambientes reais.

Gabarito — Questão 3​

Resposta: Verdadeiro

A atualização de um Virtual WAN do tipo Basic para Standard é suportada pela Microsoft e pode ser realizada sem recriar o hub ou as conexões existentes. Contudo, essa migração é irreversível: uma vez no tipo Standard, não é possível fazer downgrade para Basic. Esse comportamento é relevante do ponto de vista de custo e governança, pois o tipo Standard tem um custo de processamento de dados por hub maior que o Basic.

O ponto não óbvio aqui é que a irreversibilidade se aplica ao nível do Virtual WAN, não apenas do hub individualmente. Atualizar o WAN implica que todos os hubs dentro dele também passam a operar sob as capacidades e os custos do tipo Standard.

Gabarito — Questão 4​

Resposta: C

O Virtual WAN do tipo Basic suporta Site-to-Site VPN e permite conectar VNets spoke ao hub. O que ele não suporta é o roteamento transitivo entre VNets spoke: pacotes originados em uma VNet spoke não são encaminhados pelo hub para outra VNet spoke no tipo Basic. Esse comportamento de roteamento entre spokes exige o tipo Standard, que habilita o roteamento transitivo completo dentro do hub.

Os distratores A e D são factualmente incorretos: Basic suporta S2S VPN e não tem limite fixo de 2 VNets. O distrator B erra ao afirmar que VNets não podem ser conectadas ao tipo Basic. Confundir "conectar VNets ao hub" com "rotear entre VNets pelo hub" é um dos erros de planejamento mais comuns ao dimensionar um Virtual WAN.

Gabarito — Questão 5​

Resposta: B

Um único virtual hub do tipo Standard suporta simultaneamente um ExpressRoute Gateway, um VPN Site-to-Site Gateway e um User VPN Gateway (Point-to-Site). Cada um desses gateways é um recurso independente dentro do hub, com seu próprio ciclo de provisionamento, que pode levar de 20 a 45 minutos cada. Eles coexistem no mesmo hub sem conflito.

O distrator C representa um equívoco estrutural importante: o User VPN Gateway e o VPN S2S Gateway são recursos distintos e separados, não compartilham instância. O distrator D é incorreto porque o ExpressRoute Gateway pode ser adicionado a qualquer hub Standard existente, independentemente de como ele foi criado originalmente. Compreender que cada gateway tem seu próprio tempo de provisionamento é crítico para o planejamento de implantações em produção.