SOA-C02 Reliability and Business Continuity Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Change the SQS queue from standard to FIFO to ensure messages are processed in order.

  Why it's wrong here

  Switching to a FIFO queue guarantees message ordering and exactly-once delivery, but FIFO throughput is capped at 300 messages/second without batching or 3,000/second with batching. That throughput ceiling can make burst handling worse, not better. More importantly, message ordering is not the requirement here — the bottleneck is processing capacity during traffic spikes, so preserving order does nothing to help the worker fleet scale horizontally.

• ✓

  Configure an auto scaling policy for the Auto Scaling group based on the SQS queue depth (ApproximateNumberOfMessagesVisible).

  Why this is correct

  Configuring the Auto Scaling group to scale based on the SQS queue depth (ApproximateNumberOfMessagesVisible) is the correct approach because it directly matches worker capacity to the unprocessed backlog. An Amazon CloudWatch alarm or target tracking policy on this metric can add EC2 instances as messages accumulate and terminate instances as the queue drains. For best results, the policy should use a per-instance backlog metric (queue depth divided by desired capacity) to avoid over-scaling or flapping when the queue is briefly busy.

• ✗

  Use a larger EC2 instance type with enhanced networking to process messages faster.

  Why it's wrong here

  Enhanced networking via the Elastic Network Adapter (ENA) improves packet-per-second throughput and reduces latency, but message processing in EC2 workers is typically CPU- and memory-bound rather than network-bound. If the instances are not already saturating their network link, enabling enhanced networking will not reduce message processing time. It is also still a form of vertical capacity adjustment, so it lacks the elasticity needed to absorb sudden workload spikes without manual intervention.

• ✗

  Increase the EC2 instance size to a larger type with more CPU and memory.

  Why it's wrong here

  Increasing the EC2 instance size to a larger type with more CPU and memory, often called vertical scaling, is constrained by the maximum instance size available in the region and requires a stop/start or replacement, causing downtime. It also does not provide the ability to scale out and back down dynamically as queue depth fluctuates. Horizontal scaling—adding more instances through an Auto Scaling group—is more flexible, cost-effective, and can handle spikes that exceed the capacity of even the largest single instance.

Go deeper

Related to this question