Technical Lab: Configure traffic acceleration
Questions
Question 1 — Multiple Choice
A global company has users distributed across Europe, Asia, and North America accessing an application hosted in a single Azure region. The network team needs to reduce latency for all users without migrating the application to multiple regions.
Which Azure service directly meets this requirement by routing traffic through Microsoft's backbone to the point of presence closest to the user?
A) Azure Load Balancer Standard with global balancing rules
B) Azure Front Door
C) Azure Traffic Manager with performance routing method
D) Azure Application Gateway with WAF enabled
Question 2 — Technical Scenario
An architect configured Azure Front Door to accelerate access to an API hosted on Azure App Service. After deployment, users report that API responses that rarely change are being delivered with high latency, without cache utilization.
The origin configuration is correct and the route is active. The observed behavior is:
Cache-Control: no-store
The header above is present in the origin responses.
What is the root cause of the problem?
A) Front Door requires cache to be manually enabled in the profile through an explicit cache policy
B) The no-store directive instructs Front Door not to store or reuse the response in cache, respecting HTTP semantics
C) The Front Door Standard SKU doesn't support API response caching; Premium SKU is required
D) Front Door cache only works for static content served by Storage Account, not by App Service
Question 3 — True or False
Azure Traffic Manager operates at the DNS layer and, therefore, does not inspect or manipulate HTTP/HTTPS traffic from end users. As a consequence, it cannot be used as a traffic acceleration mechanism in the sense of reducing data transfer latency, but only to direct users to the most appropriate endpoint before connection establishment.
Is the statement above true or false?
Question 4 — Technical Scenario
An engineer needs to configure traffic acceleration for a web application with the following requirements:
- Protection against DDoS attacks and SQL injection at the edge
- Static content caching at global points of presence
- URL-based routing (path-based routing)
- Multiple origin support with automatic failover
The engineer is evaluating between Azure Front Door and Azure Application Gateway. He decides to use Application Gateway to meet all these requirements globally.
What is the fundamental error in this decision?
A) Application Gateway doesn't support WAF; this functionality is only available in Front Door
B) Application Gateway is a regional service and doesn't offer global points of presence or distributed edge caching
C) Application Gateway doesn't support URL-based routing, requiring Traffic Manager for this
D) Application Gateway requires all origins to be in the same virtual network, preventing cross-region failover
Question 5 — Multiple Choice
When configuring Azure Front Door with multiple origins in an origin group, the administrator defines the following weights:
| Origin | Weight |
|---|---|
| Origin A | 50 |
| Origin B | 25 |
| Origin C | 25 |
What is the expected Front Door behavior with this configuration, assuming all origins are healthy?
A) Front Door routes 100% of traffic to Origin A until it fails, using B and C as failover
B) Front Door distributes traffic proportionally to weights, sending approximately 50% to A, 25% to B and 25% to C
C) Front Door ignores weights when there are more than two origins and distributes traffic equally
D) Weight determines failover priority, not traffic distribution under normal conditions
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure Front Door routes incoming traffic through Microsoft's global private backbone to the point of presence (PoP) closest to the user, reducing the number of hops over the public internet. This constitutes real traffic acceleration, regardless of the origin being in a single region.
Traffic Manager (option C) also uses the performance routing method to direct users to the fastest endpoint, but operates only at the DNS layer: it doesn't maintain the connection on Microsoft's backbone after resolution. The user establishes the connection directly with the origin via public internet, without transport acceleration.
Load Balancer Standard operates at layer 4 and is strictly regional. Application Gateway is also regional and doesn't have global PoPs.
Answer Key — Question 2
Answer: B
Azure Front Door respects HTTP cache control directives from the origin. The no-store directive instructs any intermediary, including Front Door, not to store the response in any persistent or temporary storage. Therefore, the observed behavior is correct and expected: Front Door is working according to HTTP specification.
The correction should be made at the origin, changing the header to Cache-Control: max-age=N or public, according to the desired cache policy.
Option A is incorrect because caching in Front Door can be enabled by route rule, but this configuration doesn't override a no-store directive from the origin. Option C is false: both SKUs support caching. Option D is false: Front Door caches responses from any valid HTTP origin, not just Storage Account.
Answer Key — Question 3
True
Traffic Manager operates exclusively at the DNS layer. When a client resolves the application's DNS name, Traffic Manager returns the IP address of the most appropriate endpoint according to the configured routing method (performance, geographic, weighted, etc.). From that moment, data traffic flows directly between the client and endpoint, without passing through Traffic Manager and without any private backbone or intermediary PoP benefit.
This point is fundamental to distinguish Traffic Manager from Front Door: Traffic Manager optimizes endpoint selection before connection, while Front Door optimizes connection transport after initiated, keeping it on Microsoft's backbone to the origin.
Answer Key — Question 4
Answer: B
The fundamental error is treating Application Gateway as a global solution. It is a regional service: deployed in a single Azure region and serves users through public internet without distributed PoPs. Therefore, it doesn't offer global traffic acceleration or edge caching near the user.
The other requirements (WAF, URL routing, multiple origins with failover) are supported by Application Gateway, but only within regional scope. For the requirements described at global scale, Azure Front Door is the correct service, as it combines edge WAF, global caching, URL routing, and origin failover in a single distributed service.
Options A and C describe limitations that don't exist. Option D describes a non-existent restriction about virtual networks.
Answer Key — Question 5
Answer: B
In Azure Front Door's origin group, weight controls proportional traffic distribution among healthy origins, not failover priority. With weights 50, 25, and 25, Front Door will distribute approximately half of the requests to Origin A and a quarter to each of the others.
Failover is controlled by the priority field, not weight. Origins with higher priority receive traffic while healthy; lower priority origins function as fallback. Confusing weight with priority is a common mistake that leads to incorrect high availability configurations, where the administrator believes they have failover configured, but in practice are just distributing load.