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