Cloud / Azure Application Gateway Interview questions

Azure Application Gateway is a regional, layer 7 load balancer for web traffic. It accepts HTTP, HTTPS, WebSocket and HTTP/2 requests and decides which backend should handle each one by looking at the host name, URL path, headers and cookies, not just IP and port.

On top of routing, it gives you TLS termination, cookie-based session affinity, URL rewrite, redirection, autoscaling, zone redundancy and an optional built-in Web Application Firewall (WAF).

You typically place it in front of web apps running on VMs, virtual machine scale sets, App Service, AKS or even on-premises servers.

A gateway is assembled from a handful of resources that work together. A request enters through a frontend IP, is matched by a listener, handed to a routing rule, and finally forwarded to a backend pool using the backend settings.

• Frontend IP configuration - public and/or private IP clients connect to.
• Listener - protocol, port, host name and certificate that accept connections.
• Routing rule - binds a listener to a backend pool and backend settings.
• Backend pool - the servers that receive traffic.
• Backend settings - backend port, protocol, timeout, affinity, host header.
• Health probe - checks whether each backend can serve traffic.
• WAF policy (optional) - rule sets and custom rules.

All of it lives in a dedicated subnet of your virtual network.

There are two current SKUs: Standard_v2 and WAF_v2. Both run on the v2 architecture, and WAF_v2 simply adds the Web Application Firewall. The older v1 SKUs (Standard and WAF) were retired on April 28, 2026, so new designs should only use v2.

Pick WAF_v2 for anything exposed to the internet that handles user input; Standard_v2 is fine for internal apps already protected elsewhere.

It works at layer 7 (application layer). The gateway terminates the client's TCP connection, reads the HTTP request, applies its rules, and then opens a separate connection to the chosen backend.

Because it actually parses the request, it can route by URL path, rewrite headers, set cookies and inspect payloads for attacks. A layer 4 device such as Azure Load Balancer only sees IPs, ports and protocol, so it cannot do any of that.

A backend pool is the set of targets that receive traffic once a routing rule selects it. Targets can be VM network interfaces, virtual machine scale sets, public or private IP addresses, FQDNs, or an App Service app.

A gateway can have many pools, for example one for /api/* and one for /images/*. Traffic is spread across healthy members of the pool; members flagged unhealthy by the health probe are skipped until they recover.

Pool members must be reachable from the gateway subnet, so check NSGs, routes and peering when a target stays unhealthy.

A listener is the entry point that checks for incoming connection requests. It is defined by a frontend IP, port, protocol (HTTP or HTTPS) and, for HTTPS, a certificate. Multi-site listeners also include one or more host names.

A listener does not decide where traffic goes. It only accepts and decrypts the request; the associated routing rule then sends it to a backend pool.

A gateway can hold many listeners, for example port 80 and 443 on the same public IP, or one per host name. Each listener can also carry its own WAF policy and custom error pages, which makes it the natural place to apply per-site settings.

There are two: basic and multi-site.

Use a basic listener for a single application. Switch to multi-site when shop.contoso.com and blog.contoso.com must go to different pools behind one gateway.

Both types can use HTTP or HTTPS, and both can sit on a public or private frontend IP. The choice only changes how requests are matched, not how they are secured.

A routing rule connects a listener to a backend. When a request arrives on a listener, the rule says what to do: send it to a backend pool using certain backend settings, or redirect it elsewhere.

Rules come in two flavours: basic (one pool for everything) and path-based (different pools per URL path). On v2, every rule also needs a unique priority number; lower numbers are evaluated first.

flowchart LR
  C[Client] --> L[Listener]
  L --> R{Routing rule}
  R -->|Basic| P1["Single backend pool"]
  R -->|Path-based| P2["Pool chosen by URL path"]
  R -->|Redirect| X["Redirect target"]

Remember that the listener only accepts the connection; the rule is what gives the request a destination. A listener with no rule attached cannot forward anything, so incomplete rules are a common reason for an empty-looking gateway.

Path-based routing sends requests to different backend pools depending on the URL path. A single listener holds a path map such as /api/* to the API pool, /images/* to a static content pool, and a default pool for everything else.

This lets you split one site across specialised server groups without exposing multiple public endpoints. Paths are evaluated in the order listed, so put more specific patterns before broader ones.

/api/*     -> pool-api
/images/*  -> pool-static
(default)  -> pool-web

This also pairs well with different backend settings per path, such as a longer timeout for a report-generation endpoint. Combine it with URL rewrite if the backend paths differ from the public ones.

TLS termination means the gateway decrypts HTTPS traffic at the listener and forwards it to the backend as plain HTTP. The backend servers are freed from the CPU cost of encryption and certificate handling.

You upload a PFX certificate (or reference one in Key Vault) on the HTTPS listener. Termination also lets the gateway read the request, which is what makes WAF inspection and path routing possible.

If compliance demands encryption all the way to the server, use end-to-end TLS instead.

A health probe periodically sends requests to each backend member to decide whether it should receive traffic. Without a custom probe, the gateway uses a default one that requests / on the backend settings port and treats status codes 200-399 as healthy.

Custom probes let you set host, path, interval, timeout, unhealthy threshold and the accepted status codes or body text. A dedicated /health endpoint is better than the home page because it can check dependencies cheaply.

A member that fails the threshold is marked unhealthy and removed from rotation.

The WAF is an optional feature of the WAF_v2 SKU that inspects HTTP(S) requests for common attacks before they reach your app. It is based on the OWASP Core Rule Set and blocks threats such as SQL injection, cross-site scripting, command injection and protocol violations.

You can add custom rules (for IP allow/deny, geo-matching, rate limiting), turn on bot protection, and attach different policies to different listeners or URL paths.

It works at the gateway, so one WAF protects every backend behind it.

A WAF policy runs in one of two modes.

A common rollout is to start in Detection, review the firewall logs for false positives, add exclusions, and then switch to Prevention.

The mode is set on the WAF policy, so you can run one site in Prevention while another stays in Detection. Switching modes does not require redeploying the gateway.

Cookie-based session affinity keeps a user's requests on the same backend server. When enabled in the backend settings, the gateway adds a cookie named ApplicationGatewayAffinity to the first response, and later requests carrying that cookie go to the same pool member.

It is useful for apps that keep session state in server memory. The better long-term fix is externalising state to Redis or a database, because affinity can create uneven load and breaks when the server is removed.

It is configured on backend settings, not on the listener.

Connection draining lets existing requests to a backend member finish gracefully when that member is being removed from the pool or marked unhealthy during an update. New requests go to other members, while in-flight ones are given time to complete.

You enable it per backend settings and set a drain timeout (1 to 3600 seconds). After that timeout, remaining connections are closed. It prevents dropped uploads or half-finished checkouts during rolling deployments and scale-in.

Draining applies to planned removals such as scale-in or deployments; a server that crashes simply drops its connections. Pair it with graceful shutdown in the application for best results.

With autoscaling, the v2 gateway adds or removes instances automatically as traffic changes, within a minimum and maximum you set. You no longer choose a fixed instance size as you did on v1.

Setting a minimum of 2 gives you a warm baseline and faster response to spikes; a minimum of 0 saves money but means new instances must spin up on demand. The maximum (up to 125) caps both scale and cost.

Scaling is driven by capacity units, which measure compute, connections and throughput.

The gateway must live in its own dedicated subnet inside a virtual network. In practice no other resource types can share it, and v1 and v2 gateways cannot be mixed in one subnet.

• A /24 is recommended for v2 so it can scale to its maximum.
• Each instance consumes a private IP address, plus Azure reserves 5 addresses in every subnet.
• NSGs on the subnet must permit the GatewayManager service tag on ports 65200-65535 and the Azure load balancer probes.

Plan this early; resizing a subnet that already hosts a gateway is painful.

URL rewrite lets the v2 gateway change the request path or query string before forwarding it to the backend, without issuing a redirect. The client never sees the change.

A typical case is exposing /shop/products to users while the backend expects /products. Rewrites are defined in a rewrite set with optional conditions on headers or server variables, and attached to a routing rule. The same feature also rewrites request and response headers.

Because the rewrite happens inside the gateway, the browser address bar stays unchanged. Rewrite sets are evaluated after the routing rule matches, so path-based maps can still pick the pool first and then adjust the path.

It is a redirect configuration that sends clients from an HTTP listener to an HTTPS listener, usually with a 301 or 308 status. You create a listener on port 80, a second one on port 443, and a routing rule on port 80 whose action is Redirect to the HTTPS listener.

Options let you keep the path and query string so users land on the page they asked for. This avoids sending traffic in clear text without changing the application code.

Multi-site hosting lets one gateway serve several domains by matching the Host header of each request. You create one multi-site listener per host name, and each can have its own certificate, routing rule and backend pool.

For example, api.contoso.com can route to an API scale set while www.contoso.com goes to App Service. Wildcard names like *.contoso.com are supported, which helps with tenant-per-subdomain designs. It saves cost versus running a gateway per site.

Certificates are attached per listener, so each domain can present its own TLS certificate, or a single wildcard certificate can cover them all. Keep an eye on the listener and rule limits for very large tenant counts.

Backend settings (formerly HTTP settings) describe how the gateway talks to the backend pool. They control the backend port and protocol (HTTP or HTTPS), request timeout, cookie-based affinity, connection draining, host name override, custom probe and trusted root certificate for end-to-end TLS.

A routing rule pairs one backend pool with one set of backend settings, so the same pool can be reached differently by different rules. The default request timeout is 20 seconds.

Because the timeout is per settings object, slow endpoints can get their own settings and rule without affecting the rest. If requests exceed it, clients receive a 504 from the gateway.

A zone-redundant v2 gateway spreads its instances across availability zones in a region, so the loss of a single datacenter zone does not take the gateway down. The control plane and the data path are both zone-aware.

You choose zones when creating the gateway, and it needs a Standard SKU static public IP that is also zone-redundant. Combine this with backends spread across zones to get real end-to-end resilience; a zonal gateway in front of zone-redundant servers still has a single point of failure.

WebSocket is supported natively on v2 with no extra setting. The gateway sees the HTTP Upgrade request, passes it through, and keeps the long-lived connection open between client and backend. Use a standard HTTP or HTTPS listener, and make sure the backend itself accepts the upgrade.

HTTP/2 is supported for the client-facing side: browsers can talk HTTP/2 to the listener, while the connection to the backend continues to use HTTP/1.1. You can turn it on or off on the gateway.

Azure Load Balancer is a layer 4 service that distributes TCP/UDP flows by IP, port and protocol. Application Gateway is a layer 7 service that understands HTTP and can route by host, path and cookies.

They are often combined: Application Gateway for web tiers, Load Balancer for non-HTTP services like databases.

Both are layer 7, but the scope differs. Application Gateway is regional and sits inside your virtual network. Front Door is global, runs at Microsoft's edge, and adds anycast, CDN-style caching and global failover.

For multi-region apps many teams put Front Door in front of one gateway per region.

v2 is a re-architected platform and the only one you should deploy today; v1 was retired on April 28, 2026. The practical gains are speed, elasticity and features.

The v2 subnet also needs different NSG rules (ports 65200-65535 instead of 65503-65534), and v2 rules require a priority.

End-to-end TLS means the client connection is decrypted at the gateway for inspection, then re-encrypted to the backend. You set the backend protocol to HTTPS in the backend settings and make the gateway trust the server certificate.

1. Create an HTTPS listener with a certificate.
2. Set backend settings to HTTPS on port 443.
3. Trust the backend: v2 uses a well-known CA, or you upload the root CA certificate in the backend settings.
4. Make sure the certificate's CN or SAN matches the host name the gateway uses (or override the SNI).

A mismatch in name or an untrusted chain is the most common reason the probe turns unhealthy after enabling this.

Instead of uploading a PFX, you reference a certificate stored in Key Vault. The gateway uses a user-assigned managed identity with permission to read secrets, and fetches the certificate by its versionless secret ID.

Because the secret ID is versionless, the gateway re-checks Key Vault about every four hours and picks up a renewed certificate automatically, so there is no manual rotation. The vault must be reachable by the gateway (public with firewall exception for trusted services, or via private networking).

It keeps private keys out of templates and pipelines.

The backend sees the gateway's private IP as the source, so the real client address is carried in the X-Forwarded-For header. Application Gateway appends the client IP and port (as ip:port) to it. It also sends X-Forwarded-Proto and X-Original-Host.

Configure your web server or framework to read the right-most trusted entry, and strip the port if your logging tool expects only an IP. If you want a clean value, a response or request header rewrite using the var_client_ip server variable can create a custom header.

NSGs on the gateway subnet must allow traffic the platform depends on, otherwise the gateway fails or backends appear unhealthy.

• Inbound: client traffic on your listener ports (for example 80 and 443).
• Inbound: GatewayManager service tag on ports 65200-65535 for v2 (65503-65534 for v1).
• Inbound: AzureLoadBalancer service tag.
• Outbound: access to the backend pool and the internet for management.

Do not add a rule that denies the GatewayManager traffic; it is not optional.

Also remember that the NSG rules are evaluated for the gateway subnet, not the backend subnet; the backend NSG separately has to allow traffic from the gateway subnet range on the application port.

The v2 gateway needs a direct path to Azure platform services for management and control traffic. A user-defined route that forwards 0.0.0.0/0 to a firewall or virtual appliance breaks this path, and the gateway reports an error state.

If you must send backend-bound traffic through a firewall, create specific prefix routes for your backend subnets and leave the default route as Internet. A private-only deployment mode (network isolation) relaxes this limit, but it has its own NSG and subnet-delegation requirements, so check the current docs first.

A capacity unit is the billing and scaling measure on v2. It is the highest of three dimensions, each measured per unit:

• Compute: 1 compute unit handles about 10 TLS connections per second with a 2048-bit RSA certificate.
• Persistent connections: 2,500 per capacity unit.
• Throughput: 2.22 Mbps per capacity unit.

The gateway consumes whichever dimension demands the most units. Billing is a fixed hourly charge plus the capacity units used. You can track the Capacity Units and Current Compute Units metrics to see which dimension is limiting you.

A 502 means the gateway could not get a valid response from a backend. Work from the inside out.

flowchart TD
  A["502 Bad Gateway"] --> B{Backend Health shows Unhealthy?}
  B -->|Yes| C["Check probe path, host, status codes"]
  B -->|No| D{Backend slow or closing connections?}
  C --> E["Check NSG, UDR, firewall on backend"]
  D -->|Yes| F["Raise request timeout, check app logs"]
  D -->|No| G["Check TLS cert, SNI and host header"]

1. Open Backend health and read the exact error.
2. Verify NSGs and routes allow the gateway subnet to reach the backend port.
3. Confirm the probe path returns an accepted status code.
4. For HTTPS backends, validate the certificate chain and name.
5. Check access logs for serverStatus and timings.

If the 502 is intermittent, correlate timestamps in the access log with application logs, since a backend that restarts or resets idle connections often shows up as brief 502 bursts.

Start from the Backend health blade, which shows the status for each pool member and a readable reason such as timeout, status code mismatch or certificate error.

Fix by setting the probe host and path to match what the app expects, then re-test.

On v2 every request routing rule needs a unique priority between 1 and 20000. When more than one rule could match a request, the rule with the lowest number is evaluated first and wins.

This matters most with wildcard or overlapping multi-site listeners. For instance, a rule for *.contoso.com at priority 200 and one for admin.contoso.com at priority 100 means admin traffic correctly hits the specific rule. Leave gaps (10, 20, 30) so you can insert rules later without renumbering.

With anomaly scoring (OWASP CRS 3.x), the WAF does not block on the first matching rule. Each match adds points to a request's score based on severity, and the request is blocked only when the total reaches the threshold.

The threshold is 5, so one critical hit blocks a request in Prevention mode, whereas two notices (4 points) alone do not. This reduces blocks caused by weak signals, but you still need to review which individual rules contributed when tuning.

Tune with evidence, not guesses. Run the policy in Detection mode, collect ApplicationGatewayFirewallLog entries for a representative period, and find rules that fire on legitimate traffic.

1. Identify the rule ID and the matched field (header, cookie, argument, body).
2. Prefer a narrow exclusion for that field over disabling the whole rule.
3. Disable a rule only when an exclusion can't isolate it.
4. Add custom allow rules for trusted IPs or health checkers.
5. Re-test, then move to Prevention.

Keep a record of every exclusion and review them after app releases, because new parameters can change what the WAF sees.

Legacy WAF configuration is embedded in the gateway, so one configuration covers the whole gateway. A WAF policy is a separate Azure resource that you associate with a gateway, a listener or a URL path.

A policy also separates security ownership from gateway operations, since security teams can manage the policy independently. Microsoft recommends migrating legacy configurations to policies.

By default an App Service has a public endpoint, so users could bypass the gateway and WAF. Lock it down in one of two ways:

• Access restrictions with a service endpoint: enable the Microsoft.Web service endpoint on the gateway subnet and allow only that subnet on the app.
• Private endpoint: give the app a private IP and make the gateway reach it privately, then turn off public access.

The private endpoint is the stronger option because the public path no longer exists. With either choice, also validate the X-Forwarded-Host or host header handling so the app builds correct URLs.

The Application Gateway Ingress Controller (AGIC) is a pod in AKS that watches Kubernetes Ingress resources and translates them into Application Gateway configuration through Azure Resource Manager. Listeners, rules and backend pools are created for you.

With Azure CNI the gateway sends traffic straight to pod IPs, skipping an in-cluster ingress proxy and an extra hop. It can run as an AKS add-on or be installed with Helm.

Trade-offs: configuration changes go through ARM, so updates take longer than with an in-cluster controller, and the gateway is shared infrastructure outside the cluster.

Application Gateway for Containers is the newer, Kubernetes-native evolution of the service. It supports both the Gateway API and the Ingress API and is managed by the ALB Controller in your cluster.

Choose it for new AKS workloads that need fast config propagation or Gateway API features; keep AGIC where an existing gateway is already shared with non-Kubernetes apps.

A private-only gateway has a private frontend IP and no public IP, so it is reachable only from your network, peered networks or on-premises over VPN/ExpressRoute. It is the right design for internal line-of-business apps.

1. Deploy v2 in private deployment (network isolation) mode, which uses a delegated subnet (Microsoft.Network/applicationGateways).
2. Create the frontend with only a private IP.
3. Define explicit NSG rules, since the platform no longer adds hidden ones.
4. Add DNS records (often Azure Private DNS) pointing to the private IP.

Before this mode existed, v2 always required a public IP, so older internal designs often combined a public IP with NSGs; check the current docs for regional availability.

Cost has a fixed hourly part plus capacity units, so savings come from avoiding waste.

• Consolidate: host many sites on one gateway using multi-site listeners rather than one gateway per app.
• Right-size autoscaling: a sensible minimum, and a maximum that protects against runaway cost.
• Use Standard_v2 for internal apps that don't need WAF.
• Offload static content to a CDN or Front Door cache to cut throughput.
• Shrink payloads: enable compression at the app so throughput units drop.
• Watch the Capacity Units metric and review monthly.

Don't cut the minimum to 0 for production if you can't tolerate a scale-out delay.

Use Azure Monitor metrics for quick health and diagnostic logs for detail.

• Metrics: Unhealthy Host Count, Failed Requests, Backend Response Status, Total Requests, Capacity Units, Backend Last Byte Response Time.
• Logs: access log, performance log, firewall log, sent to Log Analytics, storage or Event Hub through a diagnostic setting.

Alert on unhealthy hosts and 5xx rates. A simple KQL query shows status code distribution:

AzureDiagnostics
| where Category == "ApplicationGatewayAccessLog"
| summarize count() by httpStatus_d, bin(TimeGenerated, 5m)
| order by TimeGenerated desc

Backend health in the portal complements this for per-server detail.

App Service uses the Host header to pick the right app. If the gateway forwards the public name (www.contoso.com) and that domain isn't bound to the app, App Service answers 404 or the probe goes unhealthy.

You have two fixes: bind the custom domain on App Service and keep the original host, or enable Pick host name from backend target so the gateway sends app.azurewebsites.net. The second is simpler but can break apps that generate absolute URLs or set cookies for the wrong domain; a Location header on redirects may then point at azurewebsites.net.

If that happens, fix it by rewriting the response headers or by preserving the host and binding the domain.

There is no in-place SKU change, so migration means building a new v2 gateway and moving traffic to it. Microsoft provides a migration tool (portal option and PowerShell script) that creates a v2 gateway with your listeners, rules, pools and settings copied across.

1. Create a new, separate subnet (v1 and v2 cannot share one) and a Standard public IP.
2. Run the migration tool and review the generated v2 configuration.
3. Re-upload or reference certificates (Key Vault is recommended) and fix NSGs for ports 65200-65535.
4. Test the new gateway using its IP and a hosts entry.
5. Switch DNS to the new public IP, then retire the v1 gateway after a stability window.

The public IP changes, so lower DNS TTLs ahead of the cutover.

A request passes through several stages inside the gateway before it reaches your server, and each stage can modify or reject it.

sequenceDiagram
  participant C as Client
  participant G as Listener
  participant W as WAF
  participant R as Routing rule
  participant B as Backend pool
  C->>G: HTTPS request to frontend IP
  G->>G: TLS termination, host match
  G->>W: Decrypted request
  W-->>C: 403 if blocked (Prevention)
  W->>R: Allowed request
  R->>R: Path match, rewrite rules
  R->>B: New connection using backend settings
  B-->>R: Response
  R-->>C: Response, with header rewrites

Health probes run independently, so the rule only chooses among members currently marked healthy. Response header rewrites and the affinity cookie are applied on the way back.

Two details trip people up. First, the gateway opens a new connection to the backend, so the server sees the gateway's private IP and the client address arrives in X-Forwarded-For. Second, the WAF sees the request only after decryption, which is why TLS termination (or end-to-end TLS with re-encryption) is a prerequisite for inspection.

When debugging, follow the same order: listener match, WAF decision, rule and path match, rewrite, backend settings, probe state. The access and firewall logs record the outcome of the first and second stages, and Backend health explains the last.

You need a virtual network with a dedicated subnet, a Standard static public IP, and then the gateway itself. The example below creates a Standard_v2 gateway with two backend servers.

az network vnet create -g rg-agw -n vnet-agw --address-prefix 10.10.0.0/16 \
  --subnet-name snet-agw --subnet-prefix 10.10.1.0/24

az network public-ip create -g rg-agw -n pip-agw --sku Standard \
  --allocation-method Static --zone 1 2 3

az network application-gateway create -g rg-agw -n agw-demo \
  --sku Standard_v2 --min-capacity 2 --max-capacity 10 \
  --vnet-name vnet-agw --subnet snet-agw --public-ip-address pip-agw \
  --frontend-port 80 --http-settings-port 80 --http-settings-protocol Http \
  --priority 100 --servers 10.10.2.4 10.10.2.5

This creates a default listener, rule, pool and backend settings; add HTTPS, probes and a WAF policy afterwards. For repeatable environments, use Bicep or Terraform.

Three things to remember. The subnet must be dedicated to the gateway and a /24 leaves room to scale. The public IP has to be Standard SKU and static for v2. And the --priority flag is mandatory on v2 rules, so omitting it causes the create call to fail. Verify the result with az network application-gateway show-backend-health.

Application Gateway doesn't offer built-in weighted traffic splitting between pools, so true blue-green is done by switching rather than gradually shifting.

1. Create two backend pools, pool-blue (live) and pool-green (new version).
2. Test green privately, for instance with a second listener or a temporary path rule.
3. Flip the routing rule's backend pool to green.
4. Watch metrics and logs; flip back instantly if errors rise.
5. Retire blue after a safe period.

az network application-gateway rule update -g rg-agw --gateway-name agw-demo \
  -n rule-web --address-pool pool-green

If you need a percentage-based canary, use Front Door or Traffic Manager weighted routing in front, or Application Gateway for Containers for in-cluster traffic splitting.

Application Gateway is regional, so cross-region resilience comes from putting a global traffic director in front of one gateway per region.

flowchart TD
  U[Users] --> F["Front Door or Traffic Manager"]
  F -->|Primary| G1["App Gateway East US, zone-redundant"]
  F -->|Failover| G2["App Gateway West US, zone-redundant"]
  G1 --> B1["Backends in East US"]
  G2 --> B2["Backends in West US"]

• Make each gateway zone-redundant and spread backends across zones.
• Use Front Door (layer 7, with WAF and caching) or Traffic Manager (DNS-based) for health-based failover.
• Keep WAF policies and certificates consistent, using Key Vault and shared policies.
• Replicate data tiers, because routing alone doesn't make the app stateless.

Test failover regularly, including DNS TTL behaviour.

Also decide up front whether failover should be active-active or active-passive, because that determines how Front Door or Traffic Manager weights and priorities are set.