Cascade Regional Airlines wants to publish both its public booking site (booking.cascaderegional.com) and a separate partner portal (partners.cascaderegional.com) through the same Application Gateway public IP, with each hostname routed to its own backend pool. Which Application Gateway feature makes this possible?
Select an answer to reveal the explanation.
Short Explanation
One public IP, two totally different websites — the gateway needs a way to tell them apart. Multi-site listeners read the hostname each visitor typed and send booking.cascaderegional.com one way and partners.cascaderegional.com another.
Full Explanation
A multi-site listener configuration lets an Application Gateway host more than one domain behind a single public IP by matching the Host header (or the SNI value on HTTPS) of each incoming request and routing it to a rule specific to that hostname, which lets booking.cascaderegional.com and partners.cascaderegional.com each reach a distinct backend pool without needing separate gateways or IPs. Path-based routing splits traffic by URL path within a single hostname's listener, which would not distinguish between two entirely different domains sharing the gateway. Source IP affinity is a session-persistence setting that keeps one client pinned to one backend instance; it has nothing to do with separating traffic by hostname. Inbound NAT rules exist on Azure Load Balancer, not Application Gateway, and are used for one-to-one management access to a single VM rather than hostname-based web routing. The exam-relevant caveat: HTTPS multi-site listeners on the same port require Server Name Indication (SNI), since the gateway must see the hostname the client requested before the TLS handshake completes in order to pick the right certificate. Operationally, confirm the setup by checking each listener's configured hostname and matching rule in the portal, then test with curl against each domain to verify they land on their respective backend pools.