2.2 - Designing for reliability and disaster recovery
AWS Solutions Architect Professional objective 2.2 covers building reliability and disaster recovery into a new design. You decouple a synchronous order tier from a slow downstream by writing to an Amazon SQS queue with a dead-letter queue so orders survive an outage, and you meet a near-zero RPO in one Region with Multi-AZ RDS and its synchronous standby. DynamoDB gains resilience from point-in-time recovery for continuous backups and global tables for multi-Region active-active writes, on-demand capacity absorbs unpredictable traffic, and Amazon MSK runs open-source Kafka so existing clients connect unchanged. You spread Kinesis load with a higher-cardinality partition key and more shards, route asynchronous Lambda results with onSuccess and onFailure destinations, and forward on-premises DNS with a Route 53 Resolver outbound endpoint. DR patterns follow RTO and RPO: pilot light replicates core data with minimal idle compute, and active-active pairs DynamoDB global tables with Route 53 health checks. Expect scenarios about a recovery target or an outage-proof tier, and ask which reliability approach fits.
Never lose orders during a downstream outage = SQS queue plus a dead-letter queue. Near-zero RPO in one Region = Multi-AZ RDS synchronous standby. Multi-Region active-active writes = DynamoDB global tables + Route 53 health checks.
Practice questions
1. A critical app needs an RPO near zero and an RTO of a few minutes across two Regions, at reasonable cost. Which disaster-recovery strategy fits?
- Backup and restore from cross-Region snapshots
- Warm standby: a scaled-down copy always running in the second Region (correct answer)
- Pilot light limited to replicated data with no compute prepared
- Multi-site active/active with full capacity running in both Regions
Warm standby keeps a scaled-down but running copy, so data is continuously replicated (RPO near zero) and you just scale up on failover (RTO minutes) without paying for full duplicate capacity. Backup/restore and pilot light give slower RTO; active/active meets it but costs the most.
2. A synchronous order service calls a slow downstream billing system directly, so a billing slowdown drops customer orders. The team wants to decouple the two tiers so orders are never lost during a downstream outage. Which TWO changes achieve this? (Choose TWO.)
- Have the order service write each order to an Amazon SQS queue (correct answer)
- Increase the order service HTTP timeout so the caller waits far longer for the billing system to respond
- Add more billing instances behind an internal Application Load Balancer only
- Attach a dead-letter queue so messages that fail repeatedly are retained for inspection (correct answer)
Writing orders to SQS buffers them so billing can process at its own pace and an outage never drops an order, and a DLQ preserves messages that keep failing instead of discarding them. A longer timeout still couples the call and blocks the caller, and more billing instances alone leaves the synchronous coupling in place.
3. A payment workflow must process messages in the exact order they were sent and must never process a duplicate, even if a producer retries. Which messaging choice enforces both guarantees natively?
- A standard SQS queue with client-side sequence numbers added to each message
- An SNS standard topic subscribed by the payment consumer directly
- An SQS FIFO queue with content-based deduplication enabled (correct answer)
- A Kinesis Data Firehose delivery stream feeding the payment service
An SQS FIFO queue guarantees strict ordering within a message group and drops duplicates via a deduplication ID or content hash, so retries are safe. Standard SQS and standard SNS are best-effort ordering with possible duplicates, and Firehose is for buffered delivery to stores, not ordered transactional messaging.
4. Consumers reading from an SQS queue sometimes take longer than expected to finish a message, and other consumers occasionally grab and process the same message before the first finishes. Which single setting most directly prevents this double processing?
- Increase the queue's visibility timeout to exceed the processing time (correct answer)
- Enable long polling by setting a higher receive wait time on the queue
- Reduce the maximum message size so messages are handled faster
- Switch the queue to short polling to receive messages more quickly
Visibility timeout hides a received message from other consumers while one processes it; setting it above the actual processing time stops a second consumer from picking up the same message. Long/short polling affects how empty receives are handled, and message size does not control concurrent re-delivery.
5. A Lambda function processes messages from an SQS queue. During large bursts the function scales up and overwhelms a downstream relational database with connections, and some messages that always fail keep being retried forever. Which TWO measures address these issues? (Choose TWO.)
- Set reserved concurrency on the function to cap simultaneous executions (correct answer)
- Remove the visibility timeout so failed messages return to the queue instantly
- Configure a dead-letter queue with a maxReceiveCount to sideline poison messages (correct answer)
- Increase the function timeout so each invocation can retry the database many times
Reserved concurrency caps how many Lambda executions run at once, protecting the database connection pool during bursts, and a DLQ with a maxReceiveCount moves messages that keep failing out of the main queue after N attempts. Removing the visibility timeout causes immediate re-delivery storms, and a longer timeout increases, not reduces, database pressure.
6. A critical relational workload has an RTO of about 15 minutes and an RPO near zero within a single Region. The team wants a managed database that fails over automatically to a standby with no data loss. Which configuration fits?
- Single-AZ RDS with automated snapshots taken every hour
- A read replica in the same AZ promoted manually during an outage
- Multi-AZ RDS with a synchronous standby in a second AZ (correct answer)
- RDS with cross-Region snapshot copies restored on demand
Multi-AZ RDS keeps a synchronous standby in another AZ and fails over automatically in a minute or two, giving near-zero RPO and low RTO within a Region. Snapshots and manually promoted replicas lose recent data or take longer, and cross-Region restore is slower.