AWS DVA-C02: Development with AWS Services Practice Questions

DAX is a fully managed, DynamoDB-compatible in-memory cache that sits transparently between the application and DynamoDB. Switching from the standard DynamoDB SDK client to the DAX client is a minimal code change, and DAX automatically caches reads with a configurable TTL. When the TTL expires, DAX fetches fresh data from DynamoDB, providing automatic invalidation. ElastiCache for Redis requires the developer to write explicit cache-check, cache-populate, and TTL management logic, representing significantly more code changes, and it also requires VPC configuration for Lambda. CloudFront cannot directly query DynamoDB; it caches HTTP responses from origins and is not applicable here. AWS AppSync is a GraphQL API service and is not designed to cache DynamoDB reads invoked directly by a Lambda function.

The FlushStageCache API action (available via the AWS SDK or CLI as flush-stage-cache) immediately invalidates all cached responses for a given API Gateway stage. Calling this at the end of the catalog update pipeline ensures users receive fresh results right away. Reducing the TTL to 60 seconds would improve freshness slightly but does not solve the problem: updates could still be stale for up to 60 seconds and the average hit rate drops significantly, increasing Lambda invocation costs. Redeploying the stage with CreateDeployment does not flush the response cache; it creates a new deployment snapshot but cache entries persist. Per-key cache invalidation via Cache-Control: max-age=0 allows individual clients to bypass cache, but the backend pipeline cannot realistically issue a request on behalf of all users, and this approach requires the caller to have the execute-api:InvalidateCache permission — it is a client-side bypass, not a server-side flush.

Provisioned Concurrency pre-initialises execution environments so there is no cold start at all for the provisioned instances; this is the most direct solution. Reducing the container image size directly reduces the time Lambda spends pulling and extracting the image during a cold start, which is the dominant factor for large container-based functions. — Increasing memory allocation speeds up CPU-bound initialisation code slightly but does not significantly reduce image-pull time; the main bottleneck for a 3 GB image is I/O, not CPU. — The image should already be in the same region; this is a prerequisite, not an optimization. — Switching languages reduces handler init time but does not address the 3 GB image pull, which is the primary cold start driver for container images. — Lambda SnapStart is currently only available for Java runtimes (on supported Java versions), not for container image deployments.

API Gateway WebSocket APIs support persistent, bidirectional connections and are well-suited for server-push scenarios. The server can push updates to connected clients at any time via the @connections callback URL. This is natively supported, simple to configure, and cost-effective at scale. — HTTP API with SSE is conceptually valid but Lambda has a maximum execution timeout of 15 minutes, making truly long-lived SSE connections impractical without a workaround. — AppSync subscriptions backed by IoT add unnecessary complexity and cost for a simple server-push use case. — Polling every second is neither push-based nor cost-effective; it generates high request volume and adds latency.

Using device_id as the partition key co-locates all readings for a device on the same partition, and using timestamp as the sort key enables efficient range queries (e.g., between two timestamps) sorted in order — exactly matching the access pattern. Using a UUID as the partition key with no sort key prevents range queries and scatters items randomly. Using timestamp as the partition key causes hot-partition issues because many writes occur at the same second, and range queries by device become full scans. Using sensor_type as the partition key mixes readings from many devices, making device-specific queries very inefficient.