Courseiva

DVA-C02 Development with AWS Services Practice Question

A company runs a microservices architecture on Amazon ECS with Fargate. Each service uses an Application Load Balancer and stores data in Amazon DynamoDB. The operations team notices that during traffic spikes, some requests fail with HTTP 503 errors. CloudWatch metrics show that the ALB's TargetResponseTime is increasing, and the DynamoDB table's ConsumedWriteCapacityUnits are reaching the provisioned limit. The team wants to handle traffic spikes gracefully without manual intervention. What should they do?

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

✓

Enable DynamoDB Auto Scaling for write capacity and configure ECS Service Auto Scaling based on ALB request count.

DynamoDB Auto Scaling automatically adjusts the provisioned write capacity based on traffic, preventing throttling and 503 errors from write capacity exhaustion. ECS Service Auto Scaling adds more tasks when the ALB request count increases, distributing the load. Together, they handle traffic spikes without manual intervention. Option A is wrong because manually increasing provisioned capacity does not scale automatically, and deregistration delay does not address capacity issues. Option B is wrong because while SQS can buffer write requests, it adds complexity and latency; the question asks for graceful handling, and auto scaling addresses the root cause more directly. Option C is wrong because DAX is a cache for read operations, not write capacity.

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 write capacity and the ALB's target group deregistration delay.

    Why it's wrong here

    Manually increasing DynamoDB's provisioned write capacity is a static adjustment that does not dynamically respond to fluctuating traffic, leading to either over-provisioning and wasted costs or under-provisioning and continued throttling. Furthermore, adjusting the ALB's target group deregistration delay primarily affects connection draining during instance termination, not the ability of the ECS service or DynamoDB to handle increased write requests. This approach lacks the necessary automation for a microservices architecture experiencing variable load.

  • ✗

    Use an SQS queue to buffer write requests and process them asynchronously.

    Why it's wrong here

    While using an SQS queue effectively decouples the request producer from the consumer, improving resilience and preventing direct throttling *of the producer*, it does not inherently increase the DynamoDB table's *actual write capacity* to process the buffered items. The underlying throttling issue would simply shift from the API gateway/ECS service to the SQS consumer attempting to write to DynamoDB, potentially leading to a backlog in the queue and increased end-to-end latency for the write operations. This solution addresses resilience but not the core capacity problem.

  • ✗

    Add a DynamoDB Accelerator (DAX) cluster to cache frequently accessed data.

    Why it's wrong here

    DynamoDB Accelerator (DAX) is specifically designed to provide an in-memory cache for DynamoDB tables, significantly improving read performance by reducing latency for frequently accessed items. However, DAX does not enhance or scale the write capacity of the underlying DynamoDB table. Write operations still directly interact with DynamoDB, meaning a DAX cluster would have no impact on mitigating write throttling issues experienced during high-volume write traffic.

  • ✓

    Enable DynamoDB Auto Scaling for write capacity and configure ECS Service Auto Scaling based on ALB request count.

    Why this is correct

    Enabling DynamoDB Auto Scaling for write capacity allows the table to automatically adjust its provisioned throughput based on actual utilization and defined target metrics, preventing throttling during peak loads and scaling down during lulls to optimize costs. Concurrently, configuring ECS Service Auto Scaling based on the ALB request count ensures that the microservices processing the requests will dynamically add or remove tasks to match incoming traffic, providing sufficient compute resources to handle the increased demand and effectively utilize the scaled DynamoDB capacity. This combination offers a fully automated, elastic, and cost-efficient solution.

About these practice questions

Courseiva writes every DVA-C02 question from scratch — 1,135 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.