These questions cover Aurora, DynamoDB, and RDS connection management, areas that appear heavily in DBS-C01 and where the exam tests understanding of how each feature actually works, not just what it's called.
Question 1
An e-commerce application needs a database that remains writable during a regional AWS outage with a recovery time of under 1 minute. Which solution meets this requirement?
- A) RDS MySQL with Multi-AZ enabled in a single region
- B) Aurora MySQL with a read replica in a second region
- C) Aurora Global Database with write forwarding enabled on the secondary region
- D) RDS MySQL with automated cross-region snapshots
Answer: C — Aurora Global Database with write forwarding
Aurora Global Database replicates across up to 5 regions with typical lag under 1 second. In a regional failure, the secondary region can be promoted to primary (new writer) in under 1 minute, meeting the RTO requirement.
Comparing the options:
| Option | Scope | RTO on region failure |
|---|---|---|
| RDS Multi-AZ | Single region (AZ failover) | ~1-2 minutes, but stays in same region |
| Aurora read replica (cross-region) | Cross-region, read-only replica | Promotion is manual, minutes |
| Aurora Global Database | Cross-region, managed failover | Under 1 minute |
| Cross-region snapshots | Disaster recovery only | Hours |
RDS Multi-AZ provides AZ-level failover within a region. It doesn't survive a full regional outage. A standard Aurora cross-region read replica requires manual promotion, which takes longer than the <1 minute requirement.
</details>Question 2
A DynamoDB table stores user session data. The application uses a userId as the partition key and frequently queries all sessions for a specific applicationId. Queries are slow and consuming large amounts of read capacity. What is the most cost-effective fix?
- A) Increase the provisioned RCU on the main table
- B) Add a Global Secondary Index (GSI) with
applicationIdas the partition key - C) Switch to DynamoDB Streams and aggregate sessions in a Lambda function
- D) Scan the entire table and filter by
applicationIdin application code
Answer: B — Add a GSI with applicationId as the partition key
DynamoDB queries are efficient only when they target a partition key. Querying by applicationId on a table partitioned by userId requires a full table scan: scanning every partition, reading every item, then filtering. This consumes RCU proportional to the total table size, not the result size.
A Global Secondary Index (GSI) with applicationId as the partition key creates a separate, sparse index that DynamoDB maintains automatically. Queries against the GSI target only the relevant partition. RCU consumption matches the result set size.
When to use each index type:
| Index type | Key structure | Use case |
|---|---|---|
| GSI | Different partition key (and optional sort key) | Query on non-primary attributes |
| LSI | Same partition key, different sort key | Sort/filter within a partition |
Increasing RCU makes scans faster but doesn't reduce the cost per query: you're paying for more capacity to burn through the same wasteful scan pattern.
</details>Question 3
An RDS MySQL database is running out of connections during traffic spikes. The application uses a serverless architecture with Lambda functions. Increasing max_connections causes memory pressure. What is the best architectural solution?
- A) Increase the Lambda concurrency limit to reduce the number of simultaneous functions
- B) Deploy RDS Proxy between the Lambda functions and the RDS instance
- C) Switch to connection pooling inside each Lambda function using a persistent library
- D) Migrate to a larger RDS instance class to increase the connection limit
Answer: B — RDS Proxy
Lambda functions each open their own database connection, which is a problem because:
- Each function invocation is a new process with no connection reuse
- At scale, hundreds of Lambda instances can exhaust RDS
max_connectionssimultaneously - Connection setup adds latency to every cold invocation
RDS Proxy sits between Lambda and RDS, maintaining a warm pool of database connections and multiplexing Lambda requests across them. Lambda functions connect to the Proxy endpoint rather than directly to RDS.
| Without RDS Proxy | With RDS Proxy |
|---|---|
| N Lambda functions = N DB connections | N Lambda functions share pooled connections |
| Connection exhaustion at scale | Proxy queues requests above pool limit |
| Full TCP handshake + auth per Lambda | Proxy reuses persistent connections |
Connection pooling inside Lambda is unreliable because Lambda execution environments are recycled unpredictably. The pool doesn't persist reliably between invocations. Increasing instance size raises the ceiling but doesn't solve the architectural problem.
</details>Key Takeaways
- Aurora Global Database = cross-region failover under 1 minute; RDS Multi-AZ is single-region AZ failover only
- Querying non-primary-key attributes in DynamoDB needs a GSI: scanning is expensive and scales with total table size
- RDS Proxy pools connections for Lambda; without it, each Lambda invocation creates a new database connection