Troubleshooting Lab: Configure rewrite rule sets
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team reports that requests sent to an application exposed via Application Gateway v2 are reaching the backend with an incorrect X-Forwarded-Host header. The environment uses Standard_v2 SKU and WAF is enabled in detection mode. The security team recently adjusted WAF rules to detect header injection but did not change any other configuration.
The responsible engineer checks the rewrite rule set and finds the following configuration:
Rewrite Rule Set: rrs-headers
Rule: fix-forwarded-host
Condition:
Variable: http_req_header_host
Pattern: .*
Action:
Type: set
Header type: request header
Header name: X-Forwarded-Host
Header value: {http_req_header_host}
The rule set is listed in the gateway configuration, and the listener is active. Tests with curl show that the X-Forwarded-Host value reaching the backend is the gateway's internal IP, not the client's hostname.
What is the root cause of the problem?
A) WAF in detection mode is changing the X-Forwarded-Host header value before the rewrite rule is applied
B) The rewrite rule set is not associated with any request routing rule, so the rule is not executed
C) The variable {http_req_header_host} resolves to the backend pool hostname, not the original request's Host header
D) The Condition with pattern .* invalidates the Action, as this pattern matches any value and is ignored by the rewrite engine
Scenario 2 — Action Decision
The platform team identified that an Application Gateway in production is forwarding URLs to the backend with the query string parameter debug=true in all requests, even those from end users. The cause has been confirmed: an incorrectly configured rewrite rule is inserting this parameter in all requests, without any Condition.
The environment has the following constraints:
- The gateway handles 100% of production traffic for a financial application
- There is a maintenance window available in 6 hours
- There is a staging environment with identical configuration to production
- The team has permission to modify the gateway outside the window, as long as the impact is validated beforehand
What is the correct action to take at this moment?
A) Immediately remove the incorrect rewrite rule from the production gateway, as the impact is ongoing and each request exposes the unwanted parameter
B) Validate the fix in the staging environment, document the result, and apply the change in production within the maintenance window
C) Validate the fix in the staging environment and, once the result is confirmed, apply the change in production now, without waiting for the window
D) Immediately disable the entire rewrite rule set in production to stop the problem, and recreate only the correct rules during the maintenance window
Scenario 3 — Root Cause
A web application receives requests via Application Gateway v2. The development team configured a rewrite rule to internally redirect paths with prefix /legacy/ to /v2/. After deployment, pages with path /legacy/reports work, but pages with path /legacy/reports/monthly return HTTP 404 on the backend.
Backend logs show:
GET /v2/reports HTTP/1.1 -> 200 OK
GET /v2/reports HTTP/1.1 -> 200 OK
GET /v2/reports HTTP/1.1 -> 200 OK
The backend is healthy and responds normally to /v2/reports/monthly when tested directly. The rewrite rule configuration is:
Condition:
Variable: uri_path
Pattern: /legacy/reports
Case-sensitive: true
Action:
URL rewrite
Modified path: /v2/reports
Reevaluate backend pool: false
The Application Gateway has Standard_v2 SKU. The listener's TLS certificate was renewed the previous week, but the certification chain was not changed.
What is the root cause of the problem?
A) The TLS certificate renewal corrupted the listener state, causing only short paths to be routed correctly
B) The flag Reevaluate backend pool: false prevents paths with sublevels from being sent to the correct backend
C) The pattern /legacy/reports matches as a substring to any path containing that sequence, and the Action replaces the entire path with the fixed value /v2/reports, discarding the rest of the original path
D) The Condition with Case-sensitive: true prevents matching of paths that contain uppercase letters after /legacy/reports
Scenario 4 — Diagnostic Sequence
An engineer receives a ticket: the Application Gateway is not inserting the Cache-Control: no-store header in HTTP responses, as required by security policy. The rewrite rule set was created and apparently configured. No changes have been made to the backend or listener in the last 48 hours.
Available investigation steps are:
- Verify if the rewrite rule set is associated with the correct request routing rule
- Confirm in the portal or via ARM that the Action type is configured as
setinhttp_res_header - Inspect actual HTTP responses with
curl -Ito confirm the header's absence - Verify if the rule's Condition, if it exists, is being satisfied by test requests
- Confirm that the header name in the Action is written exactly as
Cache-Control, without capitalization or space variations
What is the correct investigation sequence?
A) 3 -> 1 -> 2 -> 4 -> 5
B) 1 -> 2 -> 3 -> 4 -> 5
C) 3 -> 2 -> 1 -> 5 -> 4
D) 2 -> 1 -> 4 -> 3 -> 5
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the statement: the rule set is "listed in the gateway configuration," but this doesn't mean it's associated with a request routing rule. In Application Gateway, the existence of the rewrite rule set as a configuration object produces no effect while it's not linked to one or more request routing rules. Traffic flows through the listener and routing rule without applying any rewriting.
The value the backend receives, the gateway's internal IP, is the default Application Gateway behavior when no header rewriting is active: the gateway acts as a proxy and the X-Forwarded-Host reflects the gateway's own address, not the original host.
The information about WAF in detection mode is purposefully irrelevant: detection mode logs but doesn't block or modify headers. The most dangerous distractor is C, since the variable {http_req_header_host} correctly resolves to the client request's Host header, not the backend. Acting based on C would lead the engineer to incorrectly change the variable without solving the real problem.
Answer Key — Scenario 2
Answer: C
The cause is identified and confirmed. The scenario constraints authorize changes outside the window as long as they're validated previously. The staging environment exists exactly for this purpose. The correct sequence is: validate in staging and apply immediately in production after confirmation, without waiting for the window.
Answer B is technically safe but ignores the explicit constraint that allows acting before the window, and unnecessarily prolongs an active problem that exposes the debug=true parameter to end users of a financial application. Answer A ignores the principle of validating before acting in production. Answer D is the most dangerous: disabling the entire rewrite rule set may remove other correct and in-use rules, causing collateral impact on functionalities that depend on other configured rewrites.
Answer Key — Scenario 3
Answer: C
The backend logs confirm the diagnosis: all requests arrive as GET /v2/reports, regardless of the original path. This reveals that the Action replaces the entire path with the literal value /v2/reports, without preserving any part of the original path beyond what's in the regex.
The problem lies in two combined factors: the pattern /legacy/reports acts as substring matching, so /legacy/reports/monthly also matches. But the Action defines a fixed path /v2/reports, without any capture group that preserves /monthly. The result is that any path variation after the prefix is discarded.
The information about TLS certificate renewal is irrelevant and was purposefully included to divert the diagnosis. The Reevaluate backend pool flag controls whether the gateway reevaluates which backend pool to use after rewriting, but doesn't affect the construction of the rewritten path. Distractor D, about case-sensitivity, doesn't apply because all paths in the scenario are lowercase.
Answer Key — Scenario 4
Answer: A
The correct sequence starts with confirming the actual symptom (step 3): before investigating configurations, the engineer needs to confirm with objective evidence that the header is really absent in responses. Without this confirmation, the diagnosis might be chasing a problem that doesn't exist or has already been resolved.
Next, step 1 checks if the rule set is associated with the routing rule, as this is the most common and easiest cause to verify. Step 2 confirms if the Action is correctly typed as response and not request. Step 4 verifies if an existing Condition is being satisfied. Step 5 checks header name writing details, which is the most specific and unlikely error, so it should be investigated last.
Sequence B seems logical but starts with configuration without confirming the symptom, which is a diagnostic method error: the engineer might spend hours adjusting configurations that are already correct while the real problem is something else.
Troubleshooting Tree: Configure rewrite rule sets
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or intermediate verification |
To use this tree when facing a real problem, start with the root node describing the symptom and answer each question based on what you can observe or verify directly in the portal, via ARM, or with tools like curl. Follow the path that corresponds to what you find at each step. When the path leads to a red node, you've identified the cause; when it leads to a green node, you have the correct action to execute. If the rewrite is being applied but the result is still incorrect, return from the orange validation node to investigate the Action logic.