Day 5 - Week 4 Review: Sharpening Real Exam Instincts with Comprehensive API Gateway Scenarios

A startup provides an API to external partners. Partner A must be limited to 100,000 calls per month and Partner B to 500,000 per month. Also, Partner B needs a rate limit of 100 requests/second and Partner A 20 requests/second. What is the most appropriate configuration?

• ACreate a separate REST API and stage per partner and set rate/burst throttling on each stage — differentiated rates work, but it can't provide a monthly quota, and the API is duplicated per partner, driving up operational complexity
• BCreate a Usage Plan per partner and issue an API key to each partner, linking it to the appropriate plan
• CVerify the partner ID in a Lambda Authorizer and atomically record the call count in a DynamoDB counter to implement monthly/per-second limits yourself — it works but the atomicity of a distributed counter is costly and reinvents a managed feature
• DLimit the request count per partner IP with an aws:SourceIp condition in an API Gateway resource policy — a resource policy is only allow/deny access control and has no rate limit/quota functionality

A company's REST API Lambda function depends on an external payment service. In CloudWatch, 5XXError is increasing, Latency is close to 29 seconds, and IntegrationLatency is also close to 29 seconds. What is the most likely cause?

• AThe Lambda Authorizer is slow, so time is being spent in the auth stage — but then Latency should be larger than IntegrationLatency, whereas here the two are nearly equal, so the bottleneck is the backend
• BThe Lambda function is hitting the API Gateway integration timeout (29 seconds) before responding
• CThe client is exceeding limits and 429 throttling is occurring — if it were throttling, 4XXError would increase, not 5XX, and Latency wouldn't pin to 29 seconds
• DA CloudWatch Logs misconfiguration is inflating the recorded Latency/IntegrationLatency metrics above their real values — a pattern where both metrics consistently converge on 29 seconds is a classic signal of a real backend timeout

A dev team implemented a DynamoDB direct integration (VTL) on a REST API. API Gateway calls DynamoDB GetItem and returns the response to the client. The client developer complained that the response comes in the format {"Item": {"name": {"S": "Hong Gildong"}, "age": {"N": "30"}}}. How do you fix this?

• AAdd a Lambda function behind the integration to parse the DynamoDB response and return clean JSON — it works, but it throws away the core benefit of the Lambda-free direct integration (eliminating cost and cold starts)
• BForce all attribute types of the DynamoDB table to string (S) to remove the type wrappers from the response — DynamoDB always includes a per-item type wrapper, so it can't be removed via table configuration
• CWrite a VTL mapping template in the Integration Response to transform the DynamoDB response into clean JSON
• DMigrating the REST API to HTTP API automatically strips the type wrappers in DynamoDB direct integration — HTTP API doesn't support VTL or direct AWS service integration, so this scenario itself is impossible

A mobile app queries data through an API Gateway REST API. It authenticates with a Cognito User Pool. You want to reduce Lambda calls when the same user repeatedly queries the same data. You enabled response caching, but a problem arose where all users share the same cached value. What is the cause and solution?

• ASince caching doesn't automatically include the Cognito token in the cache key, add the Authorization header to the cache key
• BAPI Gateway caching doesn't support per-user separation, so turn off the cache and implement per-user caching inside Lambda yourself — adding the header to the cache key achieves separation, so self-implementation is unnecessary
• CSwitching from the Cognito Authorizer to a Lambda Authorizer automatically separates the cache by principalId — the authorizer type and the response cache key are unrelated, so it won't separate automatically
• DSwitching the REST API to HTTP API applies per-token caching by default — HTTP API doesn't support response caching at all, so it can't be a solution

You're building a real-time stock trading alert system. When a trader connects from a web browser, the server must push price changes immediately. The trader has no need to send messages to the server. What is the most suitable architecture?

• AConfigure a bidirectional channel with WebSocket API + DynamoDB connection registry + Lambda broadcast — it works, but for one-way push it adds unnecessary complexity and cost in the form of a connection registry and broadcast logic
• BHave the client poll the REST API every 5 seconds to fetch the latest price — immediacy is poor and a call occurs every time even for empty responses, which is inefficient
• CLambda Response Streaming + Function URL (SSE pattern)
• DDeliver events with SNS + SQS + Lambda + REST API long polling — too many components, overly complex, and unsuitable for real-time push to a browser

A company wants to configure WAF on a REST API to block SQL injection. However, some legitimate requests are also being blocked. The team wants to analyze the pattern of blocked requests and fine-tune the WAF rules. Which WAF setting should they enable?

• AEnable WAF Sampled Requests to view a sample of matched requests in the console — it shows only some samples and helps analysis, but it doesn't stop blocking, so legitimate requests keep getting blocked
• BRaise API Gateway Execution Logs to INFO level to log blocked requests in detail — execution logs are only the API GW processing history and don't show the cause of a WAF rule match
• CEnable X-Ray tracing to analyze per-request-path latency and the blocking point — X-Ray is a performance tracing tool and doesn't provide data usable for WAF rule tuning
• DSwitch the WAF Web ACL to count mode and enable CloudWatch Logs

A startup wants to deploy a Next.js backend API to AWS. Each API path is split into a separate Lambda, and the requirements are: (1) low cost, (2) Cognito-based JWT authentication, (3) automatic CORS setup, (4) a custom domain. Which API type is most suitable?

• AREST API (Cognito User Pool Authorizer + manual CORS + us-east-1 ACM custom domain) — it meets the requirements but per-call cost is about 3.5x higher and CORS must be configured manually, which is unfavorable for the cost and automation requirements
• BHTTP API (JWT Authorizer + automatic CORS setup + custom domain)
• CFunction URL (automatic CORS + IAM auth) to expose each Lambda directly — only one URL per function is possible, so it can't provide multi-path routing or a unified custom domain
• DHandle requests by maintaining a persistent connection with the client via WebSocket API — a bidirectional protocol unsuitable for a request-response REST backend, and it doesn't support JWT Authorizer or automatic CORS

There's an API using a Lambda Authorizer (TOKEN type, TTL 300 seconds). The security team requests that a specific user's JWT token be invalidated immediately. The token has not yet expired. What is the fastest way?

• ADisable that user's account in Cognito to invalidate the token — it blocks issuing new tokens, but the already-cached Authorizer Allow policy remains valid for the TTL duration, so it's not blocked immediately
• BAdd that token to a blacklist in the Lambda Authorizer function code, and temporarily change the Authorizer TTL to 0
• CWait until the Authorizer cache TTL of 300 seconds expires and let it be invalidated naturally — this doesn't meet the immediate-invalidation requirement and access is allowed in the meantime
• DRedeploy the API Gateway stage to forcibly clear the Authorizer cache — redeploying doesn't clear the Authorizer result cache, so the cached token keeps passing

In a WebSocket API-based real-time chat, you must broadcast a message only to users in a specific chat room. There's a connection registry in DynamoDB. What is the most efficient DynamoDB lookup method?

• ARead the entire table with Scan + FilterExpression and then filter to only that chat room's connections — Scan reads all items, so RCU and latency grow linearly with the number of connections, making it inefficient
• BSet the chat room ID as a GSI Partition Key and use Query to look up only that chat room's connections
• CCreate a separate DynamoDB table per chat room and store connections separately — the number of tables grows with the number of chat rooms, imposing management/limit burdens and being unsuitable for dynamic chat room creation
• DKeep a chat-room-to-connection mapping in ElastiCache Redis and look it up — it's fast, but it requires additional infrastructure/cost/operations in the form of an ElastiCache cluster, which is excessive for this requirement

A team uses API Gateway HTTP API with Lambda integration. The existing Lambda code was code that worked on REST API, reading the client IP with event["requestContext"]["identity"]["sourceIp"]. After switching to HTTP API, an error occurs in that code. What is the root cause and solution?

• AHTTP API doesn't provide the client IP as an event, so you must keep the REST API — HTTP API does provide the IP; only its location changed, so there's no reason to abandon the switch
• BIn HTTP API Payload v2.0, the IP is at event["requestContext"]["http"]["sourceIp"]. Modify the code or set payloadFormatVersion to "1.0"
• CThe Lambda execution role is missing execute-api-related permissions, so access to the IP field is being denied — IAM permissions are unrelated to the availability of event payload fields, so this isn't the cause
• DYou must parse the X-Forwarded-For header directly instead of sourceIp and extract the first IP — it's possible, but v2.0 provides sourceIp, so header parsing is an unnecessary workaround