Troubleshooting Lab: Select an appropriate ExpressRoute SKU and tier
Diagnostic Scenarios
Scenario 1 — Root Cause
A network team from a Brazil-based company reports that the ExpressRoute circuit is operational and the provisioning status shows as Succeeded in the Azure portal. Private peering is configured and active. However, virtual machines in a VNet in the Australia East region cannot be reached from the on-premises environment connected by this circuit.
Information collected by the team:
ExpressRoute Circuit
Name: er-corp-brasil
Status: Enabled
Provider Status: Provisioned
SKU: Standard
Bandwidth: 1 Gbps
Peering Location: São Paulo
Private Peering: Configured and active
Virtual network gateway: Connected to circuit
Affected VNet region: Australia East
Regions with functional connectivity: Brazil South, East US
The team suspects a gateway or peering configuration problem, as the circuit appears healthy in the portal.
What is the root cause of the connectivity failure with the Australia East region?
A) The virtual network gateway in the Australia East region VNet is misconfigured and needs to be recreated
B) The Standard SKU restricts connectivity to the geopolitical context of the circuit region, excluding regions like Australia East
C) The 1 Gbps bandwidth is insufficient to support connections to geographically distant regions
D) Private peering does not propagate routes to VNets in regions different from the PoP region
Scenario 2 — Action Decision
The network team identified that an ExpressRoute circuit with Standard SKU needs to be upgraded to Premium to enable ExpressRoute Global Reach between two on-premises sites. The SKU change has been approved and is scheduled for a maintenance window next weekend.
However, the operations manager informs that one of the two circuits involved in Global Reach already has Premium SKU. The remaining circuit, still Standard, is the main connectivity circuit for the production datacenter, with active SLA and continuous traffic during business hours.
The maintenance window is 2 hours, starting at 11 PM Saturday. The team has network contributor permissions in the subscription.
What is the correct action to take during the maintenance window?
A) Recreate the Standard circuit as a new Premium circuit, as in-place upgrade is not supported by Azure
B) Perform the Standard to Premium SKU upgrade directly on the existing circuit, as this operation does not interrupt ongoing traffic
C) Wait until production traffic is zeroed before starting the upgrade, as SKU change temporarily brings down private peering
D) Request the connectivity provider to reconfigure the circuit before changing the SKU in the Azure portal
Scenario 3 — Root Cause
A network administrator is investigating why access to Microsoft 365 services is not working via ExpressRoute, even after configuring Microsoft peering. The circuit has Provisioned status and Microsoft peering appears as Enabled in the portal.
Logs collected during investigation:
Microsoft Peering: Enabled
Advertised prefixes: 40 prefixes received
Default route via ExpressRoute: Not configured
Circuit SKU: Premium
Contracted bandwidth: 500 Mbps
Current utilization: 120 Mbps
Microsoft 365 connectivity test:
outlook.office365.com -> Timeout
teams.microsoft.com -> Timeout
Azure PaaS connectivity test:
storage.azure.com -> OK
sql.azure.com -> OK
The administrator believes the problem is insufficient bandwidth, as utilization is at 120 Mbps of the contracted 500 Mbps.
What is the root cause of Microsoft 365 access failure?
A) The 500 Mbps bandwidth is being saturated by Azure PaaS traffic, leaving insufficient capacity for Microsoft 365
B) The Premium SKU does not support Microsoft peering for productivity services like Microsoft 365
C) Microsoft 365 access via ExpressRoute requires prior authorization from Microsoft and specific routing policies that were not applied
D) Microsoft peering is configured incorrectly, as the number of prefixes received is below the minimum required for Microsoft 365
Scenario 4 — Diagnostic Sequence
A network team receives the following report: "We configured ExpressRoute Global Reach between two circuits, but traffic between the two on-premises sites is not flowing. Both circuits appear healthy individually."
Available investigation steps are:
P Verify if both circuits have Premium SKU
Q Confirm if Global Reach is available in the geographic region of both circuits' PoPs
R Verify if Global Reach configuration was applied to both circuits, referencing the remote circuit ID
S Test end-to-end connectivity between the two on-premises sites using traceroute
T Confirm if on-premises network prefixes from both sides do not overlap
Which sequence represents the correct diagnostic investigation order?
A) S, P, Q, T, R
B) P, Q, R, T, S
C) R, P, Q, S, T
D) Q, P, T, R, S
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The Standard SKU restricts the ExpressRoute circuit reach to the geopolitical context of the region where the PoP is located. The PoP in São Paulo belongs to the South America and Brazil geopolitical region, which covers regions like Brazil South and East US (within the Americas geopolitics), but excludes regions like Australia East, which belongs to a different geopolitics. To reach regions outside the circuit's geopolitical context, the Premium SKU is required.
The decisive clue in the scenario is the explicit contrast: Brazil South and East US work, Australia East does not work. This selective failure pattern by region is the signature of the Standard SKU geopolitical limitation, not gateway or peering failure.
The information about 1 Gbps bandwidth is irrelevant for diagnosis: the limitation is geographic reach, not traffic capacity.
The most dangerous distractor is alternative A, which would lead the team to recreate a functional gateway without solving the real problem, generating unnecessary downtime during the intervention.
Answer Key — Scenario 2
Answer: B
The ExpressRoute SKU upgrade from Standard to Premium is an in-place operation supported by Azure that does not interrupt ongoing traffic and does not bring down configured peerings. This makes the operation safe to execute within the maintenance window, even with active traffic, as long as the necessary permissions are available, which was confirmed in the scenario.
Alternative A is factually incorrect: Azure supports in-place SKU upgrade without needing to recreate the circuit. Choosing this option would generate total unnecessary interruption and require complete reconfiguration of all peerings and gateway connections.
Alternative C represents a common misconception, where the administrator confuses the behavior of destructive operations (like recreating a circuit) with non-destructive upgrade operations. Alternative D confuses the provider's responsibility in the initial provisioning phase with an unnecessary step in a SKU upgrade.
Answer Key — Scenario 3
Answer: C
Access to Microsoft 365 via ExpressRoute is not automatically enabled by Microsoft peering configuration. It requires a formal authorization process with Microsoft and, after authorization, requires the application of specific routing policies for Microsoft 365 prefixes to be correctly advertised and used. The fact that Microsoft peering is enabled and Azure PaaS services are accessible confirms that peering itself is functional, but the absence of exclusive Microsoft 365 connectivity points to the lack of this authorization and complementary configuration.
The information about bandwidth utilization (120 Mbps of 500 Mbps) is deliberately irrelevant: there are 380 Mbps free, which completely rules out the saturation hypothesis.
The most dangerous distractor is alternative D, which would lead the team to investigate Microsoft peering prefix configuration, a path that would consume time without reaching the real cause. The number of 40 prefixes received is plausible information that indicates no problem by itself.
Answer Key — Scenario 4
Answer: B
The correct sequence is P, Q, R, T, S, which follows the logic of progressive diagnosis from most restrictive to most operational:
P verifies the SKU requirement, as without Premium on both circuits Global Reach is impossible to configure. Q verifies regional availability of the feature, as Global Reach is not available in all PoPs. R validates if the configuration was applied correctly on both sides, referencing the remote ID, as unilateral configuration does not establish the path. T verifies network prefix overlap, which prevents routing even with correct configuration. S performs the end-to-end test only at the end, when prerequisite and configuration layers have already been validated.
Alternative A starts with the connectivity test (S), which is inefficient: a negative test without having validated prerequisites does not provide useful diagnostic information. Alternative C starts with configuration verification (R) before confirming if SKU and regional availability allow the feature, inverting the logic of progressive elimination. Alternative D starts with regional availability before SKU, which is acceptable but loses logical priority: without Premium SKU, regional availability is irrelevant.
Troubleshooting Tree: Select an appropriate ExpressRoute SKU and tier
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue (navy) | Initial symptom, investigation entry point |
| Medium blue | Diagnostic question, decision point |
| Red | Identified cause |
| Green | Recommended action or connectivity restored |
To use this tree when facing a real problem, always start from the root node (connectivity failure) and answer each question based on what is directly observable in the Azure portal or connectivity tests. At each bifurcation, choose the path corresponding to the verified state, without skipping steps. The causes in red indicate where the investigation ends and corrective action begins. Green nodes indicate that the diagnostic path has reached resolution or confirmation that the configuration is correct.