Cascade Regional Airlines wants a single Application Gateway to send requests for /booking to its web-farm backend pool and requests for /api to its internal reservations API backend pool, all behind one public IP and hostname. Which Application Gateway feature accomplishes this split?
Select an answer to reveal the explanation.
Short Explanation
One doorway, two different destinations depending on what's written on the request. That's exactly what path-based routing does — it reads the URL path and sends /booking one way and /api another, all through the same listener.
Full Explanation
Path-based routing lets a single Application Gateway listener inspect the URL path of an incoming request and forward it to a different backend pool based on a URL path map, so /booking/ and /api/ can be served by entirely separate backend pools — one for the web farm, one for the internal reservations service — while customers only ever see one public hostname and IP. Multi-site listeners solve a different problem: routing based on the hostname in the request (for example booking.cascaderegional.com versus partners.cascaderegional.com) rather than the path, so it would not split traffic within the same hostname by path. Session affinity keeps a given client's requests pinned to the same backend instance for state continuity; it has no role in deciding which backend pool handles which URL. A backend health probe only determines whether a pool member is healthy enough to receive traffic and plays no part in routing decisions between pools. The exam-relevant caveat: path-based rules are evaluated in order and the first matching path pattern wins, so a catch-all '/' rule must be placed last or it will shadow more specific paths like '/api/'. To verify the configuration, review the listener's URL path map in the portal and confirm /api/* points to the reservations backend pool while the default path falls through to the web-farm pool.