Laboratório Técnico: Create a prefix for public IP addresses
Questões
Questão 1 — Múltipla Escolha
Uma equipe de rede precisa garantir que todas as instâncias de um conjunto de máquinas virtuais recebam endereços IP públicos pertencentes a um bloco contíguo e previsível, facilitando a criação de regras de firewall em sistemas de parceiros externos.
Qual recurso do Azure atende diretamente a esse requisito?
A) Endereços IP públicos estáticos individuais associados a cada NIC
B) Um prefixo de IP público, que reserva um intervalo contíguo de endereços IPv4 ou IPv6
C) Um NAT Gateway com IP público dedicado compartilhado entre todas as instâncias
D) Um Load Balancer público com um único frontend IP
Questão 2 — Cenário Técnico
Um arquiteto configurou um prefixo de IP público com tamanho /28 na região East US. Ao tentar associar o nono endereço IP público derivado desse prefixo a uma nova NIC, a operação falha.
Qual é a causa mais provável da falha?
A) Prefixos de IP público não podem ser usados com NICs diretamente; exigem um Load Balancer
B) A região East US não suporta prefixos /28 para IPv4
C) Um prefixo /28 contém exatamente 16 endereços, mas o Azure reserva automaticamente os 3 primeiros para uso interno, deixando apenas 13 disponíveis
D) Um prefixo /28 contém exatamente 16 endereços, e todos já foram alocados para as oito NICs anteriores mais recursos auxiliares do prefixo
Questão 3 — Verdadeiro ou Falso
Um prefixo de IP público criado no Azure com SKU Standard pode conter endereços IPv4 e IPv6 simultaneamente em um único recurso de prefixo.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Observe a sequência de comandos abaixo:
az network public-ip prefix create \
--name meu-prefixo \
--resource-group rg-producao \
--location eastus \
--length 31 \
--version IPv4
Após a criação, um engenheiro tenta derivar três IPs públicos independentes desse prefixo para associá-los a três máquinas virtuais distintas. A terceira associação falha.
Qual é a explicação correta para a falha?
A) O parâmetro --version IPv4 impede que mais de dois endereços sejam derivados do mesmo prefixo
B) Um prefixo com comprimento /31 contém apenas dois endereços utilizáveis, esgotando-se na segunda alocação
C) O recurso de prefixo de IP público não suporta comprimento /31; o tamanho mínimo permitido é /28
D) O Azure limita a três o número de IPs públicos por grupo de recursos, e o limite já foi atingido
Questão 5 — Múltipla Escolha
Ao criar um prefixo de IP público, qual das seguintes afirmações descreve corretamente o comportamento de zona de disponibilidade dos endereços derivados desse prefixo?
A) Cada IP derivado pode ser atribuído a uma zona de disponibilidade diferente, independentemente da configuração do prefixo
B) O prefixo em si define a zona; todos os IPs derivados herdam obrigatoriamente a mesma configuração de zona do prefixo pai
C) Prefixos de IP público não suportam zonas de disponibilidade; esse recurso é exclusivo de IPs públicos individuais
D) A zona de disponibilidade é configurada individualmente em cada IP derivado, sem relação com o prefixo
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O prefixo de IP público (Public IP Prefix) é o recurso do Azure projetado especificamente para reservar um intervalo contíguo e previsível de endereços IP públicos. Isso permite que administradores de parceiros externos criem regras de firewall baseadas em um único bloco CIDR, em vez de gerenciar endereços avulsos.
A alternativa A descreve uma prática funcional, mas que não garante contigüidade nem previsibilidade do bloco. A alternativa C (NAT Gateway) concentra saída de tráfego, mas não distribui IPs distintos por instância. A alternativa D (Load Balancer) expõe um único IP de entrada, sem atender ao requisito de IPs individuais por instância.
Gabarito — Questão 2
Resposta: D
Um prefixo /28 contém exatamente 2⁴ = 16 endereços IPv4. O Azure não reserva endereços internamente dentro do prefixo da mesma forma que faz em sub-redes de VNet. Portanto, todos os 16 endereços estão disponíveis para alocação como IPs públicos individuais. Se oito NICs já foram associadas e outros recursos do prefixo (como o próprio objeto de prefixo e associações auxiliares) consumiram os endereços restantes, a nona tentativa falha por esgotamento do pool.
A alternativa C é um distrator que confunde as regras de reserva de sub-redes de VNet (onde os 5 primeiros endereços são reservados) com o comportamento de prefixos de IP público, contextos distintos. A alternativa B é falsa: a região East US suporta /28. A alternativa A é falsa: prefixos podem ser usados diretamente com NICs.
Gabarito — Questão 3
Resposta: Falso
Um único recurso de prefixo de IP público suporta exclusivamente uma família de endereços: IPv4 ou IPv6, nunca ambas simultaneamente. Se uma arquitetura exige IPs públicos de ambas as famílias, é necessário criar dois prefixos separados, um para cada versão.
Esse comportamento é relevante em cenários de pilha dupla (dual-stack), onde o planejamento incorreto pode levar à tentativa de derivar um IPv6 de um prefixo IPv4, resultando em falha. A afirmação é falsa porque mistura um limite de design fundamental com a flexibilidade que o recurso não possui.
Gabarito — Questão 4
Resposta: B
Um prefixo com comprimento /31 contém 2¹ = 2 endereços. O Azure permite criar prefixos de IP público com tamanhos entre /28 (16 endereços) e /31 (2 endereços) para IPv4. Portanto, /31 é um valor válido, descartando a alternativa C.
Com apenas dois endereços disponíveis, as duas primeiras derivações têm sucesso e a terceira falha por esgotamento. A alternativa A é tecnicamente infundada: o parâmetro --version define a família do endereço, não limita a quantidade. A alternativa D confunde um limite fictício de grupo de recursos com o comportamento real do serviço.
Gabarito — Questão 5
Resposta: B
A configuração de zona de disponibilidade é definida no momento da criação do prefixo e todos os IPs públicos derivados desse prefixo herdam obrigatoriamente a mesma configuração zonal. Não é possível derivar um IP com zona diferente da configurada no prefixo pai.
Isso tem implicação direta de arquitetura: se um prefixo é criado como zonal (por exemplo, fixado na Zona 1), os recursos que consumirem IPs desse prefixo devem estar na mesma zona para garantir alinhamento de disponibilidade. Criar o prefixo como zone-redundant é a escolha correta quando os recursos consumidores precisam de resiliência entre zonas. As alternativas A e D descrevem um comportamento que o recurso não possui. A alternativa C é falsa: prefixos Standard suportam zonas de disponibilidade.