Troubleshooting Lab: Choose when to use a public IP address prefix
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team receives a complaint from a partner client: after Azure provisioned new resources in the company's subscription, traffic from these resources is being blocked by the client's on-premises firewall. Older resources continue to work normally.
The environment is described as follows:
- The subscription uses individual public IPs with Standard SKU, allocated on demand
- The partner client maintains an allow list with 14 CIDR entries in the firewall
- The Azure network team confirmed that all IPs are in the East US region
- The team verified that NSGs on new VMs are configured correctly
- The security team confirmed no firewall policy changes in the last 30 days
The client reports:
Firewall log - deny outbound:
src: 20.85.112.47 dst: 10.10.5.20 port: 443 action: DENY
src: 20.85.114.12 dst: 10.10.5.20 port: 443 action: DENY
src: 20.85.99.200 dst: 10.10.5.20 port: 443 action: DENY
What is the root cause of the observed blocking?
A) NSGs on the new VMs are blocking return traffic, preventing TLS session establishment
B) New public IPs were allocated outside the range already registered in the client's allow list, as there's no guarantee of contiguity in individual allocations
C) The Standard SKU of public IPs is incompatible with routing to on-premises networks via third-party firewalls
D) The East US region underwent IP block reallocation and old addresses were invalidated
Scenario 2 — Action Decision
The platform team identified that the problem from Scenario 1 would repeat indefinitely as new resources were provisioned. Leadership approved migration to a model based on public IP prefix.
The constraint context is:
- The 14 existing public IPs are associated with production VMs with active traffic
- The partner client requires 72-hour advance notice before any IP changes
- The team has a maintenance window available in 5 days
- An engineer already provisioned a /28 prefix in East US region and confirmed that the 16 new IPs are available
What is the correct action to take at this time?
A) Immediately disassociate old IPs from VMs and associate new IPs from the prefix to end the risk as quickly as possible
B) Communicate the new CIDR ranges to the client now and schedule the IP swap for the maintenance window in 5 days
C) Provision new IPs from the prefix and associate them in parallel to VMs, keeping old IPs active during the transition period
D) Request the client to temporarily expand the allow list to accept any IP from the 20.0.0.0/8 range while migration is planned
Scenario 3 — Root Cause
An administrator tries to create a public IP from an existing prefix using the following command:
az network public-ip create \
--resource-group rg-prod \
--name pip-vm-new \
--sku Basic \
--prefix "/subscriptions/.../publicIPPrefixes/prefix-prod-eastus" \
--allocation-method Static \
--location eastus
The returned output is:
(InvalidPublicIpSkuMismatch) The public IP address SKU 'Basic' is not
supported for public IP prefix. Only 'Standard' SKU is supported.
Code: InvalidPublicIpSkuMismatch
Message: The public IP address SKU 'Basic' is not supported for public
IP prefix. Only 'Standard' SKU is supported.
The administrator reports that the prefix was created three weeks ago without problems, that allocation of other IPs from the same prefix worked previously, and that the subscription still has available quota for public IPs in the region.
What is the root cause of the error?
A) The prefix reached the limit of allocated IPs and no longer accepts new creations until an IP is released
B) The --allocation-method Static parameter is incompatible with IPs derived from prefixes and caused operation rejection
C) The SKU specified in the command is incompatible with the prefix SKU, as public IP prefixes require derived IPs to be Standard SKU
D) The Basic public IP quota in East US region was exhausted, causing Azure to reject creation with a generic error message
Scenario 4 — Diagnostic Sequence
A company provisioned a public IP prefix /29 and started creating IPs from it. After some time, a new engineer tries to provision one more public IP from the same prefix and receives a failure. The engineer needs to diagnose the problem.
The following investigation steps are available, out of order:
- P1: Verify how many public IPs have already been created from the prefix
- P2: Confirm the prefix size (/29 provides a maximum of 8 addresses)
- P3: Try creating the public IP with a different name to rule out naming conflict
- P4: Verify if the prefix exists in the same region and expected resource group
- P5: Verify if all 8 addresses in the prefix are already associated with provisioned public IPs
What is the correct diagnostic sequence?
A) P3 > P1 > P5 > P2 > P4
B) P4 > P2 > P1 > P5 > P3
C) P1 > P3 > P4 > P2 > P5
D) P2 > P4 > P5 > P1 > P3
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the firewall logs: the three blocked IPs (20.85.112.47, 20.85.114.12, 20.85.99.200) don't belong to the same CIDR block and don't form a contiguous range. This is the expected behavior when public IPs are allocated individually in Azure: the platform doesn't guarantee that separate allocations result in adjacent addresses or addresses belonging to the same prefix.
The information about correctly configured NSGs is irrelevant to the diagnosis and was intentionally included. The blocking occurs at the client's firewall, before traffic even reaches the VM NSG rules. Alternative C is a plausible distractor, but Standard SKU is fully compatible with on-premises traffic. Alternative D describes a hypothetical event with no evidence in the statement.
The most dangerous distractor is A: a diagnosis focused on NSGs would lead to hours of investigation in the wrong place, while new resources would continue being blocked.
Answer Key — Scenario 2
Answer: B
The critical constraint in the scenario is the 72-hour advance notice required by the client. Any action that results in IP changes without this notification violates an operational commitment to the partner, regardless of the technical correctness of the action.
Alternative A directly ignores this constraint and would cause service interruption for the client without warning. Alternative C is technically appealing, but public IPs in Azure cannot be associated in parallel to the same resource in a way that inbound traffic works through both simultaneously without an additional layer. Alternative D is inadequate because it unnecessarily expands the client firewall's attack surface without a defined timeline.
The correct action is to communicate the new prefix CIDR blocks to the client now and execute the migration within the maintenance window, respecting the contractual deadline.
Answer Key — Scenario 3
Answer: C
The error message is explicit: Only 'Standard' SKU is supported. Public IP prefixes in Azure are created with Standard SKU and all IPs provisioned from them must equally be Standard SKU. This restriction is absolute and doesn't depend on quota, naming, or allocation method.
The information about the prefix being created three weeks ago and previous allocations working is irrelevant: it only confirms that the prefix and subscription are healthy, which redirects the correct diagnosis to the submitted command itself.
Alternative D is the most dangerous distractor: the error message could be interpreted as generic by less experienced engineers, leading to a quota investigation that wouldn't find any real problem.
Answer Key — Scenario 4
Answer: B
The correct sequence follows the logic of eliminating structural causes before operational causes:
P4 confirms the prefix exists in the expected location, as without this the other steps have no foundation. P2 establishes the theoretical maximum limit of addresses available in the prefix (/29 = 8 addresses). P1 verifies how many IPs were created, providing the current number of allocations. P5 compares this number with the limit and confirms if exhaustion occurred. P3 only makes sense as a final verification, as naming conflict would only be relevant if there was still available capacity in the prefix.
Sequence A makes the classic mistake of testing solutions (P3) before understanding the structural problem. Sequence C jumps to operational verifications without first confirming resource existence. Sequence D reverses P1 and P5, checking exhaustion before knowing how many IPs exist, which lacks progressive logic.
Troubleshooting Tree: Choose when to use a public IP address prefix
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (root) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate verification or validation |
To use this tree when facing a real problem, start from the root node and answer each question based on what you observe in the environment, not what you assume. Follow the path that corresponds to the observed behavior until reaching a red cause node or a green action node. Never skip levels: each question filters a class of causes and ensures diagnosis is progressive, not speculative.