SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company uses AWS Lambda functions behind an Amazon API Gateway REST API. The Lambda functions query an Amazon RDS for PostgreSQL database. Recently, the company has noticed increased latency and occasional timeouts during peak hours. A solutions architect needs to improve the performance and scalability of the database layer. Which solution will meet these requirements with the LEAST operational overhead?

⚠ Common exam trap

SAP-C02 often tests the misconception that read replicas or larger instances solve Lambda-to-RDS connection issues, when the core problem is connection pooling and the answer is RDS Proxy.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Implement Amazon RDS Proxy to manage connection pooling between Lambda and the RDS instance.

AWS Lambda functions can overwhelm an RDS database with too many concurrent connections, causing latency and timeouts. RDS Proxy pools and shares database connections, reducing the connection overhead and improving scalability without code changes. It requires minimal operational overhead because it is a managed service that integrates with IAM and Secrets Manager.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Enable Amazon DynamoDB Accelerator (DAX) on the RDS instance.
Why it's wrong here
DAX is an in-memory cache for DynamoDB and cannot attach to an RDS for PostgreSQL instance, so it addresses neither the query latency nor the connection pressure. It is tempting because caching frequently read data is a genuine scaling technique — but only for DynamoDB workloads, where DAX would be the right answer.
✗
Add a Multi-AZ RDS Read Replica and modify Lambda to use the Read Replica for queries.
Why it's wrong here
RDS Multi-AZ read replicas do not exist as a distinct feature; Multi-AZ is synchronous standby failover, and a read replica is a separate single-AZ instance. Amazon RDS Proxy pools and reuses connections, which is the low-overhead fix for Lambda connection exhaustion.
✗
Increase the instance size of the RDS database to handle more concurrent connections.
Why it's wrong here
Vertical scaling raises the ceiling on a single instance's CPU and memory but leaves the connection-count limit and read contention unchanged, so peak-hour timeouts persist. It is tempting because resizing is a familiar, low-effort fix, and it would be correct for a workload whose bottleneck is genuinely sustained compute on one node.
✓
Implement Amazon RDS Proxy to manage connection pooling between Lambda and the RDS instance.
Why this is correct
Lambda opens a new database connection per invocation, exhausting PostgreSQL's connection limit during peak load. RDS Proxy pools and reuses connections, absorbing bursts without application changes. This reduces latency and timeouts with minimal operational overhead, since AWS manages the proxy infrastructure.

Quick reference

Cloud Service Model Comparison

Model	You Manage	Provider Manages	Examples
IaaS	OS, runtime, apps, data	Hardware, hypervisor, networking	EC2, Azure VMs, GCP Compute Engine
PaaS	Apps and data	OS, runtime, middleware, hardware	Elastic Beanstalk, Azure App Service
SaaS	Data and settings only	Everything else	Microsoft 365, Salesforce, Workday
FaaS / Serverless	Function code only	Infra, scaling, runtime	Lambda, Azure Functions, Cloud Run
CaaS	Containers and apps	Kubernetes, OS, hardware	EKS, AKS, GKE

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Cloud Service Model Comparison

Related to this question