The lock-booking site now has users on two continents and needs anycast HTTPS at the edge with a single global hostname. Which entry-point choice should the security engineer make?
Select an answer to reveal the explanation.
Short Explanation
Two continents and one global hostname scream Azure Front Door. A second regional Application Gateway isn’t anycast, and Traffic Manager isn’t the January 2026 headline skill here.
Full Explanation
Users on two continents who need anycast HTTPS at the edge with a single global hostname for the lock-booking site should use Azure Front Door for global Layer-7/CDN entry. When the documented regional reverse-proxy pattern is also required, pair Front Door with Application Gateway rather than pretending a second regional gateway is global anycast.
Deploying only a second regional Application Gateway in one continent fails by concept: Application Gateway is regional and does not provide global anycast with one hostname across continents. Replacing both Front Door and Application Gateway with Traffic Manager fails by concept: Traffic Manager is DNS-based routing and is not the first-class January 22, 2026 public-access skill for global L7/CDN HTTPS entry in this objective. Using Azure Firewall DNAT alone fails by concept: DNAT publishes network mappings; it is not a global HTTPS application edge with anycast and CDN features.
Exam caveat: Front Door for global L7; Application Gateway for regional L7; Traffic Manager ≠ Front Door for this bullet. Operational check: place Front Door in front with a single global hostname, origin to regional Application Gateway or apps as designed, verify anycast HTTPS from both continents, and keep Firewall DNAT out of the web-edge role.