Skip to main content

Technical Lab: Create a prefix for public IP addresses

Questions​

Question 1 — Multiple Choice​

A network team needs to ensure that all instances of a set of virtual machines receive public IP addresses belonging to a contiguous and predictable block, facilitating the creation of firewall rules in external partner systems.

Which Azure resource directly meets this requirement?

A) Individual static public IP addresses associated with each NIC

B) A public IP prefix, which reserves a contiguous range of IPv4 or IPv6 addresses

C) A NAT Gateway with dedicated public IP shared among all instances

D) A Load Balancer public with a single frontend IP

Question 2 — Technical Scenario​

An architect configured a public IP prefix with size /28 in the East US region. When attempting to associate the ninth public IP address derived from this prefix to a new NIC, the operation fails.

What is the most likely cause of the failure?

A) Public IP prefixes cannot be used with NICs directly; they require a Load Balancer

B) The East US region does not support /28 prefixes for IPv4

C) A /28 prefix contains exactly 16 addresses, but Azure automatically reserves the first 3 for internal use, leaving only 13 available

D) A /28 prefix contains exactly 16 addresses, and all have been allocated to the eight previous NICs plus auxiliary prefix resources

Question 3 — True or False​

A public IP prefix created in Azure with Standard SKU can contain IPv4 and IPv6 addresses simultaneously in a single prefix resource.

True or False?

Question 4 — Technical Scenario​

Observe the sequence of commands below:

az network public-ip prefix create \
  --name meu-prefixo \
  --resource-group rg-producao \
  --location eastus \
  --length 31 \
  --version IPv4

After creation, an engineer attempts to derive three independent public IPs from this prefix to associate them with three distinct virtual machines. The third association fails.

What is the correct explanation for the failure?

A) The --version IPv4 parameter prevents more than two addresses from being derived from the same prefix

B) A prefix with length /31 contains only two usable addresses, exhausting on the second allocation

C) The public IP prefix resource does not support length /31; the minimum allowed size is /28

D) Azure limits to three the number of public IPs per resource group, and the limit has already been reached

Question 5 — Multiple Choice​

When creating a public IP prefix, which of the following statements correctly describes the availability zone behavior of addresses derived from this prefix?

A) Each derived IP can be assigned to a different availability zone, regardless of the prefix configuration

B) The prefix itself defines the zone; all derived IPs obligatorily inherit the same zone configuration from the parent prefix

C) Public IP prefixes do not support availability zones; this feature is exclusive to individual public IPs

D) The availability zone is configured individually on each derived IP, without relation to the prefix

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The public IP prefix is the Azure resource designed specifically to reserve a contiguous and predictable range of public IP addresses. This allows administrators of external partners to create firewall rules based on a single CIDR block, instead of managing individual addresses.

Alternative A describes a functional practice, but one that does not guarantee contiguity or block predictability. Alternative C (NAT Gateway) concentrates outbound traffic, but does not distribute distinct IPs per instance. Alternative D (Load Balancer) exposes a single ingress IP, without meeting the requirement of individual IPs per instance.

Answer Key — Question 2​

Answer: D

A /28 prefix contains exactly 2⁴ = 16 IPv4 addresses. Azure does not reserve addresses internally within the prefix in the same way it does in VNet subnets. Therefore, all 16 addresses are available for allocation as individual public IPs. If eight NICs have already been associated and other prefix resources (such as the prefix object itself and auxiliary associations) have consumed the remaining addresses, the ninth attempt fails due to pool exhaustion.

Alternative C is a distractor that confuses VNet subnet reservation rules (where the first 5 addresses are reserved) with public IP prefix behavior, which are distinct contexts. Alternative B is false: the East US region supports /28. Alternative A is false: prefixes can be used directly with NICs.

Answer Key — Question 3​

Answer: False

A single public IP prefix resource exclusively supports one address family: IPv4 or IPv6, never both simultaneously. If an architecture requires public IPs from both families, it is necessary to create two separate prefixes, one for each version.

This behavior is relevant in dual-stack scenarios, where incorrect planning can lead to attempting to derive an IPv6 from an IPv4 prefix, resulting in failure. The statement is false because it mixes a fundamental design limitation with flexibility that the resource does not possess.

Answer Key — Question 4​

Answer: B

A prefix with length /31 contains 2¹ = 2 addresses. Azure allows creating public IP prefixes with sizes between /28 (16 addresses) and /31 (2 addresses) for IPv4. Therefore, /31 is a valid value, discarding alternative C.

With only two addresses available, the first two derivations succeed and the third fails due to exhaustion. Alternative A is technically unfounded: the --version parameter defines the address family, not limits the quantity. Alternative D confuses a fictitious resource group limit with the actual service behavior.

Answer Key — Question 5​

Answer: B

The availability zone configuration is defined at the time of prefix creation and all public IPs derived from this prefix obligatorily inherit the same zonal configuration. It is not possible to derive an IP with a different zone from that configured in the parent prefix.

This has direct architectural implications: if a prefix is created as zonal (for example, pinned to Zone 1), the resources that consume IPs from this prefix must be in the same zone to ensure availability alignment. Creating the prefix as zone-redundant is the correct choice when consuming resources need resilience across zones. Alternatives A and D describe behavior that the resource does not possess. Alternative C is false: Standard prefixes support availability zones.