Troubleshooting Lab: Secure an origin by using Azure Private Link in Azure Front Door
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team receives alerts that requests sent by Azure Front Door Premium to an origin protected via Private Link are intermittently returning 502 Bad Gateway. The environment has been in production for three weeks without any reported configuration changes.
The responsible engineer collects the following information during the investigation:
[Front Door Health Probe Log]
Timestamp : 2024-11-14T18:32:11Z
Origin FQDN : app-backend-prod.azurewebsites.net
Probe Status : Timeout
HTTP Status : N/A
Latency (ms) : N/A
Private Link : Enabled
Connection State: Approved
[App Service Access Log - last 10 min]
Requests received : 0
Errors logged : 0
CPU usage (avg) : 12%
Memory usage : 34%
Additional information collected:
- The Private Endpoint created by Front Door appears with Approved status in the portal.
- The App Service has public access enabled.
- The App Service plan is P2v3, with available capacity.
- The WAF on Front Door is in Detection mode, with no active blocks.
- The Front Door health probe is configured for the
/healthzroute via HTTPS on port 443. - The response file at
/healthzwas removed from the repository in the last deployment made four days ago.
What is the root cause of the observed behavior?
A. The WAF in Detection mode is interfering with health probe responses and generating false timeouts.
B. The App Service is not receiving requests because public access was automatically disabled after Private Link approval.
C. The /healthz endpoint no longer exists in the application, causing the health probe to fail and Front Door to mark the origin as degraded.
D. The Private Endpoint silently lost approval status after 72 hours without traffic, requiring reapproval.
Scenario 2 — Action Decision
The platform team identified that an origin configured in Azure Front Door Premium with Private Link is being accessed directly from the internet, without going through Front Door. After investigation, it was confirmed that:
- The origin is an Azure App Service with the public endpoint still enabled.
- Private Link is active and approved.
- Front Door is operating normally and delivering traffic via private channel.
- The allowed maintenance window is Saturday, from 02:00 to 04:00 (Brazil time).
- It's Thursday, 4 PM, and the security team demands immediate resolution due to an ongoing audit.
The team has permission to make changes to the App Service but cannot modify the Front Door profile settings at this time.
What is the correct action to take now?
A. Remove the private endpoint from the App Service to force all traffic to go through Front Door.
B. Configure access restrictions on the App Service to block all traffic that doesn't come from the service tag AzureFrontDoor.Backend, preserving the Private Link channel.
C. Wait for Saturday's maintenance window to disable the App Service public endpoint with lower operational risk.
D. Enable the WAF on Front Door in Prevention mode to block traffic arriving directly at the origin without going through Front Door.
Scenario 3 — Root Cause
A cloud architect configures Azure Front Door Premium to use Private Link Service over an Internal Load Balancer as the origin. After completing the configuration, the connection status in the Front Door portal shows:
Origin Name : ilb-origin-prod
Private Link : Enabled
Connection State : Pending
Last Updated : 2024-11-14T09:00:00Z
Two hours later, the state remains Pending. The architect checks the ILB and Private Link Service and collects:
[Private Link Service - ilb-pls-prod]
Region : brazilsouth
Alias : ilb-pls-prod.12345678.brazilsouth.azure.privatelinkservice
Visibility : Restricted (whitelist)
Auto-approval : Not configured
Pending Connections: 0
Active Connections: 0
Additional information:
- The ILB is in
brazilsouthand is healthy, with backends responding normally. - Front Door was configured with
privateLinkLocation: brazilsouth. - The Private Link Service DNS is resolving correctly in the test environment.
- No blocking policies are active in the subscription.
- The Private Link Service visibility is configured as restricted, with a list of authorized subscriptions.
What is the root cause of the persistent Pending state?
A. The Private Link Service DNS is resolving incorrectly, preventing Front Door from locating the service and registering the connection.
B. The Azure Front Door subscription is not included in the Private Link Service restricted visibility list, preventing the connection from being registered.
C. The auto-approval configuration was not enabled on the Private Link Service, and manual approval needs to be performed in the ILB pending connections tab.
D. The privateLinkLocation should be configured with the Front Door region, not the ILB region, reversing the provided value.
Scenario 4 — Diagnostic Sequence
An engineer receives a report that requests to Azure Front Door Premium are returning 421 Misdirected Request for a specific group of users. The environment uses Private Link to protect the origin, and no configuration changes have been reported in the last 48 hours.
The engineer has the following investigation steps available:
- Check if the TLS certificate configured on the origin has a CN or SAN compatible with the hostname used by Front Door in forwarding.
- Verify if the Private Link connection state shows as
Approvedin the portal. - Confirm if the
Hostheader is being preserved or correctly replaced in Front Door route configurations. - Check the health probe logs to identify if the origin is being marked as degraded.
- Validate if the WAF is in Prevention mode and blocking specific patterns from the affected group.
What is the correct investigation sequence for this symptom?
A. 5 -> 2 -> 4 -> 3 -> 1
B. 4 -> 2 -> 5 -> 1 -> 3
C. 2 -> 4 -> 5 -> 3 -> 1
D. 3 -> 1 -> 4 -> 2 -> 5
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
The determining clue is the combination of two facts: the App Service registers no requests in the last 10 minutes and the /healthz file was removed in the last deployment, made four days ago. Front Door's health probe is configured exactly for this path. When the probe doesn't receive a valid response (the endpoint no longer exists, returning 404 or timeout depending on configuration), Front Door begins marking the origin as degraded and stops or reduces traffic forwarding, generating the observed 502 errors.
The information about the Private Link Approved status is relevant to eliminate channel connectivity issues, but doesn't explain why the App Service receives no requests at all. The low CPU and memory eliminate overload as a cause. The WAF in Detection mode never blocks traffic, making alternative A incorrect by definition.
Alternative D describes behavior that doesn't exist: approved Private Link connections don't silently expire due to inactivity. Acting based on it would lead to unnecessary reapproval without solving the real problem, while the /healthz endpoint would continue to be nonexistent.
Answer Key — Scenario 2
Answer: B
The cause is already identified: the App Service public endpoint is enabled and directly accessible. The context imposes two critical restrictions: the team can modify the App Service but not the Front Door profile, and there's an ongoing audit requiring immediate resolution. Waiting until Saturday (alternative C) ignores the urgency restriction imposed by the audit context.
Alternative B is the correct action because App Service access restrictions allow blocking all external traffic that doesn't come from the AzureFrontDoor.Backend service tag, without removing the public endpoint (which could impact the established Private Link channel) and without modifying the Front Door profile. This action can be executed immediately and resolves the direct access vector.
Alternative A is technically dangerous: removing the Private Endpoint would bring down the private channel as well. Alternative D is incorrect for architectural reasons: the WAF operates at the Front Door perimeter and has no capability to block traffic that never passes through it.
Answer Key — Scenario 3
Answer: B
The decisive element is in the collected Private Link Service data: Visibility: Restricted (whitelist) and Pending Connections: 0. When visibility is restricted, only explicitly authorized subscriptions can register a connection request. Since the subscription used by Azure Front Door is not on the list, the service doesn't even receive the request, which is why the pending connections counter is zero and the Front Door state remains Pending indefinitely.
The information about DNS resolving correctly is intentionally irrelevant: DNS resolution occurs in the architect's test environment, not in the Front Door context. Alternative C confuses the mechanism: manual approval would only be necessary if the connection reached the Private Link Service as pending, which isn't happening. Alternative D describes incorrect behavior: the privateLinkLocation should point to the origin resource region, exactly as configured.
The most dangerous distractor is C, because it would lead the engineer to look for pending connections in a place where they simply don't exist, wasting time while the real cause remains in the visibility configuration.
Answer Key — Scenario 4
Answer: D
The 421 Misdirected Request error indicates that the origin is rejecting the request because the hostname in the Host header doesn't match the presented TLS certificate or isn't recognized by the server. The correct sequence starts from the most direct symptom to progressively deeper causes:
3 -> 1 -> 4 -> 2 -> 5
Step 3 is first because 421 is directly caused by hostname incompatibility in forwarding; Front Door may be replacing the Host header with the origin endpoint FQDN instead of preserving the original hostname. Step 1 validates if the certificate covers the hostname in use. Step 4 eliminates origin degradation as a contributing factor. Step 2 verifies Private Link channel integrity. Step 5 is last because WAF in Prevention mode would produce 403, not 421, making it unlikely as a primary cause but still relevant to close the diagnosis.
Starting with WAF (alternatives A and C) or health probe (alternative B) represents a triage error: the 421 error code is specific enough to direct diagnosis directly to TLS and hostname processing, not security blocks or origin availability.
Troubleshooting Tree: Secure an origin by using Azure Private Link in Azure Front Door
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| 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 at the root node and answer each question based on what you can directly observe in the portal, logs, or via CLI. Follow the path indicated by your answer without skipping steps. Questions about Private Link state should always be verified on the origin resource, not just on the Front Door profile. When you reach an identified cause node, apply the corresponding recommended action and validate the behavior before closing the diagnosis.