SAA-C03 Design Resilient Architectures Practice Question

A healthcare company runs a batch ingestion pipeline on Amazon EC2 instances that read messages from an Amazon SQS queue and write results to Amazon DynamoDB. The pipeline must be resilient so that a single instance failure does not stop processing and no messages are lost. Which two architectural changes should a solutions architect make to meet these requirements? (Choose two.)

⚠ Common exam trap

The trap here is treating caching or FIFO ordering as durability mechanisms, when message safety actually depends on visibility timeout and delete-after-success semantics.

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

✓

Move the ingestion workers into an Auto Scaling group across multiple Availability Zones with a launch template, so failed instances are replaced automatically.

Resilience here has two parts: redundant compute that self-heals, and queue semantics that return unprocessed messages to the queue. A multi-AZ Auto Scaling group replaces failed workers, while a visibility timeout longer than processing time plus delete-after-success ensures a message is reprocessed rather than lost if an instance dies mid-flight.

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 number of EC2 instances manually to five and place them all in the same Availability Zone for low latency.
Why it's wrong here
Manually adding instances does not provide automatic replacement when one fails, and concentrating them in a single Availability Zone means a zone event takes down the entire pipeline. This approach increases capacity but leaves both the single-point-of-failure and the no-message-loss requirements unmet.
✗
Convert the SQS queue to a FIFO queue with content-based deduplication enabled to guarantee no message loss.
Why it's wrong here
A FIFO queue provides ordering and deduplication, not durability against worker failure. Messages are still deleted by consumers, so a crashed worker with an in-flight message would lose it unless visibility timeout and delete-after-success behavior are configured. The queue type alone does not solve the resilience requirement.
✓
Move the ingestion workers into an Auto Scaling group across multiple Availability Zones with a launch template, so failed instances are replaced automatically.
Why this is correct
An Auto Scaling group spanning multiple Availability Zones maintains desired capacity and replaces unhealthy instances automatically, removing the single-instance failure point. Combined with a queue-based workload, replacement workers resume consuming messages, so processing continues without manual intervention and the pipeline remains resilient to instance loss.
✗
Enable DynamoDB Accelerator (DAX) on the target table to cache writes so failed instances do not lose data.
Why it's wrong here
DAX is a read-through and write-through cache for DynamoDB that improves read performance, but it is not designed to buffer writes across an instance failure. Enabling it does not make the pipeline resilient to worker loss and does not prevent message loss in the queue, so it addresses the wrong problem here.
✓
Configure the SQS queue with a visibility timeout longer than the maximum processing time and have workers delete a message only after successful processing.
Why this is correct
A visibility timeout that exceeds processing time prevents other workers from receiving an in-flight message prematurely, and deleting only after success ensures a crashed worker's message becomes visible again for reprocessing. Together these settings guarantee that no message is silently lost when an instance fails mid-processing.

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question