Pular para o conteúdo principal

Laboratório Técnico: Plan and implement a custom public IP address prefix (bring your own IP)

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de rede precisa migrar um bloco de IPs públicos já utilizados em produção para o Azure, mantendo os mesmos endereços visíveis na internet. Durante o planejamento, o arquiteto afirma que o prefixo deve ser validado pelo Azure antes de qualquer alocação de endereços individuais.

Qual é o requisito mínimo de tamanho de bloco CIDR aceito pelo Azure para um custom public IP prefix (BYOIP)?

A) /28
B) /24
C) /22
D) /16

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

Uma organização realizou o processo de onboarding de um custom public IP prefix no Azure. O prefixo foi criado com sucesso no portal, mas ao tentar criar um public IP prefix derivado a partir dele, a operação falha com erro de validação.

O engenheiro verifica o estado do recurso e encontra o seguinte:

ProvisioningState : Succeeded
CommissionedState : Provisioning
CustomIPPrefixParent : null

Qual é a causa mais provável da falha?

A) O prefixo ainda não foi comissionado, portanto não está pronto para alocar endereços derivados
B) A ausência de um CustomIPPrefixParent indica que o prefixo é inválido e precisa ser recriado
C) O estado Succeeded em ProvisioningState é contraditório com Provisioning em CommissionedState, o que indica corrupção do recurso
D) Prefixos BYOIP não suportam a criação de public IP prefixes derivados; os IPs devem ser alocados individualmente

Questão 3 — Verdadeiro ou Falso​

Um custom public IP prefix no Azure pode ser associado diretamente a uma interface de rede de máquina virtual, da mesma forma que um public IP address convencional.

Verdadeiro ou Falso?

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

Uma empresa possui o bloco 203.0.113.0/24 registrado em seu RIR (Regional Internet Registry) e deseja trazê-lo para o Azure via BYOIP. O time de redes concluiu os seguintes passos:

  1. Criou um ROA (Route Origin Authorization) apontando para o ASN do Azure
  2. Realizou a validação de posse do prefixo via arquivo de autorização assinado
  3. Criou o recurso CustomIPPrefix no Azure com o bloco informado

Ao verificar a anunciação do prefixo na internet, constata que o bloco não está sendo anunciado. Qual etapa foi omitida?

A) O prefixo precisa ser associado a um Azure Route Server antes de ser anunciado
B) O comissionamento do prefixo não foi executado, etapa necessária para iniciar o anúncio BGP pelo Azure
C) O ROA deve apontar para o ASN da própria empresa, não para o ASN do Azure
D) É necessário criar um gateway de VPN para que o Azure assuma o anúncio do bloco

Questão 5 — Múltipla Escolha​

Ao planejar o uso de um custom public IP prefix em múltiplas regiões do Azure, um arquiteto precisa decidir como estruturar os recursos. Ele tem um bloco /22 e precisa distribuir endereços entre três regiões diferentes.

Qual abordagem está alinhada com o modelo de recursos do Azure para BYOIP em cenários multirregionais?

A) Criar um único CustomIPPrefix global e referenciar o mesmo recurso em todas as regiões
B) Dividir o bloco /22 em prefixos menores (como /24), criar um CustomIPPrefix regional para cada subprefixo e derivar IPs em cada região separadamente
C) Criar o CustomIPPrefix em uma região primária e usar peering de VNet para tornar os endereços acessíveis nas demais regiões
D) Registrar o bloco /22 como um único prefixo global no Azure Front Door e mapear regiões por meio de regras de roteamento

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O Azure exige que o bloco CIDR de um custom public IP prefix tenha no mínimo /24 (256 endereços). Blocos menores, como /28, não são aceitos porque o Azure precisa de um prefixo suficientemente grande para garantir a roteabilidade e a legitimidade do anúncio BGP na internet pública.

O distrator /22 é plausível porque representa um tamanho maior e válido, mas não é o mínimo aceito. Já /16 é válido como tamanho máximo suportado, não mínimo. Escolher /28 reflete a confusão com limites de sub-redes privadas ou public IP prefixes convencionais, que têm regras distintas.

Gabarito — Questão 2​

Resposta: A

O campo CommissionedState indica em qual fase do ciclo de vida o prefixo se encontra. O estado Provisioning significa que o Azure ainda está processando o comissionamento, ou seja, preparando o anúncio BGP do bloco. Enquanto o prefixo não atingir o estado Commissioned, ele não pode ser usado como origem para alocar public IP prefixes derivados ou endereços individuais.

O erro conceitual central dos distratores é tratar ProvisioningState: Succeeded como indicativo de que o prefixo está pronto para uso. Esse campo reflete apenas que o recurso foi criado com sucesso no plano de controle do Azure, não que o comissionamento foi concluído. São dois ciclos de vida distintos e independentes.

Gabarito — Questão 3​

Resposta: Falso

Um custom public IP prefix é um recurso contêiner que representa um bloco de endereços. Ele não pode ser associado diretamente a interfaces de rede ou outros recursos de computação. Para isso, é necessário primeiro derivar public IP addresses ou public IP prefixes a partir do custom prefix e então associar esses recursos derivados às interfaces ou load balancers.

A confusão ocorre porque o custom prefix aparece junto a outros recursos de IP público no portal, mas sua função é exclusivamente de gerenciamento e alocação do bloco, não de atribuição direta.

Gabarito — Questão 4​

Resposta: B

O processo de BYOIP no Azure envolve etapas distintas: validação de posse, criação do recurso e comissionamento. O comissionamento é a etapa que instrui o Azure a iniciar o anúncio BGP do prefixo na internet. Sem ela, o bloco existe como recurso no Azure, mas permanece invisível para o tráfego externo.

O distrator C representa um equívoco frequente: o ROA deve, de fato, apontar para o ASN do Azure (8075), autorizando o Azure a originar o anúncio. Alterar o ROA para o ASN da própria empresa quebraria a cadeia de autorização e impediria o anúncio válido. O distrator A confunde o Azure Route Server, que é usado para integração BGP com redes on-premises, não para anúncio de prefixos BYOIP.

Gabarito — Questão 5​

Resposta: B

O modelo de recursos do Azure para BYOIP é regional: cada CustomIPPrefix pertence a uma região específica. Para distribuir endereços de um bloco maior entre múltiplas regiões, a abordagem correta é subdividir o bloco original (por exemplo, de /22 em três /24) e criar um CustomIPPrefix independente em cada região de destino, derivando os endereços localmente.

O distrator A é o erro mais comum: não existe o conceito de CustomIPPrefix global ou multirregional no Azure. O distrator C confunde a disponibilidade de endereços com conectividade de rede: peering de VNet não torna um IP público de uma região alocável em outra. O distrator D mistura serviços de camada de aplicação com gerenciamento de endereços IP públicos, que são camadas de abstração completamente distintas.