TL;DR: Load Balancer is layer 4 within a region, Application Gateway is layer 7 within a region with a web application firewall, Front Door is layer 7 at the global edge. Pick on the two axes of protocol layer and scope, and expect to use Front Door in front of a regional gateway for anything multi-region.
How to approach it
Give the two axes before naming products, because the three names are memorisable and the reasoning is not. Then state clearly that they combine rather than compete: the most common real architecture uses two of them together, so treating the question as a choice between three gets the shape wrong before any detail does.
A strong answer
The two questions that decide it: does the decision need to see the HTTP request, and does it need to happen close to the user or inside one region?
Azure Load Balancer is layer 4. It distributes TCP and UDP connections across a backend pool inside one region, using a five-tuple hash. It cannot see a URL path or a hostname, cannot terminate TLS and cannot route on anything in the request. It is extremely fast, costs little, and is the right answer for non-HTTP traffic, for internal traffic between tiers, and for anything where the routing decision is per connection. The internal variant gives you a private front end inside a VNet, which is how you balance an internal API without exposing it.
Application Gateway is layer 7 and regional. It terminates TLS, reads the request, and routes on hostname and path. That gives you path-based routing to different backend pools, host-based routing for several sites, cookie-based session affinity, URL rewriting, and end-to-end TLS if you want it re-encrypted to the backend. Its Web Application Firewall tier adds OWASP rule sets, which is often the reason it is chosen at all. It lives in a VNet, so it can reach private backends directly.
Front Door is layer 7 and global. It is an edge network with points of presence worldwide, terminating the connection close to the user and carrying traffic onward over Microsoft's backbone. What that buys is latency (the TLS handshake happens near the user, which takes a round trip out of every new connection and shows up most in tail latency), global routing to the healthiest or nearest region, failover between regions on health probes, caching for static content, and DDoS absorption at the edge. It also has a WAF.
The architecture that uses two:
user -> Front Door (global routing, WAF, TLS at the edge, caching)
-> Application Gateway, region A (path routing, private backends)
-> Application Gateway, region B
Front Door decides which region, the gateway decides which service inside it. For a single-region application, Application Gateway on its own is usually enough, and adding Front Door buys you edge termination and DDoS protection rather than routing you need.
Traffic Manager deserves a mention because it looks like Front Door and is not. It is DNS-based: it returns a different answer depending on the routing method, and the client then connects directly. So it works for any protocol, not just HTTP, and it inherits DNS's failover problem.
That problem is worth adding up rather than describing, because "minutes" is doing a lot of work. Three delays stack. The probes have to decide a region is down, which with an illustrative 30-second interval and three required failures is about 3 × 30 = 90 seconds. Then the DNS record's TTL has to expire, so a 60-second TTL adds up to 60 more. Then the client has to honour that expiry, and many do not: a JVM with default settings caches a resolved address for the life of the process, and some resolvers round TTLs up. So the floor is roughly 90 + 60 = 150 seconds, two and a half minutes, and there is no ceiling, because the last term is somebody else's cache.
Front Door terminates the connection itself, so only the first term applies: probes fail and the edge stops forwarding, with no client or resolver in the loop. Same detection time, none of the cache. Check the current probe and TTL defaults for the product rather than relying on those figures, since the structure rather than the numbers is the point: a DNS mechanism can only ever ask clients to move, and a proxy mechanism moves the traffic itself.
For HTTP, prefer Front Door. For non-HTTP global routing, Traffic Manager is what exists, and the failover arithmetic above is the price.
What interviewers probe next
"How does failover actually work in Front Door?" Health probes against each backend, with priority and weight. Traffic moves at the edge as soon as probes fail, with no client involvement, which is why it is far faster than a DNS change.
"Where would you put the WAF?" Once, as far forward as possible, so Front Door if you have it. Running WAF in both places doubles the cost and the false positives for little benefit.
"Can Application Gateway reach a backend in another region or on-premises?" Yes over VNet peering or a VPN, and it is usually the wrong shape. Cross-region backends belong behind a global front end rather than a regional one reaching across.
Common mistakes
Presenting the three as competitors when the common design layers Front Door over Application Gateway.
Using Traffic Manager for HTTP failover and being surprised that recovery takes minutes because of DNS caching.
Reaching for Application Gateway to balance non-HTTP traffic, which is what Load Balancer is for.
Putting a WAF at two layers and paying twice for the same rule set.