Technical Lab: Choose when to use a public IP address prefix
Questions
Question 1 — Multiple Choice
A security team needs to allow outbound traffic from multiple Azure virtual machines to on-premises systems protected by a firewall. The requirement is that all public IPs used belong to a contiguous and predictable range, so that the firewall rule is as simple and compact as possible.
Which Azure resource directly meets this requirement?
A) Allocate individual public IPs with Standard SKU and manually register them in a route table
B) Create a public IP prefix and provision public IPs from it
C) Use a NAT Gateway with a single public IP shared by all VMs
D) Associate the VMs to a public Load Balancer with static IP
Question 2 — Technical Scenario
An architect configured the following in the Azure portal:
Resource: Public IP Prefix
Size: /28
Region: East US
SKU: Standard
After provisioning, he tries to create a public IP with Basic SKU from this prefix.
What happens?
A) Creation succeeds, as the public IP SKU is independent of the prefix
B) Creation fails, as public IP prefixes only allow IPs with Standard SKU
C) Creation succeeds, but the IP stays in warning state until reclassified
D) Creation fails, as the /28 size is incompatible with Basic SKU IPs
Question 3 — True or False
A public IP prefix in Azure guarantees that all addresses in the range will be available for immediate use as soon as the prefix is provisioned, regardless of how many IPs have already been allocated from it by other subscriptions in the same region.
Question 4 — Technical Scenario
A company operates a SaaS service and its customers need to include the Azure environment's public IPs in allow lists. Currently, the company uses 12 individual public IPs with Standard SKU, allocated at different times, without any range pattern. Customers complain that the IP list grows unpredictably with each new provisioned resource.
The team considers migrating to a public IP prefix-based model. What is the main benefit of this change in this context?
A) IPs become shared between resources, reducing the total needed
B) The prefix provides a contiguous and announceable range, simplifying allow list management by customers
C) The prefix allows IPs to be reused across multiple regions simultaneously
D) IPs provisioned from a prefix have lower latency because they are pre-allocated at the edge
Question 5 — Multiple Choice
When provisioning a public IP prefix, the administrator must choose the prefix size. Considering the sizes supported by Azure, which statement below correctly describes a real limit of this choice?
A) The maximum supported size is /24, providing up to 256 addresses per prefix
B) It's possible to create a /31 prefix, providing exactly 2 usable addresses
C) The minimum supported size is /31 and maximum is /24, both within a single regional range
D) The minimum supported size is /28, providing 16 addresses, and maximum is /24, providing 256 addresses
Answer Key and Explanations
Answer Key — Question 1
Answer: B
A public IP prefix is exactly the resource designed for this scenario. It provisions a contiguous range of public IP addresses that belong to the same CIDR block, which allows external firewall rules to cover all IPs with a single network entry.
The other alternatives fail for distinct reasons: individual IPs allocated separately don't form a guaranteed contiguous range; a NAT Gateway solves the outbound problem but concentrates everything on a single IP, which may be undesirable for traceability; and a Load Balancer only exposes its own IP, not the VMs' individually.
Answer Key — Question 2
Answer: B
Public IP prefixes in Azure exclusively support IPs with Standard SKU. There's no compatibility with Basic SKU, and the SKU of the prefix and derived IPs must be consistent. This restriction exists because Basic SKU is in the deprecation process and doesn't offer the same availability and security guarantees as Standard.
The /28 size has no relation to the derived IP's SKU, which makes alternative D a plausible distractor, but technically incorrect.
Answer Key — Question 3
Answer: False
The public IP prefix reserves the CIDR range for the subscription that provisioned it, but individual addresses only become "in use" when public IPs are explicitly created from it. The critical point, however, is that the range is reserved exclusively for that subscription: other subscriptions in the same region don't have access to these addresses. The statement is false because it mixes the concept of block reservation with unrestricted immediate availability, creating an incorrect impression that there would be competition for addresses within the prefix.
Answer Key — Question 4
Answer: B
The central benefit of a public IP prefix in this context is the predictability and contiguity of the range. Instead of a growing list of scattered IPs, customers receive a single CIDR block to configure in their allow lists. Any new IP provisioned from the prefix will already be within this block, without requiring list updates.
The other alternatives describe behaviors that don't exist: IPs from a prefix aren't shared between resources, aren't valid across multiple regions simultaneously, and don't have latency advantages from being derived from a prefix.
Answer Key — Question 5
Answer: D
Azure supports public IP prefixes in sizes /28 (16 addresses), /29 (8), /30 (4), /31 (2), and /24 (256). Therefore, the minimum size is /28 and maximum is /24. Alternative A is incorrect by stating /24 is the maximum without mentioning the correct minimum. Alternative B is incorrect because /31 exists as a valid size but isn't the minimum. Alternative C gets the minimum wrong by citing /31. Only D correctly describes both extremes of the supported range.