Technical Lab: Implement rules, URL rewrite, and URL redirect
Questionsβ
Question 1 β Multiple Choiceβ
A platform team needs to configure Azure Application Gateway to route requests with the path /api/v1/users to a different backend pool than the default, without changing the path sent to the destination server. Which Application Gateway component should be created to meet this requirement?
A) A path-based routing rule associated with a path map
B) A rewrite rule with URL path matching condition
C) An additional listener with HTTPS protocol pointing to the new backend pool
D) A redirect rule with Permanent type to the new pool
Question 2 β Technical Scenarioβ
An engineer configures Azure Front Door to rewrite URLs before forwarding requests to the backend. The applied configuration is as follows:
Source pattern: /loja/
Destination: /store/
Preserve unmatched path: true
A request arrives with the path /loja/produtos/eletronicos. What will be the path sent to the backend?
A) /loja/produtos/eletronicos
B) /store/
C) /store/produtos/eletronicos
D) /store/loja/produtos/eletronicos
Question 3 β True or Falseβ
In Azure Application Gateway, a redirect rule configured with Permanent (301) type and external destination can coexist in the same routing rule with a header rewrite action, with both being applied sequentially to the same request.
Question 4 β Technical Scenarioβ
A company migrated its site from http://contoso.com to https://contoso.com. The networking team configured Azure Application Gateway to force HTTP to HTTPS redirection. After configuration, users report that when accessing http://contoso.com/artigos/2024 they arrive at https://contoso.com without the original path. What was likely configured incorrectly?
A) The redirect type was set to Found (302) instead of Permanent (301)
B) The Include path option was not enabled in the redirect configuration
C) The target listener was configured as Multi-site instead of Basic
D) The redirect rule was associated with a path map instead of the main routing rule
Question 5 β Multiple Choiceβ
When configuring rewrite rules in Azure Application Gateway, which of the following statements correctly describes the scope of application for these rules?
A) Rewrite rules are applied globally to all gateway listeners, regardless of routing rule
B) Rewrite rules are associated with a rewrite rule set, which is linked to one or more routing rules
C) Rewrite rules can only be applied to backend responses, not to incoming requests
D) Rewrite rules are configured at the backend pool level and only affect traffic directed to it
Answer Key and Explanationsβ
Answer Key β Question 1β
Answer: A
Path-based routing uses a path map to associate URL patterns with specific backend pools. This mechanism routes the request to the correct pool without modifying the path, which is the behavior required in the statement.
- Alternative B (rewrite rule) would modify the path before forwarding, which contradicts the requirement.
- Alternative C (additional listener) resolves routing by port or hostname, not by path.
- Alternative D (redirect rule) would send a redirect response to the client, not internally forward to the backend.
The common mistake is confusing "forward to different backend" with "rewrite URL", where the first is the responsibility of routing rules and the second is a request transformation.
Answer Key β Question 2β
Answer: C
When Preserve unmatched path is enabled in Azure Front Door, the URL segment that is not part of the matched pattern (/produtos/eletronicos) is preserved and concatenated to the configured destination (/store/). The result is /store/produtos/eletronicos.
- Alternative A would completely ignore the rewrite.
- Alternative B would apply only the destination without preserving the rest of the path, which would occur if
Preserve unmatched pathwas disabled. - Alternative D would duplicate the prefix, which is not the feature's behavior.
Understanding the role of Preserve unmatched path is essential for partial URL rewrites, especially in migrations where only the path prefix changes.
Answer Key β Question 3β
Answer: False
In Azure Application Gateway, a routing rule cannot simultaneously contain a redirect action and a rewrite action. Redirection terminates request processing at the gateway and returns a response to the client (301 or 302). Since the request never reaches the backend, there is no response cycle on which to apply header rewrites.
Rewrite rules operate on requests forwarded to the backend or on responses returned by it. Mixing redirection with rewriting in the same rule represents a functional contradiction, and Application Gateway does not allow this combination.
Answer Key β Question 4β
Answer: B
The Include path option controls whether the original URL path is preserved during redirection. When disabled, only the destination hostname is used, discarding the path. Therefore, /artigos/2024 is lost and the user arrives at the root of the HTTPS site.
- Alternative A (302 vs 301 type) only affects cache semantics in the browser, not path preservation.
- Alternative C (listener type) has no relation to path preservation behavior in redirection.
- Alternative D describes a valid configuration scenario, not an error that would cause path loss.
In addition to Include path, there is also the Include query string option, which should be evaluated separately to preserve URL parameters.
Answer Key β Question 5β
Answer: B
Rewrite rules in Application Gateway are grouped into a rewrite rule set, which is explicitly linked to routing rules. This means the engineer has granular control: the same rewrite rule set can be reused across multiple rules, but it is never applied globally automatically.
- Alternative A describes global behavior that doesn't exist; linking is always explicit per routing rule.
- Alternative C is incorrect: rewrite rules can be applied to both incoming requests and backend responses (headers and body, as supported).
- Alternative D confuses scope; rewrite rules are not configured at the backend pool level, but at the gateway routing layer.
Understanding this linking model prevents configuration errors where one expects a rewrite to apply to all traffic, but it only triggers on routing rules to which the rule set was associated.