Exam AZ-204 topic 4 question 26 discussion

Inbound Inbound Inbound Outbound

The answer provided is correct.

the discussion on whether the 3rd option is inbound or outbound is valid since the cache-store-value can be used in both sections. In this case we don't want to store the result but rather which user the request is from without JWT parsing again. This saves computational effort

Answer should be Inbound, Inbound, Inbound, Outbound.

Set-Variable Policy Purpose: To store the detected user identity, which is likely extracted from the JWT token. Placement: Inbound. You need to extract and store the user ID as the request comes in, before any caching logic is applied. Cache-Lookup-Value Policy Purpose: To check if there's a cached response available for the specific user ID. Placement: Inbound. This should happen early in the request processing to determine if a cached response can be used instead of forwarding the request to the backend. Cache-Store-Value Policy Purpose: To store the response in the cache associated with the specific user ID. Placement: Outbound. After the backend service generates a response, this policy stores it in the cache before sending it to the client. Find-and-Replace Policy Purpose: To update the response body with the user profile information. Placement: Outbound. This modification should be done after the backend service has generated the response and just before it's sent back to the client.

The cache-store-value policy in Azure API Management (APIM) is used in the inbound policy section. This policy is typically applied before the request reaches the backend service, allowing you to cache the response based on the specified conditions or keys. In the context of caching, the inbound policy section refers to policies that are executed before the request is sent to the backend, and the outbound policy section refers to policies that are executed before the response is sent back to the client. So, when you use cache-store-value to cache a response, you want to do this on the inbound side, ensuring that the caching occurs before the request is forwarded to the backend service.

Inbound Inbound Inbound Outbound https://learn.microsoft.com/en-us/azure/api-management/api-management-sample-cache-by-key#fragment-caching

Inbound Inbound Outbound Outbound Reference: https://learn.microsoft.com/en-us/azure/api-management/api-management-sample-cache-by-key#architecture

Got this on 6/28/2023 and passed with 850. Went with highly voted answer.

>> The caching mechanism must detect the user ID of the client that accesses data for a given location and *cache the response for that user ID.* Thus cache store should be outbound guys

Given answers are correct. Inbound Inbound outbound->in general the response come in oubound section outbound https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-cache

Here is Answer:https://learn.microsoft.com/en-us/azure/api-management/api-management-sample-cache-by-key#architecture inbound, inbound, inbound outbound

Got it in exam 20/10/2022

see the xml tag of inbound and outbound https://docs.microsoft.com/en-us/azure/api-management/api-management-sample-cache-by-key

<policies> <inbound> <base /> <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" > <vary-by-query-parameter>version</vary-by-query-parameter> </cache-lookup> </inbound> <outbound> <cache-store duration="seconds" /> <base /> </outbound> </policies>

I think it's B, because of this: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Integrated-Windows-Authentication Federated users only, i.e. those created in an Active Directory and backed by Azure Active Directory. Users created directly in AAD, without AD backing - managed users - cannot use this auth flow. This limitation does not affect the Username/Password flow.

Inbound Inbound Inbound Outbound