Troubleshooting Lab: Create a prefix for public IP addresses
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team maintains a production environment in the West Europe region with a Standard SKU public IP prefix /28 created six months ago. The environment has 14 virtual machines, each with a public IP derived from this prefix. Today, when trying to provision the 15th virtual machine with a new public IP derived from the same prefix, the operation fails with the following output:
az network public-ip create \
--name vm15-pip \
--resource-group rg-prod-we \
--allocation-method Static \
--sku Standard \
--public-ip-prefix /subscriptions/.../publicIPPrefixes/prefixo-prod \
--location westeurope
ERROR: (PublicIPPrefixExhausted) The public IP prefix
'/subscriptions/.../publicIPPrefixes/prefixo-prod' has no available
IP addresses. The prefix is exhausted.
Additional information collected by the team:
- The subscription has a limit of 100 public IPs and only 22 are in use in total
- The
West Europeregion has no capacity alerts in Azure Service Health - The resource group
rg-prod-wehas an active deletion lock policy - Two of the 14 VMs were deallocated yesterday, but their public IPs remain associated with the NICs
What is the root cause of the failure?
A) The subscription's public IP limit has been reached and no new IP can be created
B) The /28 prefix has 16 addresses, and with 14 addresses allocated there would still be space, so the resource group's lock policy is preventing creation
C) The /28 prefix has exactly 16 addresses, all already allocated as individual public IPs, including the IPs from deallocated VMs that remain reserved
D) The deallocated state of the two VMs corrupted the internal prefix state, blocking new allocations
Scenario 2 — Action Decision
The network team identified that an IPv4 public IP prefix with length /28 created in the Brazil South region needs to be migrated to the East US 2 region, as the client's entire infrastructure is being relocated. The operational problem's cause is clear: the public IPs derived from the current prefix are specific to the Brazil South region and cannot be used by resources in the new region.
The migration must occur during a 30-minute maintenance window, in production, with the following known facts:
- Six applications depend on the IPs derived from the current prefix for partner firewall rules
- Partners have been notified and agreed to update rules within 72 hours after migration
- The original prefix cannot be deleted while there are derived IPs associated with resources
- A new
/28prefix already exists in theEast US 2region with 16 available addresses
What is the correct action to take during the maintenance window?
A) Delete the old prefix in Brazil South immediately and associate resources with the new prefix in East US 2
B) Disassociate the derived IPs from the old prefix from resources, associate the new IPs from the prefix in East US 2 and communicate the new addresses to partners within the agreed timeframe
C) Keep both prefixes active simultaneously and configure traffic routing between regions until all partners update their rules
D) Request Microsoft support to transfer the CIDR block from the prefix in Brazil South to East US 2, preserving the same IP addresses
Scenario 3 — Root Cause
An engineer executes the following command to create a public IP prefix:
az network public-ip prefix create \
--name prefixo-dmz \
--resource-group rg-dmz \
--location eastus \
--length 30 \
--version IPv4 \
--zone 1 2 3
The command returns success. Then, the engineer tries to create a public IP derived from this prefix and associate it with a Basic SKU NIC:
az network public-ip create \
--name pip-dmz-01 \
--resource-group rg-dmz \
--allocation-method Static \
--sku Basic \
--public-ip-prefix /subscriptions/.../publicIPPrefixes/prefixo-dmz \
--location eastus
ERROR: (InvalidParameter) Public IP address SKU must be Standard
when created from a public IP prefix.
The engineer reports that the prefix was created successfully and that the target NIC was available and without previous associations. The team suspects that the error is related to the availability zones configured in the prefix.
What is the root cause of the observed error?
A) Prefixes with availability zones configured do not allow deriving public IPs via CLI; the operation must be done through the Azure portal
B) The /30 length is incompatible with availability zone configurations, invalidating the prefix after creation
C) Public IPs derived from a public IP prefix must mandatorily have Standard SKU; the attempt to create an IP with Basic SKU violates this restriction
D) Availability zones 1 2 3 configure the prefix as zone-redundant, and IPs derived from zone-redundant prefixes cannot be associated with NICs directly
Scenario 4 — Diagnostic Sequence
An administrator receives the following report: "We created a public IP prefix a week ago and today, when trying to delete it, the operation fails without a clear error message in the portal."
The administrator has the following investigation steps available, presented out of order:
- Check if there are individual public IPs associated with active resources that were derived from the prefix
- Try to delete the prefix again after confirming that no derived IP is in use
- List all public IPs in the subscription and filter by the
publicIPPrefixfield to identify dependencies - Check if the resource group has an active deletion lock at the prefix resource level
- Disassociate or delete each derived public IP that is still linked to a resource
What is the correct diagnostic sequence?
A) 4 → 1 → 3 → 5 → 2
B) 1 → 3 → 4 → 5 → 2
C) 3 → 1 → 5 → 4 → 2
D) 4 → 3 → 1 → 5 → 2
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
The decisive clue is in the prefix mathematics combined with the IP state. A /28 prefix contains exactly 2⁴ = 16 addresses. With 14 active VMs and 2 deallocated VMs, there are 16 derived IPs in total, all still associated with NICs. The deallocated state of a VM in Azure does not automatically release the public IP linked to the NIC; the IP remains reserved and allocated while the association exists. Therefore, the prefix is genuinely exhausted.
The information about the subscription limit (100 IPs, 22 in use) is deliberately irrelevant: the problem is not subscription quota, but exhaustion of the specific prefix block. The resource group's lock policy prevents deletions, not creations, making option B incoherent.
Option D represents the most dangerous error: attributing the problem to state corruption would lead to opening an unnecessary support ticket, delaying the real solution, which is simply disassociating IPs from deallocated VMs or creating a second prefix.
Answer Key — Scenario 2
Answer: B
The scenario's critical restriction is the order of operations: the original prefix cannot be deleted while there are derived IPs associated. This eliminates option A immediately, as the direct deletion attempt would fail before any progress.
Option D describes an impossible operation: CIDR blocks of public IP prefixes are region-specific and cannot be transferred between regions by Microsoft; IP addresses from different regions belong to different routing ranges.
Option C is technically unfeasible in practical terms: prefixes from different regions do not establish automatic routing between themselves, and the 30-minute window cannot accommodate this approach.
Option B is the only one that respects all restrictions: disassociation of old IPs to enable future prefix deletion, association of new IPs from the prefix in East US 2, and communication within the agreed timeframe with partners.
Answer Key — Scenario 3
Answer: C
The error message is direct and the clue is in the command output itself: Public IP address SKU must be Standard when created from a public IP prefix. This is a fundamental resource restriction: any public IP derived from a public IP prefix must have Standard SKU, regardless of any other configuration.
The information about availability zones is deliberately irrelevant to this specific error. The prefix was created successfully with --zone 1 2 3, which is valid. The error has no relation to zones; it would occur equally in a prefix without configured zones.
Option D represents the most common reasoning error: associating zone behavior with the observed problem because it seems like the "different" variable in the command. Acting on this hypothesis would lead the engineer to recreate the prefix without zones, only to encounter the same error again.
Answer Key — Scenario 4
Answer: D
The correct sequence is 4 → 3 → 1 → 5 → 2, following diagnostic logic from simplest to most destructive:
- Step 4 first: checking deletion lock at the resource level is a non-destructive and immediate check that can explain the failure without any other investigation.
- Step 3 next: listing all derived IPs with filter by
publicIPPrefixprovides complete visibility of dependencies before any action. - Step 1 after: confirming which of these IPs are effectively associated with active resources refines the diagnosis.
- Step 5: disassociating or deleting linked IPs is a destructive action and should occur only after confirming dependencies.
- Step 2 last: attempting prefix deletion only after ensuring there are no more dependencies.
Option A reverses steps 1 and 3, which is less efficient: checking lock before mapping dependencies is correct, but checking each IP individually before listing all is redundant. Option B skips lock verification, which could be the immediate cause. Option C starts with listing without checking lock, which may lead to unnecessary disassociations if the cause is just a resource lock.
Troubleshooting Tree: Create a prefix for public IP addresses
Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Medium blue | Diagnostic question |
| Orange | Intermediate verification or validation |
| Red | Identified cause |
| Green | Recommended action or resolution |
To use this tree when facing a real problem, start with the root node describing the observed symptom and follow the branching by answering each question based on what is verifiable in the environment. Diagnostic questions (blue) require direct observation before advancing; verification nodes (orange) indicate data collection steps; when reaching a red node, the cause is identified and the next step is always a green corrective action node. Never skip from cause to action without confirming the actual resource state.