Troubleshooting Lab: Create a public IP address
Diagnostic Scenarios
Scenario 1 — Root Cause
An engineer attempts to associate an existing public IP address with a new Azure Load Balancer being created through the Azure portal. The Load Balancer is configured as Standard and the chosen region is East US. The resource group already contains other resources working normally, including two VMs and a Virtual Network.
During association, the portal displays the following error message:
Cannot associate public IP address 'pip-lb-frontend' with this load balancer.
The resource is not compatible with the selected configuration.
The engineer verifies that the public IP exists, is in the same region, and is not currently associated with any other resource. They also confirm that the resource group has adequate permissions and there are no active blocking policies.
What is the root cause of the observed error?
A) The public IP is in a different resource group from the Load Balancer, preventing direct association
B) The public IP was created with Basic SKU, making it incompatible with a Standard SKU Load Balancer
C) The public IP does not have a configured availability zone, which is mandatory for Standard Load Balancers
D) The Standard Load Balancer requires the public IP to be pre-associated with a network interface before being linked to the frontend
Scenario 2 — Diagnostic Sequence
A team receives a ticket reporting that a web application hosted on an Azure VM has stopped responding to external requests. The VM is operational, the service is active, and the application logs show no internal errors. The VM has a public IP associated directly with its network interface.
The responsible engineer needs to investigate if the problem is related to the public IP address. The following investigation steps are available:
- Verify if the public IP is associated with the correct VM NIC
- Try accessing the application via private IP from another VM in the same VNet
- Confirm if the public IP has Dynamic allocation and if the address changed after a recent restart
- Check if the NSG associated with the NIC or subnet blocks the application port
- Query the current public IP address assigned to the resource in the portal
Which sequence represents the correct order of investigation to progressively diagnose the problem, from most external to most specific?
A) 1, 5, 3, 2, 4
B) 2, 4, 5, 3, 1
C) 5, 3, 1, 4, 2
D) 3, 1, 5, 4, 2
Scenario 3 — Root Cause
During the creation of a public IP address via CLI, an engineer executes the following command:
az network public-ip create \
--resource-group rg-networking \
--name pip-appgw-prod \
--sku Standard \
--allocation-method Dynamic \
--location brazilsouth
The command returns the following error:
(InvalidPublicIpAllocationMethod) Dynamic allocation method is not supported
for Standard SKU public IP.
Error Code: InvalidPublicIpAllocationMethod
The engineer notes that the same command worked without errors six months ago in another environment. They verify that the resource group exists, the Brazil South region is available for the subscription, and the resource name follows Azure accepted conventions.
What is the root cause of the error?
A) The Brazil South region does not support Standard SKU public IP addresses with any allocation method
B) The Standard SKU requires Static allocation, and the command specified Dynamic allocation, which is incompatible with this SKU
C) The --allocation-method Dynamic parameter has been deprecated in the CLI and needs to be replaced with --allocation-method Automatic
D) The command worked six months ago because the subscription had a different policy configuration that allowed Dynamic allocation for Standard SKU
Scenario 4 — Action Decision
The cause has been identified: a Basic SKU public IP address is associated with a Standard_v2 Application Gateway in production. The Standard_v2 Application Gateway requires Standard SKU for the public IP, and the incompatibility is causing intermittent failures in provisioning new routing rules. The environment serves external users with an active SLA and any interruption must be communicated with 30 minutes advance notice.
The operations team confirms that no other maintenance window is available in the next 4 hours and that the Application Gateway is responding normally at the moment, but new rules cannot be added. The current public IP is registered in the company's external DNS with a TTL of 3600 seconds.
What is the correct action to take at this time?
A) Immediately delete the Basic public IP and create a new Standard IP, as the Application Gateway will continue responding during the swap
B) Upgrade the public IP SKU directly in the portal from Basic to Standard, preserving the IP address and avoiding DNS impact
C) Create a new Standard public IP, update the DNS record pointing to the new address, and plan the disassociation of the Basic IP for the next maintenance window, communicating the impact according to the SLA
D) Add the new Standard public IP as a secondary address on the Application Gateway while the Basic remains active, performing the migration without downtime
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
Explanation:
- The incompatibility error occurs because Azure enforces that Standard Load Balancers be associated exclusively with Standard SKU public IP addresses. A Basic SKU public IP cannot be linked to a resource that requires the Standard tier.
- The decisive clue in the scenario is the confirmation that the Load Balancer is Standard and that the IP exists and is disassociated. The absence of a configured zone is not the problem: a Standard IP without a zone (non-zonal) is perfectly compatible with a Standard Load Balancer.
- The information about VMs and the Virtual Network in the resource group is intentionally irrelevant and does not influence SKU compatibility between public IP and Load Balancer.
- Alternative C represents the most dangerous diagnostic error: availability zones are optional for Standard IPs, and confusing "non-zonal" with "incompatible" would lead the engineer to unnecessarily create a Standard IP with a zone, without solving the problem if the original IP remained Basic.
- Acting based on distractor A (different resource group) would make the engineer move resources unnecessarily, wasting time without reaching the real cause.
Answer Key — Scenario 2
Answer: C
Explanation:
- The correct sequence starts from the current state of the public IP (step 5), checks if there was an address change due to Dynamic allocation after restart (step 3), confirms if the IP is associated with the correct NIC (step 1), checks for NSG blocks at the network layer (step 4), and only then tests internal connectivity to isolate if the problem is external or in the application (step 2).
- The correct diagnostic logic starts from the most external component and most likely to have changed (the public IP address with Dynamic allocation) before advancing to internal layers like NSG and private connectivity.
- Alternative B completely reverses the order by starting with the internal test, which may confirm that the application works internally, but doesn't identify the external problem without first checking the IP.
- Alternative D starts with the most specific step (IP change) without first confirming what the current assigned IP is, making comparison difficult.
- Starting with step 2 (internal test) before checking the public IP would be a classic inside-out diagnostic error, which can generate false conclusions about application health when the real problem is in the external addressing layer.
Answer Key — Scenario 3
Answer: B
Explanation:
- The Standard SKU of public IP addresses in Azure supports exclusively Static allocation. There is no valid combination of Standard SKU with Dynamic allocation. This is a platform restriction, not a subscription policy.
- The most important clue is the explicit error message:
Dynamic allocation method is not supported for Standard SKU public IP. The scenario describes the symptom with sufficient technical precision to identify the cause without ambiguity. - The information that the same command worked six months before is intentionally irrelevant and aims to induce the reader to look for an external cause like subscription policy (alternative D). In practice, if the command worked previously with this combination, the created resource was Basic SKU, not Standard, or the SKU parameter was different.
- Alternative C is a plausible distractor because it describes real CLI deprecation behavior, but doesn't correspond to any real change in the Azure CLI interface for this parameter.
- Acting based on alternative D would lead the engineer to open tickets with Microsoft or investigate non-existent policies, wasting time while the real fix is simply replacing
DynamicwithStaticin the command.
Answer Key — Scenario 4
Answer: C
Explanation:
- The critical restriction is the 3600-second TTL on external DNS. Any IP address change requires the new DNS record to be propagated before the old address is removed. Deleting the current IP without respecting the TTL would cause real unavailability for external users while DNS still points to the old address.
- The correct action is to create the new Standard IP, update DNS with sufficient advance time to cover the TTL, and only then disassociate the Basic IP in a planned window, with communication according to the SLA.
- Alternative B is the most dangerous distractor because it describes something technically impossible: the SKU of a public IP cannot be changed after creation. An engineer who believes this will go to the portal, not find the option, and waste time trying a non-existent action.
- Alternative A ignores the DNS TTL and would cause immediate downtime, violating the active SLA.
- Alternative D is technically invalid: an Application Gateway does not accept two simultaneous frontend public IP addresses of different SKUs as a transparent migration strategy.
- The central point of this decision is recognizing that the DNS restriction is the limiting factor, not the technical compatibility of the new IP.
Troubleshooting Tree: Create a public IP address
Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start with the root node describing the observed symptom and follow the diagnostic questions answering yes or no based on what you can verify directly in the portal or via CLI. Orange nodes indicate information gathering steps before advancing to the next question. Each path ends with an identified cause (red) followed by a specific action (green). Never jump directly to an action without going through the question path, as identical symptoms can have different causes depending on the environment configuration.