Practice Test #5

Set-variable should be placed in the Inbound section because you need to derive and persist request-scoped data (the detected user identity) before any caching decision is made. Inbound is where APIM has access to the incoming request headers (including Authorization: Bearer <JWT>) and can parse JWT claims (for example, sub, oid, upn) to compute a stable user identifier. Storing the user ID in a variable during inbound allows subsequent inbound policies (like cache-lookup-value) to build a cache key such as "{location}:{userId}". If you waited until outbound, you would already have called the backend, defeating the purpose of using the cache to avoid backend calls. Outbound is primarily for response transformations and post-processing, not for request-derived routing/caching decisions.

Cache-lookup-value belongs in the Inbound section because the goal is to check the cache before forwarding the request to the backend. When cache-lookup-value finds an entry, APIM can immediately return the cached payload and skip the backend call, which is the main performance benefit of gateway caching. Placing cache lookup in outbound would be too late: the backend would already have been invoked, so you would not reduce backend load or latency. Inbound lookup also ensures the cache key can be constructed from request context (location parameter/path + user ID variable extracted from JWT). This is also important for security: per-user caching must be enforced before any response is generated to prevent mixing responses between users.

Cache-store-value should be placed in the Outbound section because you typically want to cache the response after the backend has produced it (and after any outbound transformations that should be reflected in the cached content). Outbound is the correct stage to capture the final response body/status/headers that will be returned to the client. If you stored in inbound, you would not yet have the backend response to cache. Also, caching after outbound modifications ensures consistency: the cached representation matches what clients receive (for example, after injecting user profile information or normalizing fields). This approach supports the Performance Efficiency pillar by reducing repeated backend calls for the same user/location combination.

Find-and-replace is a response body transformation policy, so it should be applied in the Outbound section. The requirement explicitly says to update the response body with the user profile information, which is only available/meaningful once a response exists. Inbound policies operate on the request before it is sent to the backend; they are not the right place to modify the response body. In outbound, APIM can read and rewrite the response payload (for example, replacing a placeholder token with user-specific profile data). Doing this in outbound also ensures that what you cache (via cache-store-value) can include the transformed content, so subsequent requests for the same user/location can be served entirely from cache without re-running backend logic.

Yes. Policies that inspect the incoming request (such as checking request body size) and policies that rewrite or normalize the request URL (such as retaining a particular API version segment) are applied before the request is sent to the backend. That is exactly what the <inbound> section is for. In APIM, <inbound> is the correct place for request validation, header/query/path manipulation, and routing decisions. By contrast, <outbound> is used to transform responses coming back from the backend, and <backend> is used to configure how APIM forwards the request (e.g., set-backend-service), not typically to validate request payload size. <on-error> only runs after an error has occurred. Therefore, an XML segment that evaluates request body size and/or rewrites the request path belongs in <inbound>.

No. A body size greater than 256 KB does not automatically cause an error unless the policy explicitly enforces that limit (for example, using validate-content with max-size, or a choose/when that returns an error response when the size exceeds a threshold). APIM does have practical limits and considerations when reading/buffering request bodies, but simply referencing a variable like "bodySize" (as implied by the snippet) does not itself throw an error at 256 KB. Errors occur when you attempt to read a body beyond configured limits, when buffering is required but not possible, or when a validation policy is configured to reject the request. For the exam, distinguish between (a) a computed value/variable and (b) an enforcement policy. Without an explicit reject/return-response/validate-content rule tied to 256 KB, exceeding 256 KB alone is not guaranteed to produce an error.

Yes. With a request like http://contoso.com/api/9.2/, a policy designed to compare versions and retain the higher version would keep 9.2 when compared against a lower version (for example, 9.1 or 9.0). This is a common APIM pattern: extract the version segment from the path, compare it to a configured/expected version, and rewrite/route accordingly. In APIM policy expressions, you must be careful about how versions are compared. If the policy uses numeric/semantic parsing (e.g., converting to a Version type or splitting into major/minor integers), then 9.2 correctly evaluates as higher than 9.1. If it used naive string comparison, results can be incorrect in some cases (e.g., "9.10" vs "9.2"). However, the statement specifically says the policy will retain the higher version for 9.2, which is consistent with the intended behavior of such a policy. Thus, given the scenario, the policy retains the higher version, and 9.2 would be kept.