Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in caching behavior of API Gateway custom authorizers and how that impacts attribute propagation during user authentication. In production, this is about knowing exactly when new federated user attributes become visible to your Lambda authorizer versus being served from cached tokens. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
A fintech startup is developing a mobile trading application that uses Amazon API Gateway to expose its backend services. User authentication is handled via Amazon Cognito User Pools, federated through a third-party OAuth provider. The startup’s security model restricts app features to users belonging to specific departments. To enforce this, a user attribute named Dept is mapped from the IdP to Cognito and then passed to a custom Lambda authorizer, which evaluates the attribute to allow or deny access.
The lead developer tests the system by changing their department attribute in the IdP from analytics to trading but notices that the application still denies access as if the attribute were unchanged. Logs indicate that the access token passed to the Lambda authorizer still contains Dept: analytics.
The Requirement: #
Identify the most likely reason the Lambda authorizer continues to receive stale department information even after the IdP attribute was updated.
The Options #
- A) Authorization caching is enabled in the custom Lambda authorizer.
- B) Authorization caching is enabled on the Amazon Cognito user pool.
- C) The IAM role for the custom Lambda authorizer does not have a Department tag.
- D) The IAM role for the Amazon Cognito user pool does not have a Department tag.
Google adsense #
leave a comment:
Correct Answer #
A) Authorization caching is enabled in the custom Lambda authorizer.
Quick Insight: The DVA Imperative #
Custom Lambda authorizers by default cache policy decisions (including custom claims) for a configurable TTL. If the department attribute changes upstream in your IdP or Cognito but the authorizer cache remains active, your Lambda authorizer will continue to see and enforce access control based on the old attribute value until the cache expires.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option A
The Winning Logic #
Authorization caching in API Gateway’s custom Lambda authorizers is a common cause of outdated authorization information. When enabled, the Lambda authorizer’s response—which contains policy decisions based on user attributes like department—is cached for a specified TTL (Time to Live). Any subsequent requests within that TTL bypass re-invocation of the authorizer, resulting in the stale attribute value being applied, even if the upstream IdP or Cognito User Pool has updated the user attributes.
- The developer changed the
Deptattribute in the IdP and triggered a new login, but the cached authorizer policy is still being used. - The access token itself (issued by Cognito) contains the old attribute, meaning the authorizer sees stale claims.
- To see the updated attribute, the authorizer cache must be disabled or the cached entries invalidated.
The Trap (Distractor Analysis) #
- B: Authorization caching on Cognito user pool — Cognito User Pools do not cache the authorization decisions in the same manner. While Cognito does cache tokens and handle attribute mappings, this caching does not affect the attribute claims once a new access token is issued. Since the logs show the token still has the old attribute, the problem lies downstream.
- C & D: IAM role missing Department tag — IAM roles do not get tagged with user attributes such as department for authorization to work, especially in this context of Lambda authorizers. This is a misunderstanding of IAM’s role here and irrelevant to the symptom.
The Technical Blueprint #
# To disable or reduce caching on the custom Lambda authorizer via AWS CLI:
aws apigateway update-authorizer \
--region us-east-1 \
--rest-api-id a1b2c3d4 \
--authorizer-id x5y6z7 \
--patch-operations op=replace,path=/authorizerResultTtlInSeconds,value=0
# Setting TTL to 0 disables caching entirely, forcing Lambda invocations per request,
# ensuring fresh attributes from Cognito/OAuth provider on each API call.
The Comparative Analysis (Mandatory for Associate/Pro/Specialty) #
| Option | API Behavior Impact | Performance Impact | Use Case |
|---|---|---|---|
| A) | Prevents stale attribute caching | Slightly higher latency due to Lambda calls | Recommended for dynamic attributes or frequent changes |
| B) | No direct caching impacts on tokens | Minimal | Not relevant in this scenario |
| C) | No effect on attribute propagation | None | IAM role tags unrelated here |
| D) | No effect on attribute propagation | None | IAM role tags unrelated here |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For API Gateway custom Lambda authorizers, always consider the authorizationResult TTL cache when debugging stale policy results.”
Real World #
“In production environments, to optimize Lambda invocation costs and latency, we often enable a low but non-zero TTL. During development or rapid attribute changes, temporarily disabling caching prevents confusing stale authorization decisions.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.