Laboratório Técnico: Implement and manage virtual network connectivity by using Azure Virtual Network Manager
Questões
Questão 1 — Múltipla Escolha
Uma equipe de rede precisa aplicar uma política de conectividade que force todas as VNets de uma assinatura a rotear tráfego entre si sem exigir configuração individual de peering. O ambiente possui VNets em múltiplas regiões e o requisito é que novas VNets adicionadas ao escopo sejam incluídas automaticamente.
Qual combinação de recursos do Azure Virtual Network Manager atende a esse requisito?
A) Grupo de rede com associação estática + configuração de conectividade do tipo Mesh
B) Grupo de rede com associação dinâmica baseada em política + configuração de conectividade do tipo Mesh
C) Grupo de rede com associação dinâmica baseada em política + configuração de conectividade Hub and Spoke
D) Grupo de rede com associação estática + configuração de conectividade Hub and Spoke
Questão 2 — Cenário Técnico
Um administrador criou um Azure Virtual Network Manager com escopo em uma assinatura, definiu um grupo de rede, criou uma configuração de conectividade do tipo Hub and Spoke e clicou em "Save". Após aguardar alguns minutos, verificou que nenhum peering foi criado entre as VNets membros e a VNet hub.
Network Manager Scope: Subscription A
Network Group: group-prod (3 VNets como membros estáticos)
Connectivity Config: HubSpoke-Config (hub: vnet-hub, spokes: group-prod)
Status da configuração: Saved (não implantada)
Qual é a causa do comportamento observado?
A) As VNets membros precisam estar na mesma região da VNet hub para que o peering seja criado automaticamente
B) A configuração foi salva, mas não foi implantada em nenhuma região; a implantação é uma etapa separada e obrigatória
C) Grupos de rede com membros estáticos não suportam configurações do tipo Hub and Spoke
D) O Network Manager precisa de permissão explícita de Contributor em cada VNet individual para criar peerings
Questão 3 — Verdadeiro ou Falso
Uma regra de administrador de segurança (security admin rule) definida no Azure Virtual Network Manager pode bloquear tráfego em uma VNet mesmo que um Network Security Group aplicado à subnet dessa VNet permita explicitamente aquele tráfego.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma organização utiliza o Azure Virtual Network Manager com a seguinte configuração:
Topologia: Hub and Spoke
Hub: vnet-hub (região: East US)
Spokes: vnet-app1, vnet-app2 (região: East US)
Opção habilitada: "Enable direct connectivity between spokes"
A equipe relata que vnet-app1 consegue se comunicar com vnet-hub, mas não consegue se comunicar diretamente com vnet-app2, mesmo com a opção de conectividade direta habilitada.
Após investigação, constata-se que a configuração foi reimplantada na região correta. Qual é a causa mais provável?
A) Conectividade direta entre spokes em topologia Hub and Spoke exige que as VNets estejam em regiões diferentes
B) A opção "Enable direct connectivity between spokes" cria uma rota, mas não cria peering direto; o tráfego ainda depende de um NVA no hub
C) A configuração foi implantada, mas nenhuma implantação anterior foi removida, gerando conflito de estado
D) Existe um NSG em uma das subnets de vnet-app2 bloqueando o tráfego; regras de administrador de segurança não substituem NSGs em topologia spoke-to-spoke
Questão 5 — Múltipla Escolha
Ao definir o escopo de um Azure Virtual Network Manager, qual das afirmações abaixo descreve corretamente uma limitação real da plataforma?
A) Um Network Manager pode ter como escopo um grupo de gerenciamento, mas não pode gerenciar VNets de assinaturas filhas contidas nesse grupo
B) Um Network Manager pode gerenciar VNets de múltiplas assinaturas desde que essas assinaturas estejam dentro do escopo definido (assinatura ou grupo de gerenciamento)
C) O escopo de um Network Manager é imutável após a criação; para alterar o escopo é necessário recriar o recurso
D) Um Network Manager criado em uma assinatura A não pode incluir no escopo VNets de uma assinatura B, mesmo que ambas estejam no mesmo grupo de gerenciamento
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
A inclusão automática de novas VNets exige associação dinâmica, que utiliza Azure Policy para avaliar recursos e adicioná-los ao grupo de rede sem intervenção manual. A associação estática (opções A e D) requer que cada VNet seja adicionada explicitamente, o que contradiz o requisito de inclusão automática.
A topologia Mesh cria peering entre todos os membros do grupo de rede, estabelecendo conectividade any-to-any. A topologia Hub and Spoke (opção C) atenderia parcialmente, mas não cria comunicação direta entre todos os membros por padrão, exigindo roteamento pelo hub.
O equívoco comum é assumir que Hub and Spoke com conectividade direta habilitada equivale ao Mesh. A diferença fundamental está na intenção arquitetural e no comportamento de roteamento padrão de cada topologia.
Gabarito — Questão 2
Resposta: B
No Azure Virtual Network Manager, salvar uma configuração e implantá-la são etapas distintas. Salvar persiste a definição da configuração no plano de controle, mas não aplica nenhuma mudança nas VNets. A implantação (Deploy) é o ato de enviar a configuração para regiões específicas, o que de fato cria os peerings e aplica as políticas.
A opção A é incorreta porque o Hub and Spoke do AVNM suporta peering global entre regiões. A opção C é incorreta porque membros estáticos são plenamente suportados em topologias Hub and Spoke. A opção D representa um equívoco sobre permissões: o Network Manager precisa de permissão no escopo definido, não necessariamente em cada VNet individualmente, embora precise de acesso suficiente para gerenciar os recursos de rede.
O erro de não implantar após salvar é um dos mais frequentes em ambientes reais e em provas.
Gabarito — Questão 3
Resposta: Verdadeiro
As regras de administrador de segurança (security admin rules) operam em uma camada de precedência superior à dos NSGs. Elas são avaliadas antes das regras de NSG e podem forçar o bloqueio ou a permissão de tráfego independentemente do que o NSG defina.
Isso é especialmente relevante em cenários de governança centralizada, onde a equipe de plataforma precisa garantir que certas políticas de tráfego não possam ser contornadas por administradores de VNet individuais que controlam seus próprios NSGs.
A confusão comum é equiparar security admin rules ao comportamento dos NSGs, assumindo que a regra mais específica prevalece. No AVNM, a hierarquia é intencional: regras de administrador de segurança têm precedência sobre NSGs por design.
Gabarito — Questão 4
Resposta: C
Quando uma configuração é reimplantada sem que a implantação anterior seja explicitamente removida (ou substituída de forma limpa), podem ocorrer conflitos de estado entre a configuração ativa e a nova. O comportamento esperado após habilitar "Enable direct connectivity between spokes" é a criação de peering direto entre os spokes, o que deveria permitir a comunicação sem passar pelo hub.
A opção A é incorreta porque a conectividade direta entre spokes é suportada tanto em cenários intra-região quanto entre regiões. A opção B representa um equívoco conceitual relevante: a opção de conectividade direta justamente cria peering direto entre os spokes, não depende de NVA. A opção D inverte a hierarquia: security admin rules têm precedência sobre NSGs, não o contrário, e o cenário descreve ausência de comunicação, não bloqueio por NSG.
Em ambientes reais, sempre verifique o histórico de implantações e o estado atual antes de diagnosticar falhas de conectividade no AVNM.
Gabarito — Questão 5
Resposta: B
O Azure Virtual Network Manager suporta escopos em nível de assinatura ou grupo de gerenciamento. Quando o escopo é um grupo de gerenciamento, todas as assinaturas contidas nele (incluindo assinaturas filhas aninhadas) estão elegíveis para gerenciamento, o que permite governança centralizada em escala de organização.
A opção A é falsa: esse é exatamente o caso de uso mais valioso do escopo em grupo de gerenciamento. A opção C é falsa: o escopo pode ser modificado após a criação. A opção D é falsa e representa o equívoco mais comum: desde que a assinatura B esteja dentro do grupo de gerenciamento definido como escopo, o Network Manager pode gerenciar suas VNets normalmente.
Compreender a hierarquia de escopo é essencial para projetar soluções de conectividade centralizada em ambientes multi-assinatura.