Examkin

Question

Difficulty: Very hardDefine API Management Policies

An organization uses Azure API Management (APIM) to secure and manage a legacy backend REST API. You are tasked with configuring a policy definition at the API level to meet the following operational and security requirements:
1. Rate-limit incoming calls to a maximum of 100 requests per minute based on the client IP address.
2. Validate that the incoming request contains a valid JSON Web Token (JWT) issued by a trusted identity provider before any backend communication occurs.
3. Cache HTTP GET responses for 60 seconds to reduce the load on the legacy backend.
4. Strip the 'Server' header from all backend responses before they are returned to client applications.

Which XML policy configuration correctly implements these requirements while preventing unauthorized clients from bypassing token validation on cache hits?

  1. <policies>
    <inbound>
    <base />
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Request.IpAddress)" />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
    <openid-config url="https://login.microsoftonline.com/common/.well-known/openid-configuration" />
    </validate-jwt>
    <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" />
    </inbound>
    <backend>
    <base />
    </backend>
    <outbound>
    <base />
    <cache-store duration="60" />
    <set-header name="Server" exists-action="delete" />
    </outbound>
    <on-error>
    <base />
    </on-error>
    </policies>    Answer
  2. B
    <policies>
    <inbound>
    <base />
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Request.IpAddress)" />
    <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" />
    <cache-store duration="60" />
    </inbound>
    <backend>
    <base />
    </backend>
    <outbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
    <openid-config url="https://login.microsoftonline.com/common/.well-known/openid-configuration" />
    </validate-jwt>
    <set-header name="Server" exists-action="delete" />
    </outbound>
    <on-error>
    <base />
    </on-error>
    </policies>
  3. C
    <policies>
    <inbound>
    <base />
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Request.IpAddress)" />
    <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
    <openid-config url="https://login.microsoftonline.com/common/.well-known/openid-configuration" />
    </validate-jwt>
    </inbound>
    <backend>
    <base />
    </backend>
    <outbound>
    <base />
    <cache-store duration="60" />
    <set-header name="Server" exists-action="delete" />
    </outbound>
    <on-error>
    <base />
    </on-error>
    </policies>
  4. D
    <policies>
    <inbound>
    <base />
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Request.IpAddress)" />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
    <openid-config url="https://login.microsoftonline.com/common/.well-known/openid-configuration" />
    </validate-jwt>
    <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" />
    <set-header name="Server" exists-action="delete" />
    </inbound>
    <backend>
    <base />
    <cache-store duration="60" />
    </backend>
    <outbound>
    <base />
    </outbound>
    <on-error>
    <base />
    </on-error>
    </policies>

Answer

The configuration that places the rate-limit-by-key, validate-jwt, and cache-lookup policies in the inbound section (in that order), and the cache-store and set-header (delete Server) policies in the outbound section is the only correct and secure solution.
The correct configuration establishes a secure and logical processing flow. In the inbound section, the rate limit check runs first to mitigate denial-of-service attempts. Next, validate-jwt verifies the client's token, ensuring that only authenticated users proceed. Only after successful token verification is cache-lookup executed, which protects the cached data. In the outbound section, cache-store saves the valid backend response, and set-header successfully deletes the 'Server' header from the outbound HTTP response.

Step-by-Step Solution

1
Determine the proper section for JWT validation.
JWT validation must occur in the inbound section to authenticate the client before routing the request or serving data.
Placing authentication checks like validate-jwt in the inbound section secures the API endpoints and blocks unauthorized traffic early.
2
Determine the correct ordering of validate-jwt relative to cache-lookup.
The validate-jwt policy must precede the cache-lookup policy.
If cache-lookup is placed before validate-jwt, a cache hit will bypass the token validation entirely, resulting in a security vulnerability where unauthenticated clients can read cached responses.
3
Determine the proper sections for caching policies.
The cache-lookup policy must be in the inbound section, and the cache-store policy must be in the outbound section.
API Management checks the cache during the inbound processing phase and saves the generated response to the cache during the outbound phase.
4
Determine the proper section for response header modification.
The set-header policy designed to delete the Server header must reside in the outbound section.
Since the Server header is generated by the backend service, it can only be removed from the response headers during the outbound processing phase.

Key Concept

Azure API Management policy evaluation order, caching logic, and authentication sequencing.
Rate this question

Topics

Define API Management Policies

More questions from this topic