Design and implement Azure Front Door

Ardenwick Legal hosts a document portal on an internal Standard Load Balancer named lb-docs in a virtual network in UK South, with no public IP anywhere in the application. The portal must be published to the internet through Azure Front Door only, and no other path from the internet to the virtual network may exist. The company currently has an Azure Front Door Standard profile. The solution must minimize changes to the application network.

What should you do?

1. AUpgrade the profile to Front Door Premium, create an Azure Private Link service that fronts lb-docs, add the Private Link service as an origin with Private Link enabled, then approve the pending private endpoint connection on the Private Link service.Only Premium supports Private Link origins; an internal load balancer is exposed to Front Door by placing a Private Link service in front of it, and the connection becomes active once the resource owner approves Front Door's private endpoint request.
2. BKeep Front Door Standard, add a public IP to lb-docs, and restrict the network security group to the AzureFrontDoor.Backend service tag.This adds a public frontend to the application, which the scenario forbids, and the service tag allows all Front Door profiles rather than just this one; it is also an inferior security posture to Private Link.
3. CUpgrade to Front Door Premium and add the private IP address of lb-docs as an origin with Private Link enabled.Front Door cannot reach a private IP directly; a Private Link origin must be a supported resource type such as a Private Link service, App Service, or storage account, and an internal load balancer requires the Private Link service wrapper.
4. DKeep Front Door Standard, create a private endpoint in the virtual network that points to the Front Door profile, and add lb-docs as an origin.Private Link in Front Door works in the other direction: Front Door creates the private endpoint toward your origin, and the capability is not available in the Standard tier.

Larchmont Finance has created an Azure Front Door Standard profile named afd-trade with an endpoint named trade-endpoint. The trading web app runs in two regions: app-trade-eus in East US is the primary and app-trade-weu in West Europe is a standby that must receive traffic only when East US is unhealthy. Both apps expose a health endpoint at /healthz. The web app must be reachable at https://trade.larchmont.example/, and requests for any path must reach the application.

Which three actions should you perform? Each correct answer presents part of the solution.

1. ACreate an origin group with a health probe to /healthz over HTTPS, and add both apps as origins with app-trade-eus at priority 1 and app-trade-weu at priority 2.Origin priority inside an origin group provides active/standby behaviour: Front Door sends traffic to the lowest-priority-number healthy origin and fails over to the next only when probes fail.
2. BAdd trade.larchmont.example as a custom domain on the profile, validate it with the required DNS TXT record, and create a CNAME from trade.larchmont.example to the trade-endpoint host name.A custom domain must be validated and then associated with the endpoint through a route; the CNAME to the endpoint host directs client traffic into Front Door.
3. CCreate a route on trade-endpoint for the custom domain with the pattern /* and HTTPS only, pointing to the origin group.The route binds the domain and path pattern to the origin group; /* matches every path and HTTPS only enforces the required scheme.
4. DCreate two origin groups, one per region, and two routes with the pattern /*, each pointing to one group.Two routes with identical domain and pattern conflict, and splitting the origins into separate groups removes the health-based failover that an origin group provides.
5. EAdd both apps as origins with equal priority 1 and weight 50, so that traffic is spread evenly across the two regions.Equal priority and weight produces active/active distribution, but the scenario requires West Europe to be a standby that only serves traffic during an East US outage.

Marlowe Analytics serves a personalized dashboard over HTTPS from an App Service in West US 2. Every response is unique to the signed-in user, so nothing can be cached. Users in Europe and Asia complain that the dashboard takes several seconds to load, mostly during the TLS handshake and initial connection. The team wants to reduce that latency without adding regional deployments.

What should you do?

1. APlace the App Service behind Azure Front Door Standard with a route that has caching disabled.Front Door terminates TLS at the edge POP nearest the user and uses split TCP with warm, long-lived connections to the origin over the Microsoft backbone, so dynamic uncacheable content still loads faster; caching is simply left off.
2. BPlace the App Service behind Azure Front Door Standard with caching enabled and a cache duration of one minute.Caching personalised responses risks serving one user's dashboard to another; acceleration does not depend on caching, so enabling it is both unnecessary and unsafe here.
3. CCreate an Azure Traffic Manager profile with the performance routing method and the App Service as its only endpoint.With a single endpoint there is nothing to route between; Traffic Manager is DNS-based and cannot shorten the TLS handshake or TCP round trips to West US 2.
4. DDeploy an Application Gateway Standard v2 in West US 2 in front of the App Service and enable HTTP/2.The gateway sits in the same region as the origin, so European and Asian users still complete the TCP and TLS handshakes across the ocean.

Nightingale Books migrated its catalogue from an old application to a new one behind Azure Front Door Standard. Old links on the internet still use https://books.nightingale.example/catalog/<id>. The new origin serves the same pages at /v2/items/<id>, and the browser address bar must continue to show the old URL. Separately, any request that arrives at the legacy host www.nightingale-books.example must be sent to books.nightingale.example with a permanent redirect that preserves the path.

What should you configure in a rule set associated with the route?

1. AA rule that matches request path Begins With /catalog/ and performs a URL rewrite with source pattern /catalog/ and destination /v2/items/ with Preserve unmatched path enabled, plus a rule that matches request host name www.nightingale-books.example and performs a URL redirect of type Moved (301) to host books.nightingale.example, preserving the path.A URL rewrite changes the path sent to the origin while the client's URL is untouched, and Preserve unmatched path keeps the <id>; a URL redirect action with a 301 changes the host while leaving path and query intact.
2. BA rule that matches request path Begins With /catalog/ and performs a URL redirect of type Moved (301) to /v2/items/, plus a rule that matches the legacy host and performs a URL rewrite to books.nightingale.example.The actions are swapped: redirecting /catalog/ changes the browser address bar, and a rewrite cannot change the host the browser uses.
3. CEnable the HTTPS redirect setting on the route and add a second origin for the legacy host.The route-level HTTPS redirect only moves HTTP to HTTPS, and adding an origin does nothing to translate paths or redirect hosts.
4. DA rule that matches request path Begins With /catalog/ and performs a URL rewrite with Preserve unmatched path disabled, plus a rule that uses the Route configuration override action to send legacy-host traffic to a different origin group.Disabling Preserve unmatched path drops the item id so every request lands on /v2/items/, and a route override forwards traffic rather than issuing the required redirect.