DBS-C01 Workload-Specific Database Design Practice Questions

Explanation: Amazon Aurora Global Database is designed for global applications requiring high availability and low-latency reads across multiple AWS Regions. While it uses eventual consistency for reads from secondary regions, it provides strong consistency within the primary region, which is the only region where writes are accepted. For a global e-commerce application that demands strong consistency, the best practice is to route all writes to the primary region and use the primary endpoint for strongly consistent reads. Although cross-region reads are eventually consistent, Aurora Global Database offers the best balance of low latency, high availability, and strong consistency for the primary region, making it the most suitable option among the choices. In contrast, Amazon DynamoDB global tables provide only eventual consistency across regions, Amazon ElastiCache is a cache (not a primary database), and Amazon Neptune is a graph database not optimized for e-commerce workloads.

Explanation: Strongly consistent reads guarantee that the leaderboard query always returns the most up-to-date scores, which is critical for a competitive gaming leaderboard where accuracy is paramount. Option C is correct because a Global Secondary Index (GSI) with score as the sort key allows efficient range queries to retrieve top players without scanning the entire table. Option D is correct because DynamoDB Streams can be used to update a materialized leaderboard table, enabling efficient queries on pre-computed rankings. Options A and E are incorrect: scanning the entire table is inefficient and a single partition key creates a hot partition and prevents efficient sorted queries.

Explanation: Amazon DocumentDB fully supports secondary indexes, similar to MongoDB. However, for reporting workloads that frequently query the same fields, covered queries (which retrieve all required data from the index without accessing the underlying documents) can provide significant performance benefits by reducing I/O and eliminating document lookups. This can lower index maintenance overhead and storage costs, making it a valuable design consideration when heavy reliance on secondary indexes is expected. The key is to design indexes that support covered queries for the most common reporting queries, rather than assuming secondary indexes alone will suffice.

Explanation: Creating a local secondary index (LSI) on user_id (same partition key) and post_timestamp as the sort key allows you to run a Query operation on the index with a limit of 5 items, sorted in descending order, to efficiently retrieve the most recent posts for a user. This targeted read reduces consumed read capacity units compared to scanning the base table, lowering cost. LSI also supports strongly consistent reads if needed. Option A (DAX) adds cost without reducing RCU for infrequent queries. Option B (increasing RCU) increases cost without improving efficiency. Option C (GSI on post_timestamp) cannot efficiently scope to a single user, leading to full scans and higher cost.

Explanation: DynamoDB Time to Live (TTL) automatically expires and deletes old sensor data. By removing obsolete items, the table size is reduced, leading to faster queries (less data to scan) and lower storage costs. Additionally, fewer read capacity units are consumed because queries process fewer items. This pattern both improves query performance and reduces cost for time-series data where queries focus on recent date ranges.