3.2 - Improving reliability and fault tolerance
AWS Solutions Architect Professional objective 3.2 covers making an existing system more reliable and fault-tolerant. You insert an SQS queue between an order service and an overloaded billing tier so requests buffer instead of dropping, and you stop synchronized retry storms with exponential backoff and jitter that spreads out client retries. Route 53 failover routing with a health check on the primary sends traffic to a standby only when the primary is unhealthy, a circuit breaker with a short timeout keeps a slow non-critical dependency from cascading into an outage, and Systems Manager Patch Manager with patch baselines and maintenance windows replaces ad hoc SSH patching, using separate baselines and windows per environment. A dead-letter queue with a maxReceiveCount redrive policy isolates poison messages, Cost Explorer finds spend by service and tag, and you recover value from underused commitments by selling Standard RIs on the Marketplace or exchanging Convertible RIs. Expect scenarios about retry storms, graceful degradation, or controlled patching, and ask which resilience pattern fits.
Buffer requests during a downstream spike = insert an SQS queue. Stop synchronized retry storms = exponential backoff with jitter. Slow non-critical dependency must not cascade = circuit breaker with a short timeout.
Practice questions
1. A synchronous chain of microservices fails entirely whenever the downstream billing service is briefly overloaded, dropping user orders. The architect wants to keep orders during spikes without losing them. What change best improves resilience?
- Increase the HTTP client timeout on the order service so that every call simply waits far longer before it fails
- Insert an SQS queue between the order service and billing to buffer and decouple them (correct answer)
- Move both services onto one larger instance so calls stay within the same host
- Add a second synchronous retry immediately after the first failed billing call
An SQS queue decouples producer from consumer: orders are buffered durably and billing drains them at its own pace, so spikes no longer drop orders. Longer timeouts and immediate retries just pile load onto an overloaded service, and co-locating services does not add buffering or fault isolation.
2. A production RDS PostgreSQL database is Single-AZ, and a recent AZ event caused an hour of downtime. The team wants automatic failover without redesigning the app. What should they enable?
- Automated daily snapshots copied to a second Region for later manual restore
- Multi-AZ deployment with a synchronous standby that fails over automatically (correct answer)
- Two independent read replicas that the application promotes on its own when needed
- A larger instance class so the single database can absorb more concurrent load
Multi-AZ keeps a synchronous standby in another AZ and RDS fails over to it automatically via a DNS swap, with no application redesign. Cross-Region snapshots need a manual restore, self-promoting read replicas require app logic and are asynchronous, and a bigger instance does nothing for AZ failure.
3. A stateless web tier behind an ALB sometimes keeps sending traffic to instances that have hung but not crashed, and the fleet does not grow under load. Which TWO changes improve availability? (Choose TWO.)
- Give each instance its own static Elastic IP address so that clients can always reconnect straight to the very same host
- Configure ALB health checks on an application endpoint to drain unhealthy targets (correct answer)
- Enable an Auto Scaling policy that adds instances when a load metric rises (correct answer)
- Increase the connection idle timeout on the ALB so hung requests wait longer
Application-level ALB health checks detect a hung instance and stop routing to it until it recovers, while an Auto Scaling policy adds capacity as load rises. Static Elastic IPs pin clients to individual hosts and hurt elasticity, and a longer idle timeout keeps stuck requests alive rather than shedding them.
4. Consumers of an SQS queue occasionally hit a malformed message that keeps failing, is retried forever, and blocks progress while inflating processing cost. What is the standard fix?
- Delete every message that fails once so the queue can never get stuck again
- Increase the visibility timeout to an extremely large value on the main processing queue for every single message received
- Configure a dead-letter queue with a maxReceiveCount to isolate poison messages (correct answer)
- Switch the queue from standard to FIFO so ordering prevents the failures
A dead-letter queue with a redrive policy moves a message aside after maxReceiveCount failed receives, so poison messages are isolated for inspection while healthy processing continues. Deleting on first failure loses recoverable messages, a huge visibility timeout just stalls, and FIFO ordering does not fix a malformed payload.
5. During a brief downstream outage, thousands of clients retry a failing API in lockstep, and the synchronized retries repeatedly hammer the service just as it tries to recover, prolonging the outage. What client-side pattern best prevents this?
- Retry immediately with no delay so requests succeed as soon as the service returns
- Retry a fixed number of times spaced exactly one second apart on every client
- Exponential backoff with jitter to spread out and space out retry attempts (correct answer)
- Give each client an unlimited retry budget so no request is ever abandoned
Exponential backoff increases the wait between attempts and jitter randomizes it, so retries spread out instead of arriving in synchronized waves that overwhelm a recovering service. Immediate or fixed-interval retries stay synchronized and amplify load, and unlimited retries remove the backpressure needed to let the service recover.
6. A single-Region web app must survive a full Regional outage with an RTO of minutes, serving from a second Region automatically. Data is already replicated cross-Region. Which TWO components complete an automatic failover? (Choose TWO.)
- A single Route 53 record pinned to the primary Region's load balancer only
- Route 53 health checks with a failover routing policy across the two Regions (correct answer)
- A standby stack pre-deployed in the second Region ready to take traffic (correct answer)
- A manual runbook the on-call engineer follows to repoint DNS during an outage
Route 53 health checks with a failover routing policy detect the primary Region as unhealthy and automatically shift DNS to the second Region, and a pre-deployed standby stack there can accept traffic within minutes. A single pinned record has no failover target, and a manual DNS runbook is not automatic and misses the RTO under pressure.