Laboratório Técnico: Create a virtual network (VNet)
Questões
Questão 1 — Múltipla Escolha
Você está projetando uma arquitetura no Azure com os seguintes requisitos: a VNet principal deve ter um espaço de endereçamento de 10.0.0.0/16, e uma sub-rede dedicada ao Azure Bastion deve ser criada dentro dela.
Qual das afirmações abaixo descreve corretamente um requisito obrigatório para essa sub-rede?
A) A sub-rede deve ter o nome BastionSubnet e pode usar qualquer prefixo /27 ou maior dentro do espaço da VNet.
B) A sub-rede deve ter o nome AzureBastionSubnet e requer um prefixo mínimo de /26.
C) A sub-rede deve ter o nome AzureBastionSubnet e pode usar qualquer prefixo desde que tenha ao menos 16 endereços disponíveis.
D) A sub-rede pode ter qualquer nome, desde que uma tag bastion=true seja aplicada e o prefixo seja /27 ou maior.
Questão 2 — Cenário Técnico
Um engenheiro cria duas VNets na mesma assinatura e na mesma região:
vnet-app:10.1.0.0/16vnet-data:10.1.128.0/17
Após configurar o VNet peering entre elas, os recursos em vnet-app não conseguem se comunicar com os recursos em vnet-data.
Qual é a causa mais provável do problema?
A) O peering entre VNets na mesma região não é suportado pelo Azure; é necessário usar VPN Gateway.
B) Os espaços de endereçamento das duas VNets se sobrepõem, o que invalida o peering.
C) O peering foi configurado apenas em uma direção e precisa ser habilitado nas duas VNets.
D) VNets na mesma assinatura exigem aprovação manual do peering por meio do portal de governança.
Questão 3 — Verdadeiro ou Falso
Afirmação: Após uma VNet ser criada no Azure, o espaço de endereçamento inicial pode ser expandido adicionando intervalos de endereços adicionais sem necessidade de recriar a VNet, desde que os novos intervalos não se sobreponham aos já existentes.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma equipe precisa implantar uma solução que exige os seguintes recursos dentro de uma única VNet:
- Uma sub-rede para VMs de aplicação:
10.2.1.0/24 - Uma sub-rede para o Azure Application Gateway v2:
10.2.2.0/24 - Uma sub-rede para o Azure Firewall:
10.2.3.0/24
Durante a implantação, a criação da sub-rede para o Azure Firewall falha. O engenheiro verifica que o prefixo /24 está disponível dentro da VNet e que não há sobreposição.
Qual é a causa mais provável da falha?
A) O Azure Firewall exige que sua sub-rede esteja em uma VNet dedicada, separada das demais cargas de trabalho.
B) O nome da sub-rede do Azure Firewall deve ser obrigatoriamente AzureFirewallSubnet.
C) O prefixo /24 é grande demais para o Azure Firewall, que aceita no máximo /26.
D) O Azure Firewall não pode coexistir na mesma VNet que o Application Gateway v2.
Questão 5 — Múltipla Escolha
Você precisa criar uma VNet no Azure usando o Azure CLI. Analise o comando abaixo:
az network vnet create \
--name vnet-producao \
--resource-group rg-networking \
--location eastus \
--address-prefixes 192.168.0.0/16
Uma sub-rede chamada snet-frontend com o prefixo 192.168.1.0/24 deve ser criada junto com a VNet no mesmo comando.
Qual parâmetro deve ser adicionado para atender a esse requisito?
A) --subnet-name snet-frontend --subnet-prefix 192.168.1.0/24
B) --subnet snet-frontend --cidr 192.168.1.0/24
C) --subnets snet-frontend=192.168.1.0/24
D) --subnet-name snet-frontend --subnet-address-prefix 192.168.1.0/24
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Azure Bastion exige que sua sub-rede tenha o nome exato AzureBastionSubnet, sem variações. Além disso, o prefixo mínimo aceito é /26, que fornece 64 endereços IP para acomodar a escala do serviço.
A alternativa A erra no nome da sub-rede. A alternativa C ignora o requisito mínimo de prefixo /26, pois apenas "16 endereços disponíveis" corresponderia a um /28, insuficiente. A alternativa D é incorreta porque o nome é obrigatório e tags não substituem esse requisito estrutural.
Escolher um prefixo menor que /26 ou um nome diferente resulta em falha na implantação do recurso Azure Bastion, não apenas em aviso.
Gabarito — Questão 2
Resposta: B
O Azure exige que os espaços de endereçamento de duas VNets em peering sejam completamente distintos, sem nenhuma sobreposição. O bloco 10.1.128.0/17 está contido dentro de 10.1.0.0/16, o que caracteriza sobreposição direta. O peering não é estabelecido nessa situação.
A alternativa C é um equívoco comum: o peering regional de fato precisa ser configurado nos dois lados, mas isso não é a causa aqui, pois a sobreposição impede o peering antes mesmo dessa etapa. A alternativa A é falsa; VNet peering na mesma região é totalmente suportado. A alternativa D não corresponde a nenhum comportamento real do Azure.
Esse cenário é clássico em projetos onde sub-redes de VNets diferentes são planejadas sem controle centralizado de IPAM.
Gabarito — Questão 3
Resposta: Verdadeiro
O Azure permite adicionar novos intervalos de endereços a uma VNet existente sem recriá-la. Essa operação é não destrutiva: os recursos e sub-redes existentes não são afetados. O único requisito é que os novos intervalos não se sobreponham aos já associados à VNet.
Esse comportamento é relevante em arquiteturas que crescem ao longo do tempo e precisam acomodar novas sub-redes sem redesenho completo. O equívoco comum é acreditar que o espaço de endereçamento é imutável após a criação, o que levaria a decisões de superprovisionar desnecessariamente o prefixo inicial.
Gabarito — Questão 4
Resposta: B
O Azure Firewall exige que sua sub-rede tenha o nome exato AzureFirewallSubnet. Qualquer outro nome faz com que a implantação do recurso falhe, independentemente do prefixo ou da disponibilidade de endereços.
A alternativa C contém uma inversão: o prefixo mínimo exigido para o Azure Firewall é /26, portanto um /24 é perfeitamente válido e maior que o mínimo. A alternativa A é falsa; o Azure Firewall pode coexistir com outros recursos na mesma VNet. A alternativa D também é falsa; não há restrição de coexistência entre Azure Firewall e Application Gateway v2 na mesma VNet.
Esse é um erro recorrente em implantações automatizadas via IaC quando o nome da sub-rede é parametrizado livremente.
Gabarito — Questão 5
Resposta: D
O Azure CLI usa --subnet-name para o nome da sub-rede e --subnet-address-prefix para o bloco CIDR quando a sub-rede é criada junto com a VNet no comando az network vnet create.
A alternativa A usa --subnet-prefix, que não é o parâmetro correto para esse comando. A alternativa B usa --subnet e --cidr, parâmetros que não existem nesse contexto. A alternativa C usa uma sintaxe de par chave-valor que não corresponde à CLI do Azure.
Confundir --subnet-prefix com --subnet-address-prefix é um erro comum ao migrar de memória entre versões da CLI ou ao usar autocompletar sem verificar a documentação atualizada.