DVA-C02 Development with AWS Services Practice Question

A company is building a serverless application using AWS Lambda and Amazon DynamoDB. The Lambda function processes user uploads from Amazon S3 and stores metadata in DynamoDB. The function is experiencing high latency during peak hours. Which action would MOST improve the performance without increasing the function timeout?

⚠ Common exam trap

Test-takers frequently confuse read optimization (DAX) with write optimization, or assume that increasing concurrency or improving network connectivity will fix a throughput bottleneck, when the actual issue is insufficient DynamoDB write capacity.

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

✓

Increase the DynamoDB table's provisioned read and write capacity.

Increasing the DynamoDB table's provisioned read and write capacity directly addresses the root cause of high latency during peak hours: throttling due to insufficient throughput. When the Lambda function's write requests exceed the table's capacity, DynamoDB throttles them, causing retries and increased latency. Raising the capacity allows DynamoDB to handle the burst of metadata writes without throttling, reducing response times without requiring a longer function timeout.

Answer analysis

Option-by-option breakdown

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

✓
Increase the DynamoDB table's provisioned read and write capacity.
Why this is correct
Increasing the DynamoDB table's provisioned read and write capacity directly addresses performance bottlenecks caused by insufficient throughput. When a Lambda function attempts to write or read data faster than the table's allocated capacity, DynamoDB throttles these requests, resulting in `ProvisionedThroughputExceededException` errors and increased latency. By raising the provisioned capacity units, the table can handle a higher volume of operations per second, preventing throttling and ensuring consistent, low-latency data access for the serverless application.
✗
Increase the Lambda reserved concurrency.
Why it's wrong here
Increasing Lambda reserved concurrency allocates a dedicated pool of concurrent executions for a specific function, preventing it from being throttled by other functions consuming the account's unreserved concurrency limit. However, this setting does not improve the performance or reduce the latency of individual Lambda invocations, nor does it address performance issues originating from downstream services like DynamoDB throttling. It is a mechanism for ensuring the availability of Lambda function resources, not for optimizing the performance of its interactions with other AWS services.
✗
Move the Lambda function into a VPC with a DynamoDB VPC endpoint.
Why it's wrong here
Moving the Lambda function into a VPC with a DynamoDB VPC endpoint establishes a private network connection to DynamoDB, bypassing the public internet. While this can reduce network latency and enhance security by keeping traffic within the AWS network, it does not resolve throttling issues caused by insufficient provisioned capacity on the DynamoDB table itself. Furthermore, placing a Lambda function within a VPC can introduce additional cold start latency due to the time required to provision and attach an Elastic Network Interface (ENI) for each new execution environment.
✗
Enable DynamoDB Accelerator (DAX) for the table.
Why it's wrong here
Enabling DynamoDB Accelerator (DAX) for the table provides an in-memory caching layer specifically designed to accelerate *read-heavy* workloads, offering microsecond response times for frequently accessed data. Since the Lambda function is primarily *writing* metadata to DynamoDB, DAX would not offer any benefit in reducing write latency or preventing write throttling. DAX is not designed to cache or accelerate write operations, making it an ineffective solution for improving the performance of a write-intensive workload.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DVA-C02 Development with AWS Services Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question