Development with AWS Services: free practice questions

API Gateway WebSocket APIs maintain persistent, stateful connections between clients and the server. They support two-way communication: clients can send messages to the server (via custom routes) and the server can push messages to connected clients using the @connections management API. This directly satisfies both requirements. Option A REST API long polling is a workaround where clients repeatedly re-issue requests; it is not true real-time push and adds significant overhead. Option B HTTP API SSE supports server-to-client push only (one-way); the client cannot send messages over the SSE connection itself. Option D API Gateway caching stores responses to reduce backend load; it has no mechanism to push data to clients.

AWS Systems Manager Parameter Store is designed for centralised configuration management. Fetching parameters at function initialisation (outside the handler) and caching them in the global scope means each execution environment retrieves them only on a cold start. When values change, you can force fresh retrieval by deploying a new function version or using a short local TTL. This avoids duplication, is immediately updatable, and requires no redeployment. — Downloading from S3 works but adds latency and cost per cold start; Parameter Store is purpose-built for this and supports IAM-based access control more easily. — Lambda environment variables are set at deploy time and are per-function; they cannot be shared across functions without redeployment. — Embedding config in a Layer still requires redeploying all 50 functions when values change, which is the exact problem the developer wants to avoid.

Option A uses a UUID postId as the partition key of the base table, enabling O(1) GetItem lookups for access pattern 2. A GSI with authorId as partition key and timestamp as sort key directly supports access pattern 1—querying by author and sorting by time descending with no extra reads. Option B makes the base table's partition key authorId with sort key timestamp, which handles access pattern 1 natively, but retrieving a single post by postId requires a GSI on postId—however, a GSI on a non-key attribute only supports Query (with an equality filter on the partition key), not a direct GetItem, adding slight inefficiency compared to option A's base table GetItem. More critically in option B the GSI would have postId as its partition key but no sort key, meaning you'd get a single item per partition which is fine, but the base table choice of authorId+timestamp makes it hard to have a truly unique single-key lookup without the GSI. Option A is still cleaner overall. Option C uses a LSI (sort key: timestamp) on a base table keyed by authorId+postId; LSIs must share the same partition key as the base table, so you can query by authorId and sort by timestamp via the LSI—but you cannot do a direct single-item lookup by postId alone without knowing the authorId, making access pattern 2 incomplete. Option D uses Scan with FilterExpression to retrieve posts by author, which is extremely inefficient and costly on large tables and is an anti-pattern.

When a consumer receives a message, SQS hides it for the duration of the visibility timeout. If the consumer doesn't delete the message before the timeout expires, SQS makes it visible again and another consumer can receive it—causing duplicate processing. Because the payment API can take up to 8 minutes, the visibility timeout must exceed that (e.g., 10 minutes) so the original consumer has time to finish and delete the message. — Long polling (B) reduces empty receives and API calls but has no effect on visibility timeout or duplicate delivery. FIFO queues (C) offer exactly-once processing at the API level (deduplication ID), but if the visibility timeout is still too short the message will still reappear and be delivered again; the root cause here is the timeout, not ordering. Decreasing the retention period (D) would cause messages to be deleted before they're processed at all, resulting in lost orders rather than duplicates.

EventBridge invokes its targets synchronously (for synchronous targets) or asynchronously. When calling Step Functions StartExecution, the invocation rate is subject to the StartExecution API quota (which has per-region TPS limits). Under high load, throttling occurs. The correct resolution is to request a quota increase to match the workload and to configure a DLQ on the EventBridge target so that throttled events are not silently dropped—they can be replayed later. — EventBridge supports up to 5 targets per rule (not 10), and the test scenario only has one target, so this is not the issue. — Narrowing the event pattern reduces the volume of events but does not fix the root throttling problem; it is also an inappropriate business change to avoid a technical limit. — EventBridge natively supports Step Functions as a direct target without a Lambda intermediary.