Technical Lab: Plan and implement a custom public IP address prefix (bring your own IP)
Questions
Question 1 — Multiple Choice
A network team needs to migrate a block of public IPs already used in production to Azure, maintaining the same addresses visible on the internet. During planning, the architect states that the prefix must be validated by Azure before any individual address allocation.
What is the minimum CIDR block size requirement accepted by Azure for a custom public IP prefix (BYOIP)?
A) /28
B) /24
C) /22
D) /16
Question 2 — Technical Scenario
An organization completed the onboarding process for a custom public IP prefix in Azure. The prefix was successfully created in the portal, but when attempting to create a derived public IP prefix from it, the operation fails with a validation error.
The engineer checks the resource state and finds the following:
ProvisioningState : Succeeded
CommissionedState : Provisioning
CustomIPPrefixParent : null
What is the most likely cause of the failure?
A) The prefix has not been commissioned yet, therefore it's not ready to allocate derived addresses
B) The absence of a CustomIPPrefixParent indicates that the prefix is invalid and needs to be recreated
C) The Succeeded state in ProvisioningState is contradictory with Provisioning in CommissionedState, which indicates resource corruption
D) BYOIP prefixes don't support the creation of derived public IP prefixes; IPs must be allocated individually
Question 3 — True or False
A custom public IP prefix in Azure can be directly associated with a virtual machine's network interface, the same way as a conventional public IP address.
True or False?
Question 4 — Technical Scenario
A company owns the 203.0.113.0/24 block registered with its RIR (Regional Internet Registry) and wants to bring it to Azure via BYOIP. The network team completed the following steps:
- Created a ROA (Route Origin Authorization) pointing to the Azure ASN
- Performed prefix ownership validation via signed authorization file
- Created the
CustomIPPrefixresource in Azure with the specified block
When checking the prefix announcement on the internet, they find that the block is not being announced. Which step was omitted?
A) The prefix needs to be associated with an Azure Route Server before being announced
B) The prefix commissioning was not executed, a necessary step to initiate BGP announcement by Azure
C) The ROA must point to the company's own ASN, not to the Azure ASN
D) A VPN gateway is required for Azure to assume the block announcement
Question 5 — Multiple Choice
When planning the use of a custom public IP prefix across multiple Azure regions, an architect needs to decide how to structure the resources. He has a /22 block and needs to distribute addresses across three different regions.
Which approach aligns with the Azure resource model for BYOIP in multi-regional scenarios?
A) Create a single global CustomIPPrefix and reference the same resource in all regions
B) Divide the /22 block into smaller prefixes (like /24), create a regional CustomIPPrefix for each subprefix, and derive IPs in each region separately
C) Create the CustomIPPrefix in a primary region and use VNet peering to make the addresses accessible in other regions
D) Register the /22 block as a single global prefix in Azure Front Door and map regions through routing rules
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure requires that the CIDR block of a custom public IP prefix be at least /24 (256 addresses). Smaller blocks, like /28, are not accepted because Azure needs a prefix large enough to ensure routability and legitimacy of BGP announcement on the public internet.
The distractor /22 is plausible because it represents a larger and valid size, but it's not the accepted minimum. /16 is valid as the maximum supported size, not minimum. Choosing /28 reflects confusion with private subnet limits or conventional public IP prefixes, which have distinct rules.
Answer Key — Question 2
Answer: A
The CommissionedState field indicates which phase of the lifecycle the prefix is in. The Provisioning state means that Azure is still processing the commissioning, that is, preparing the BGP announcement of the block. While the prefix doesn't reach the Commissioned state, it cannot be used as a source to allocate derived public IP prefixes or individual addresses.
The central conceptual error of the distractors is treating ProvisioningState: Succeeded as indicative that the prefix is ready for use. This field only reflects that the resource was successfully created in the Azure control plane, not that commissioning was completed. These are two distinct and independent lifecycles.
Answer Key — Question 3
Answer: False
A custom public IP prefix is a container resource that represents a block of addresses. It cannot be directly associated with network interfaces or other compute resources. To do this, you must first derive public IP addresses or public IP prefixes from the custom prefix and then associate these derived resources to interfaces or load balancers.
The confusion occurs because the custom prefix appears alongside other public IP resources in the portal, but its function is exclusively for management and allocation of the block, not for direct assignment.
Answer Key — Question 4
Answer: B
The BYOIP process in Azure involves distinct steps: ownership validation, resource creation, and commissioning. Commissioning is the step that instructs Azure to initiate BGP announcement of the prefix on the internet. Without it, the block exists as a resource in Azure but remains invisible to external traffic.
Distractor C represents a frequent misconception: the ROA must, in fact, point to the Azure ASN (8075), authorizing Azure to originate the announcement. Changing the ROA to the company's own ASN would break the authorization chain and prevent valid announcement. Distractor A confuses the Azure Route Server, which is used for BGP integration with on-premises networks, not for BYOIP prefix announcement.
Answer Key — Question 5
Answer: B
The Azure resource model for BYOIP is regional: each CustomIPPrefix belongs to a specific region. To distribute addresses from a larger block across multiple regions, the correct approach is to subdivide the original block (for example, from /22 into three /24) and create an independent CustomIPPrefix in each target region, deriving addresses locally.
Distractor A is the most common error: there is no concept of global or multi-regional CustomIPPrefix in Azure. Distractor C confuses address availability with network connectivity: VNet peering doesn't make a public IP from one region allocatable in another. Distractor D mixes application layer services with public IP address management, which are completely distinct abstraction layers.