Technical Lab: Map requirements to features and capabilities of Azure Front Door
Questions
Question 1 — Multiple Choice
An architecture team needs to deliver a global web application with the following requirements: URL-based routing, TLS termination at the edge, dynamic content acceleration, and application-layer threat protection. The client requires a single managed service that meets all these requirements simultaneously.
Which combination of Azure Front Door capabilities fully addresses this scenario?
A) CDN for static content + Application Gateway for URL routing + Azure Firewall for layer 7 protection
B) Global load balancing with URL-based routing, TLS termination at the edge, integrated caching, and native WAF
C) Traffic Manager for DNS routing + Azure CDN for acceleration + Application Gateway with WAF
D) Front Door only for TLS termination and CDN for other requirements, since Front Door doesn't support native WAF
Question 2 — Technical Scenario
An engineer configured Azure Front Door for an application with two backends: one in East US region and another in West Europe. The routing is configured as Priority. After testing, they observed that 100% of traffic is going to East US, even with the West Europe origin showing lower latency for European users.
Backend Pool:
- eastus-app | Priority: 1 | Weight: 50
- westeurope-app | Priority: 2 | Weight: 50
Why is the observed behavior occurring and what should the engineer change to route European users preferentially to West Europe?
A) Front Door has caching enabled, causing all requests to be served by the origin closest to the entry PoP. Disabling cache solves the problem.
B) Priority routing always sends traffic to the highest priority backend while it's healthy, regardless of latency. To route by geographical proximity, the correct method is Latency.
C) The weight is equal for both backends. Increasing the weight of westeurope-app to 100 will make European traffic route correctly.
D) The problem is that Front Door doesn't support multiple regions in the same pool. Backends must be separated into distinct pools with geolocation routing rules.
Question 3 — True or False
Azure Front Door (Standard and Premium SKUs) allows associating a single WAF policy to multiple Front Door profiles simultaneously, as long as the profiles are in the same Azure subscription.
Question 4 — Technical Scenario
A company is migrating a legacy application that exposes three distinct paths: /api/, /auth/, and /static/. The requirement is that each path be routed to a different backend, with /static/ being served directly from cache whenever possible, and /auth/ never cached. The team decided to use Azure Front Door Standard.
Which configuration approach correctly addresses these three requirements?
A) Create three distinct Front Door profiles, one for each path, since Front Door doesn't support multiple routing rules in a single profile.
B) Use a single profile with three route rules based on path patterns, associating each route to its respective origin group, and configure caching as enabled on the /static/ route and disabled on the /auth/ route.
C) Use a single profile with a generic routing rule and redirect cache control to the backends themselves via Cache-Control headers, since Front Door doesn't allow cache configuration per route.
D) Create a single origin group with the three backends and use weighted routing to distribute traffic, adding global cache rules to the profile.
Question 5 — Multiple Choice
When comparing the Standard and Premium SKUs of Azure Front Door, what is the most relevant functional difference for an organization that needs Microsoft-managed threat protection and private traffic inspection via Private Link to origins?
A) Both SKUs offer managed WAF with Microsoft rules and Private Link support. The difference is only in the maximum number of custom domains allowed.
B) The Standard SKU offers WAF with Microsoft-managed rules and Private Link. The Premium SKU is only necessary for environments with more than 25 origins.
C) Only the Premium SKU offers the Microsoft-managed ruleset in WAF and Private Link support for secure connection to origins. The Standard SKU offers WAF only with custom rules.
D) The Standard SKU doesn't include WAF in any form. WAF is exclusive to the Premium SKU and requires a separate policy created in Azure Firewall Manager.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure Front Door is a unified service that combines global layer 7 load balancing, URL-based routing, TLS termination at the Microsoft network edge, integrated caching for dynamic and static content acceleration, and native WAF available in Standard and Premium SKUs. Alternative B describes exactly this set of capabilities in a single managed service.
Alternatives A and C represent architectures composed of multiple independent services, which increases operational complexity and doesn't meet the "single managed service" requirement. Alternative D is technically incorrect: WAF is a native Front Door functionality, not an external component.
Answer Key — Question 2
Answer: B
Azure Front Door's Priority routing method is designed for failover scenarios, not for geographical distribution by latency. While the highest priority backend (lowest numerical value) is healthy, all traffic is directed to it, regardless of user location or measured latency.
To route users to the backend with lowest network latency, the correct method is Latency, which uses Front Door's latency measurements between its PoPs and backends to make routing decisions.
Alternative A confuses cache behavior with origin routing. Alternative C is incorrect because weight is only relevant in the Weighted method, not in Priority. Alternative D is false: Front Door supports multiple backends in the same origin group.
Answer Key — Question 3
Answer: False
A WAF policy in Azure Front Door is associated with a specific profile and cannot be shared between multiple profiles simultaneously. Each Front Door profile requires its own WAF policy association. This is different from Azure Application Gateway behavior, where the policy can be associated at different scopes within the same resource.
This point is relevant in governance scenarios: organizations managing multiple Front Door profiles need to replicate or reference WAF policies separately for each profile, which impacts automation and compliance planning.
Answer Key — Question 4
Answer: B
Azure Front Door Standard supports multiple route rules within a single profile, each associated with a path pattern and a distinct origin group. Cache behavior is configurable per route: it's possible to enable caching with defined TTL for /static/ and explicitly disable it for /auth/, ensuring credentials and tokens are never stored at the edge.
Alternative A is incorrect because multiple routes in a single profile are a core Front Door feature. Alternative C is incorrect: Front Door allows native cache control per route, without depending exclusively on backend headers. Alternative D describes incorrect use of weighted routing, which serves for load distribution, not path segmentation.
Answer Key — Question 5
Answer: C
The distinction between Azure Front Door's Standard and Premium SKUs is direct for this scenario. The Premium SKU is the only one that includes the Microsoft-managed ruleset in WAF, which offers updated and managed protection against the most common threats (equivalent to Microsoft-managed CRS). Additionally, Private Link support to connect Front Door to private origins (like App Service, Storage, or internal endpoints) is exclusive to the Premium SKU.
The Standard SKU supports WAF, but only with custom rules defined by the customer themselves. This means the organization would be responsible for creating and maintaining all protection rules, without the managed ruleset.
Alternative A is incorrect because Private Link isn't available in Standard. Alternative B partially reverses the capabilities and uses a false criterion (number of origins) as a differentiator. Alternative D is completely incorrect: WAF is available in both SKUs, with differences in the type of rules supported.