Skip to main content

Technical Lab: Identify appropriate use cases for Azure Front Door

Questions​

Question 1 — Multiple Choice​

A global e-commerce company hosts its web application in three Azure regions: East US, West Europe, and Southeast Asia. The infrastructure team needs to ensure that users are automatically routed to the region with lowest latency, and that in case of a region failure, traffic is redirected without manual intervention.

Which Azure Front Door feature directly meets this requirement?

A) Priority routing with health probes configured per region
B) Latency-based routing combined with automatic failover via health probes
C) Traffic Manager with performance profile and endpoint monitoring
D) Application Gateway with multiple backends in different availability zones

Question 2 — Technical Scenario​

An architect is evaluating where to apply protection against SQL injection and XSS attacks for a publicly exposed web application. The application has backends in two different regions and receives traffic from global users.

Consider the configuration below:

{
  "frontDoorProfile": {
    "sku": "Premium_AzureFrontDoor",
    "securityPolicy": {
      "wafPolicy": {
        "mode": "Prevention",
        "managedRuleSets": ["Microsoft_DefaultRuleSet_2.1"]
      }
    }
  }
}

Which statement correctly describes the behavior of this configuration?

A) WAF inspects and blocks malicious requests before they reach any backend, acting at the edge of the global network
B) WAF is applied only to the primary backend; the secondary backend requires a separate WAF policy
C) Protection against SQL injection and XSS is only available in Standard SKU, as Premium is focused on Layer 7 DDoS
D) Front Door WAF operates on a regional subscription model, requiring policy replication in each backend region

Question 3 — True or False​

Azure Front Door can be used as a load balancing and content acceleration solution for applications based exclusively on non-HTTP protocols, such as MQTT or FTP, as long as the backends are publicly exposed.

True or False?

Question 4 — Technical Scenario​

A media company is migrating its streaming platform to Azure. Video files are large and accessed repeatedly by users in different countries. The team wants to reduce load on origin servers and improve loading times for geographically dispersed users, without giving up control over cache headers.

The architect proposes using Azure Front Door with caching enabled in routing rules.

What behavior should the architect consider when evaluating this approach?

A) Front Door caches static content in global points of presence (PoPs), serving subsequent requests without hitting the origin, as long as cache rules allow
B) Front Door caching applies only to responses with status 200, and files above 1 GB are automatically excluded from cache regardless of configuration
C) Front Door delegates cache control entirely to the origin's CDN; it's not possible to define independent cache rules in Front Door itself
D) Caching is only available for routes configured with HTTPS protocol; HTTP routes are always forwarded directly to the origin

Question 5 — Multiple Choice​

An engineering team needs to decide between Azure Front Door and Azure Application Gateway for a new project. The application is an internal portal, accessed only by employees within a corporate virtual network, without internet exposure.

What is the most appropriate technical conclusion for this scenario?

A) Azure Front Door is the correct choice, as it supports virtual network integration via Private Link in all SKUs
B) Azure Application Gateway is more suitable, as it operates within a virtual network and serves regional internal load balancing scenarios
C) Both solutions are equivalent for this case, with the choice based only on cost
D) Azure Front Door should be preferred for offering managed WAF, regardless of the application's access scope

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Azure Front Door natively offers latency-based routing, which directs each user to the backend with the lowest response time measured from the nearest PoP. Health probes continuously monitor the availability of each backend and, when a region fails, Front Door automatically removes the endpoint from rotation, without manual intervention.

The main misconception in the distractors is confusing tools:

  • A describes priority routing, which is suitable for fixed priority failover, not for continuous latency optimization.
  • C describes Azure Traffic Manager, which operates at the DNS layer and doesn't offer content acceleration or layer 7 proxy.
  • D describes Application Gateway, which is regional by nature and doesn't solve the global distribution problem.

Choosing Traffic Manager instead of Front Door for this scenario would result in slower failover (dependent on DNS TTL) and absence of content acceleration at the edge.

Answer Key — Question 2​

Answer: A

Azure Front Door WAF operates at global points of presence, inspecting and filtering traffic before it's forwarded to any backend. This means requests with SQL injection or XSS patterns are blocked at the network edge, regardless of the number of configured backends. The WAF policy is defined once in the Front Door profile and applies to all associated routes.

The distractors represent recurring misconceptions:

  • B suggests that WAF policy needs to be replicated per backend, which contradicts Front Door's centralized model.
  • C inverts the SKUs: WAF protection with advanced managed rules is available in Premium, not Standard.
  • D confuses Front Door with regional solutions like Application Gateway, which indeed operates per region.

Understanding that Front Door WAF is a global and centralized control is fundamental to justify its use in multi-region architectures.

Answer Key — Question 3​

Answer: False

Azure Front Door was designed exclusively for HTTP and HTTPS traffic. It operates at layer 7 of the OSI model and doesn't support protocols like MQTT, FTP, SMTP, or any other non-HTTP-based protocol.

This is an important architectural limitation: Front Door performs inspection, routing, caching, and WAF only on HTTP/HTTPS requests. For arbitrary TCP/UDP protocols, the appropriate solution would be Azure Load Balancer (layer 4) or Azure Gateway Load Balancer, depending on the scenario.

Ignoring this restriction would lead to an incorrect architecture choice for IoT workloads, file transfer, or other non-HTTP-based application layer protocols.

Answer Key — Question 4​

Answer: A

Azure Front Door caches responses in its global PoPs, reducing the number of requests that reach the origin. Cache behavior is controllable via routing rules, where you can define cache duration, ignore query strings, or force revalidation, offering granular control over what is stored and for how long.

The distractors introduce limitations that don't exist or distort actual functionality:

  • B imposes a 1 GB limit as an automatic barrier, which isn't a default behavior documented this way as an absolute cache limitation.
  • C incorrectly states that Front Door delegates all cache control to the origin; in practice, Front Door rules can override origin cache directives.
  • D restricts caching only to HTTPS, which doesn't correspond to the service's actual behavior.

Understanding that Front Door can override or complement origin cache directives is essential for properly dimensioning CDN strategy.

Answer Key — Question 5​

Answer: B

Azure Front Door is a global service external to virtual networks. It doesn't operate within a VNet and was designed for internet-originated traffic. Although the Premium SKU supports Private Link for connecting to private backends, Front Door itself remains a public entry point.

For an exclusively internal application, accessed within a corporate virtual network, Azure Application Gateway is the correct choice: it's deployed within a VNet, supports regional load balancing, WAF, and integration with internal resources without exposing the service to the internet.

The distractors represent scope errors:

  • A is partially true regarding Private Link, but confuses the ability to connect private backends with the ability to make Front Door an internal service, which isn't possible.
  • C treats the solutions as equivalent, ignoring the fundamental difference between global/public and regional/private scope.
  • D justifies the choice by WAF without considering the exclusively internal access requirement, where exposing a public endpoint would be a design failure.