Troubleshooting Lab: Implement rules, URL rewrite, and URL redirect
Diagnostic Scenarios
Scenario 1 — Root Cause
A team reports that the Azure Application Gateway is ignoring a newly created rewrite rule. The gateway has been in production for six months without incidents. The rule was created to remove the X-Forwarded-Host header from backend responses before delivering them to clients. The responsible engineer confirms that the rule is correctly defined with the condition and header removal action. The SKU used is Standard V2. The gateway has three routing rules: two Basic type and one Path-based type.
After initial investigation, the engineer collects the following information:
Rewrite Rule Set: rrs-remove-header
Rule: remove-x-forwarded-host
Condition: (none)
Action: Response Header - Delete - X-Forwarded-Host
Routing Rules associated with rrs-remove-header:
(no association found)
Backend Health: Healthy
WAF Policy: Disabled
Users accessing via HTTPS report the same behavior. The SSL certificate was renewed last week without issues.
What is the root cause of the problem?
A) The rewrite rule was configured to act on responses, but Application Gateway only supports rewriting on incoming requests
B) The rewrite rule set is not associated with any routing rule, therefore it is never triggered
C) The Standard V2 SKU does not support response header removal, only request headers
D) The absence of a condition in the rule prevents its execution, as Application Gateway requires at least one condition to apply the action
Scenario 2 — Action Decision
The cause of an incident has been identified: a redirect rule in the Azure Application Gateway is configured with type Temporary (302) when it should be Permanent (301). The redirect points from http://store.contoso.com to https://store.contoso.com. The SEO team reports that Google is reindexing pages inconsistently, as some crawlers return to the HTTP endpoint before being redirected. The gateway serves 4.5 million requests per day and is in active production.
Changing the redirect type from 302 to 301 in the Azure portal requires the routing rule to be saved again, which causes a gateway instance restart, estimated at 2 to 4 minutes of partial unavailability.
The next approved maintenance window is in 72 hours. The product manager requests an immediate fix due to pressure from the SEO team.
What is the correct action to take at this moment?
A) Apply the change immediately, as the difference between 301 and 302 is only semantic and the actual impact of 2 to 4 minutes is acceptable at any time
B) Wait for the approved maintenance window in 72 hours to apply the change without risk of unauthorized impact
C) Create a new redirect rule with type 301 and disable the current rule, avoiding the restart
D) Escalate to the infrastructure team a request for a second gateway in parallel to apply the change without downtime
Scenario 3 — Root Cause
A company configured Azure Front Door to rewrite URLs before forwarding to the backend. The configuration was applied as follows:
Route: rt-api
Origin Group: og-api-backend
Patterns to match: /api/*
URL Rewrite:
Source pattern: /api/
Destination: /v2/
Preserve unmatched path: false
Developers report that calls to /api/orders/pending are returning HTTP 404 from the backend. The backend team confirms that the correct endpoint is /v2/orders/pending and that the service is healthy. Origin group logs show that requests are reaching the backend.
Additional information collected:
Front Door Health Probe: Healthy
WAF Policy: Detection mode (no blocks recorded)
Origin protocol: HTTPS
Backend certificate: Valid, renewed 10 days ago
What is the root cause of the observed behavior?
A) The WAF in Detection mode is silently blocking requests with the new path
B) With Preserve unmatched path set to false, the /orders/pending segment is discarded and the backend receives only /v2/, causing the 404
C) The HTTPS protocol on the origin requires URL rewriting to be disabled to work correctly
D) The /api/* pattern in the "Patterns to match" field conflicts with the /api/ source pattern, causing the rewrite to be ignored
Scenario 4 — Diagnostic Sequence
An engineer receives the following report: users accessing http://app.contoso.com/dashboard are being redirected to https://app.contoso.com without the /dashboard path. The Azure Application Gateway was recently reconfigured to force HTTPS.
The following investigation steps are available, out of order:
- Check if the Include path option is enabled in the redirect rule
- Confirm that the HTTP listener is active and receiving requests on port 80
- Identify which routing rule is associated with the HTTP listener
- Verify that the HTTPS certificate of the destination listener is valid and active
- Inspect the redirect rule configuration associated with the HTTP listener
What is the correct investigation sequence to diagnose the root cause?
A) 4 → 2 → 3 → 5 → 1
B) 2 → 3 → 5 → 1 → 4
C) 1 → 5 → 3 → 2 → 4
D) 3 → 2 → 1 → 4 → 5
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the data collected by the statement itself: Routing Rules associated with rrs-remove-header: (no association found). A rewrite rule set in Application Gateway is never automatically applied to all traffic. It needs to be explicitly linked to one or more routing rules. Without this association, the rule set exists in the configuration but is never invoked during request processing.
The information about SSL certificate renewal is irrelevant and was inserted to simulate the pressure to investigate the most recent event, which is a classic diagnostic error.
- Alternative A is false: Application Gateway supports rewriting both request and response headers.
- Alternative C is false: Standard V2 SKU supports both types of rewriting.
- Alternative D is false: conditions are optional in rewrite rules; the absence of a condition means the action is applied to all requests passing through the rule set.
The most dangerous distractor is A, as an incorrect diagnosis would lead the engineer to conclude that the feature doesn't exist, when in reality the rule is simply not connected to the processing flow.
Answer Key — Scenario 2
Answer: B
The critical constraint of the scenario is that the change requires a gateway instance restart, causing partial unavailability in a high-demand service. This action is not approved for the current moment. The change management process exists precisely to protect production environments from unauthorized impacts, regardless of external pressure.
- Alternative A ignores the process restriction and underestimates the impact: 2 to 4 minutes of partial unavailability in 4.5 million daily requests represents a real and unauthorized operational risk.
- Alternative C seems attractive, but is technically incorrect: it's not possible to have two active redirect rules for the same listener simultaneously without conflict, and disabling the current rule during new rule creation would create a window without redirection.
- Alternative D is disproportionate to the problem and would not resolve the need within the timeframe.
The fundamental principle here is that the correct fix applied at the wrong time can be worse than the original problem. The 72-hour window is the safe and approved action.
Answer Key — Scenario 3
Answer: B
With Preserve unmatched path set to false, Azure Front Door completely replaces the matched path with the configured destination, discarding any additional URL segments. In the case of the /api/orders/pending request, the matched segment is /api/ and the remainder (orders/pending) is the unmatched part. With the option disabled, this segment is discarded. The backend receives only /v2/, which is not a valid endpoint, resulting in HTTP 404.
The information about the renewed certificate and WAF in Detection mode is irrelevant and was included to induce the reader to investigate recent events instead of focusing on the rewrite configuration.
- Alternative A is incorrect: WAF in Detection mode logs but doesn't block; additionally, logs confirm that requests reach the backend.
- Alternative C is technically unfounded: the origin protocol doesn't affect URL rewrite behavior.
- Alternative D confuses two distinct fields with different purposes; "Patterns to match" defines when the route is activated, while "Source pattern" defines what is rewritten within that route. They coexist without conflict.
Answer Key — Scenario 4
Answer: B
The correct sequence is: 2 → 3 → 5 → 1 → 4.
The diagnostic reasoning should follow the request flow, from entry point to failure point:
- Step 2: confirm that the HTTP listener is active and receiving traffic on port 80. If the listener isn't operational, all subsequent steps are irrelevant.
- Step 3: identify which routing rule is associated with this listener. Without knowing which rule is active, it's impossible to know which redirect configuration is being applied.
- Step 5: inspect the associated redirect rule configuration. This is where you verify the type, destination, and rule options.
- Step 1: check the Include path option. This is the step that directly addresses the reported symptom (loss of the
/dashboardpath). - Step 4: verify the HTTPS certificate. Although relevant to the gateway's overall health, certificate validity doesn't affect path preservation in redirects and is the lowest priority step in this specific diagnosis.
- Alternative A starts with the certificate, which is the least relevant detail for the described symptom.
- Alternative C starts with step 1 without first confirming which rule is active, which would be diagnosing the solution before confirming the context.
- Alternative D changes the order of rule identification before confirming the listener is functional, skipping the flow foundation.
Troubleshooting Tree: Implement rules, URL rewrite, and URL redirect
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Orange | Intermediate checkpoint |
| Red | Identified cause |
| Green | Recommended action or resolution |
To use this tree when facing a real problem, start at the root node by identifying whether the unexpected behavior is in the redirect or rewrite layer. Follow the closed questions by answering yes or no based on what you directly observe in the configuration or gateway logs. Each red path indicates a concrete cause that can be fixed; the green validation node signals that the configuration is structurally correct and the problem requires deeper investigation via logs and request testing.