Technical Lab: Configure an Azure Front Door, including routing, origins, and endpoints
Questions
Question 1 — Multiple Choice
A platform team needs to configure Azure Front Door to distribute traffic between two origin groups: one hosted in Brazil and another in the United States. The requirement is that, under normal conditions, 80% of traffic should be directed to the American group and 20% to the Brazilian group, regardless of the user's geographic location.
Which routing mechanism should be configured to meet this requirement?
A) Latency-based routing, adjusting the priority weights of each origin individually.
B) Weighted routing, defining proportional weights on the origin groups within a single route.
C) Session-based routing (session affinity), with weights assigned per endpoint.
D) Two separate routes with matching conditions based on client geographic location.
Question 2 — Technical Scenario
An engineer configured Azure Front Door with the following structure:
Endpoint: contoso.azurefd.net
Route: /* → Origin Group: BackendProd
Origin: app-prod.azurewebsites.net (HTTPS, port 443)
After deployment, requests to https://contoso.azurefd.net/api/data consistently return HTTP 502. The backend responds correctly when accessed directly via URL. Front Door health probes mark the origin as degraded.
What is the most likely cause of the error?
A) The custom domain has not been validated on the endpoint, preventing root route routing.
B) The origin is not configured to accept the X-Forwarded-Host header sent by Front Door.
C) The origin's TLS certificate is not trusted by Front Door or the probe hostname doesn't match the certificate.
D) The /* route takes precedence over more specific routes, causing internal redirect loops.
Question 3 — True or False
In Azure Front Door (Standard or Premium SKU), it's possible to associate more than one custom domain with a single endpoint, and each domain can be routed to a different origin group through distinct routes configured on the same endpoint.
True or False?
Question 4 — Technical Scenario
A company uses Azure Front Door Premium to expose a global API. The security team requires that traffic between Front Door and origins (Azure App Services) not traverse the public internet. Direct access to origins via external IP addresses must also be blocked.
The responsible engineer proposes the following approach:
1. Enable Private Link on the origin within the origin group
2. Approve the Private Endpoint connection on the target resource
3. Restrict access to the origin only to the Front Door service via
Access Restriction configuration on the App Service
What is the problem with this approach?
A) Private Link in Azure Front Door is not compatible with Azure App Services; it only works with Azure Storage and Azure SQL.
B) Step 3 is unnecessary because, with Private Link active, App Service automatically rejects connections from public IP addresses.
C) Step 2 is mandatory and correct, but step 3 introduces redundancy without functional issues; the approach is technically valid.
D) Private Link in Azure Front Door is only available in the Standard SKU, not Premium.
Question 5 — Multiple Choice
When configuring routing rules in Azure Front Door, an engineer needs to ensure that all HTTP requests are automatically redirected to HTTPS before reaching the origin.
What is the correct way to implement this behavior?
A) Configure a rule in the Rule Set with condition RequestScheme == HTTP and redirect action to HTTPS with code 301.
B) Enable HTTPS redirect option directly in the origin configuration, within the origin group.
C) Create two separate routes: one accepting HTTP and another HTTPS, and set higher priority for the HTTPS route.
D) Enable mutual TLS (mTLS) on the endpoint, which automatically forces upgrade of all HTTP connections.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure Front Door supports the weighted routing method, in which each origin within an origin group receives a relative numeric weight. Traffic distribution follows these weights proportionally, without considering user location. For 80/20, simply assign weights like 80 and 20 (or equivalents like 4 and 1) to each origin in the group.
Distractor A confuses "weight" with "priority": priority defines failover order, not percentage distribution. Distractor C applies session affinity, which binds a user to a specific origin after first access and doesn't distribute load proportionally. Distractor D would solve a different problem (geo-targeting), not global weighted distribution.
Answer Key — Question 2
Answer: C
When Azure Front Door performs health probes via HTTPS, it validates the origin's TLS certificate. If the certificate is self-signed, issued by an untrusted CA, or if the Subject Name doesn't match the hostname configured in the origin, the probe fails and the origin is marked as degraded. The result for the client is HTTP 502, as Front Door cannot establish a trusted connection with the backend.
Distractor A is irrelevant to the described symptom: custom domain validation affects the client side, not the backend. Distractor B is plausible, but the X-Forwarded-Host header doesn't prevent TLS connection and rarely causes 502 with probe degradation. Distractor D describes behavior that doesn't occur in this simple configuration scenario.
Answer Key — Question 3
Answer: True
In Azure Front Door Standard and Premium, a single endpoint can have multiple custom domains associated. Routes are configured by combination of domain and path pattern, allowing api.contoso.com/* to point to one origin group and www.contoso.com/* to point to another, all within the same endpoint. This flexibility is a relevant advantage of the current configuration model (unified profile) over the classic model.
The non-obvious point here is that the endpoint scope doesn't limit the number of domains nor impose a 1:1 mapping between domain and origin group.
Answer Key — Question 4
Answer: C
The described approach is technically correct. Private Link in Azure Front Door Premium allows traffic between Front Door and compatible origins (including Azure App Services) to traverse Microsoft's private network, without exposure to the public internet. Manual approval of the Private Endpoint connection (step 2) is mandatory. Step 3 (Access Restriction) is redundant from a network security perspective, but doesn't introduce functional errors.
Distractor A is wrong: Azure App Service is one of the origins that supports Private Link in Front Door Premium. Distractor B is wrong: activating Private Link in Front Door doesn't automatically block public access to App Service; this requires explicit configuration on the resource itself. Distractor D reverses reality: Private Link is available only in the Premium SKU, not Standard.
Answer Key — Question 5
Answer: A
The correct way to redirect HTTP to HTTPS in Azure Front Door is through a Rule Set, using the RequestScheme condition with value HTTP and the UrlRedirect action with HTTPS destination protocol and status code 301 or 302. This approach is explicit, controlled, and decoupled from origin configuration.
Distractor B is incorrect because protocol configuration on the origin defines how Front Door connects to the backend, not how it handles client requests. Distractor C would create routing ambiguity and doesn't guarantee redirection; routes in Front Door don't work as protocol priority rules. Distractor D confuses mTLS (client authentication via certificate) with protocol redirection: they are completely distinct mechanisms.