4 of the 10 questions we have for this objective, shown with the answer and the reasoning.
Design and implement Azure Application Gateway
Pellbrook Hosting operates one Application Gateway Standard v2 named agw-shared for several customer sites. Requests to shop.pellbrook.example and blog.pellbrook.example must go to two separate backend pools, and future subdomains ending in .pellbrook.example must be accepted by the same configuration and sent to a shared pool without creating a new listener for each one. All sites use HTTPS on port 443 with a wildcard certificate for *.pellbrook.example.
Which listener and routing rule configuration should you create?
- AOne multi-site listener on port 443 with the host names shop.pellbrook.example, blog.pellbrook.example, and *.pellbrook.example, and one request routing rule that targets the shared pool.A multi-site listener can hold up to five host names, but a listener is bound to a single routing rule, so every matched host reaches the same backend pool and shop and blog cannot be routed separately.
- BThree multi-site listeners on port 443 for shop.pellbrook.example, blog.pellbrook.example, and *.pellbrook.example, each with the wildcard certificate and its own routing rule, with the two exact-host rules given a higher priority (lower number) than the wildcard rule.Multi-site listeners route on the Host header; because a request for shop or blog also matches the wildcard listener, the rule priority must place the exact-host rules ahead of the wildcard rule so each named site reaches its own pool and new subdomains fall through to the wildcard.
- COne basic listener on port 443 with the wildcard certificate and a path-based routing rule for each site.A basic listener accepts all host names on its port and cannot tell shop from blog; path-based rules inspect the URL path, not the Host header, and a listener can be used by only one rule.
- DThree multi-site listeners on port 443 for shop.pellbrook.example, blog.pellbrook.example, and *.pellbrook.example, each with its own routing rule, with the wildcard rule given priority 1 so that every subdomain is evaluated against it first.If the wildcard rule is evaluated first, it also matches shop.pellbrook.example and blog.pellbrook.example, so the more specific listeners never receive traffic.
Why: Application Gateway offers two listener types. A basic listener accepts all requests on a port regardless of host, so only one can exist per frontend port. A multi-site listener matches the Host header and can list up to five host names, including wildcards such as *.pellbrook.example, so many sites can share port 443 with one wildcard certificate. Each listener is bound to exactly one request routing rule, so separate pools need separate listeners. When a request matches more than one listener, the v2 SKU uses the mandatory rule priority field (1 to 20000, where 1 is highest) to choose the rule. Application Gateway does not automatically prefer the more specific host name, so the exact-host rules must outrank the wildcard rule. The single-listener option is the trap for anyone who assumes several host names give several targets, and wildcard-first ordering is the trap that silently shadows the named sites.
Design and implement Azure Application Gateway
Feldspar Analytics has an Application Gateway Standard v2 named agw-data in a virtual network named vnet-data. The company wants the gateway to send requests for reports.feldspar.example to an Azure App Service named app-reports-prod, which has no virtual network integration. An administrator must create the backend pool for this application.
How should you define the backend target?
- AAdd the App Service by selecting the App Services target type, which registers the FQDN app-reports-prod.azurewebsites.net.Application Gateway backend pools accept App Services directly; the gateway resolves and forwards to the App Service FQDN, and the related backend setting typically overrides the host name with the backend target.
- BAdd the outbound IP addresses listed on the App Service as IP address targets.The outbound IPs are what the App Service uses for egress and are shared across many tenants; they are not inbound endpoints for the app and may change.
- CAdd the network interface of the App Service to the pool as a virtual machine target.App Service is a multi-tenant PaaS offering with no customer-visible network interface, so there is nothing to select as a NIC target.
- DAdd the App Service to an Azure Load Balancer backend pool and reference the load balancer as the gateway's backend target.Application Gateway cannot use a Load Balancer resource as a backend target, and Load Balancer pools cannot contain App Service apps.
Why: An Application Gateway backend pool can contain IP addresses or FQDNs, virtual machine NICs, virtual machine scale sets, and App Services. For a PaaS service such as App Service, the FQDN-based App Services target is the right type because the service has no NIC and its inbound address is reached by name. Using outbound IPs is the trap: they are the addresses the app connects out from, not where it listens. Once the pool exists, the backend setting should pick the host name from the backend target so the App Service receives its own hostname in the Host header.
Design and implement Azure Application Gateway
Glenmoor Learning hosts an online exam application behind an Application Gateway Standard v2 named agw-exam. The backend servers listen on HTTPS port 8443 with certificates issued by a public certificate authority. The application stores exam progress in server memory, so every request from a given student must reach the same backend server for the length of the session. During deployments, servers removed from the pool must finish in-flight exam submissions before they stop receiving traffic.
Which three settings should you configure in the backend setting used by the routing rule? Each correct answer presents part of the solution.
- ABackend protocol HTTPS with backend port 8443The backend setting defines how the gateway talks to the servers; because they listen with HTTPS on 8443 the protocol and port must match, and a public CA certificate needs no trusted root upload.
- BCookie-based affinity enabledCookie-based affinity makes Application Gateway issue an affinity cookie so every request from the same client session is sent to the same backend server, which the in-memory session state requires.
- CConnection draining enabled with a drain timeout of 300 secondsConnection draining lets a server that is being removed or marked unhealthy complete existing requests for the configured period before it stops receiving traffic.
- DOverride with new host name set to the gateway's frontend FQDNHost name override controls the Host header sent to the backend; it has nothing to do with sticking sessions to a server or draining connections.
- ERequest timeout set to 1 secondA one-second request timeout causes the gateway to return 504 errors on any slow backend response; it does not provide affinity or graceful removal.
Why: The backend setting (formerly called HTTP settings) is where Application Gateway defines its behaviour toward the backend pool: protocol and port, cookie-based affinity, connection draining, request timeout, host name override, and trusted root certificates. The scenario's constraints map directly: HTTPS 8443 for the backend protocol, cookie-based affinity for sticky sessions, and connection draining so in-flight submissions complete during deployments. Host name override and request timeout are real settings but solve different problems, which makes them the distractors. Because the backend certificates are from a public CA, no trusted root certificate upload is required.
Design and implement Azure Application Gateway
Rowanfield Travel has an Application Gateway Standard v2 named agw-travel with a multi-site HTTPS listener for book.rowanfield.example. Requests to /api/* must go to the pool pool-api with backend setting bs-api, requests to /static/* must go to pool-static with bs-static, and everything else must go to pool-web with bs-web. The gateway also has an HTTP listener on port 80, and all HTTP requests must be redirected to HTTPS.
Which routing rule configuration should you create?
- AOne path-based rule on the HTTPS listener with path map entries /api/* to pool-api and /static/* to pool-static and default target pool-web, plus one basic rule on the HTTP listener whose target is a redirect to the HTTPS listener.A single path-based rule carries the URL path map with its default target, and a redirect-type rule on the port 80 listener sends all HTTP traffic to the HTTPS listener with a permanent redirect.
- BThree basic rules on the HTTPS listener, one per backend pool, plus one basic rule on the HTTP listener targeting pool-web.A listener can be associated with only one routing rule, so three basic rules on one listener is invalid, and the HTTP rule forwards traffic instead of redirecting it.
- COne path-based rule on the HTTPS listener with entries for /api/* and /static/* and no default target, plus a rewrite rule set on the HTTP listener that changes the scheme to https.A path-based rule requires a default backend target for unmatched paths, and a rewrite rule cannot redirect a client; redirection is a rule target type.
- DOne path-based rule on the HTTP listener with the three pools, and a basic rule on the HTTPS listener targeting pool-web.This serves the segmented routing over plain HTTP and leaves the HTTPS listener with only one pool, inverting the intended design and never redirecting HTTP.
Why: A request routing rule binds exactly one listener to a backend target, and a listener can be used by exactly one rule. A basic rule forwards everything to one pool; a path-based rule holds a URL path map whose entries route by path pattern and whose default target handles all other paths. Redirection is a target type on the rule, so HTTP to HTTPS is achieved by a basic rule on the port 80 listener that targets the HTTPS listener. The distractors violate one rule each: multiple rules per listener, a path map without a default target, or confusing a rewrite with a redirect.