AWS SAA-C03: Design Resilient Architectures Practice Questions

RDS read replicas are asynchronously replicated copies of the primary database. Typical replication lag is measured in seconds, well within the 5-minute freshness requirement. Reporting queries are routed to the read replica endpoint, completely isolating long-running analytical queries from the primary OLTP workload. Multiple read replicas can be added if query concurrency increases. The Multi-AZ standby instance is a synchronous hot standby used exclusively for failover—it is not accessible for read queries; AWS does not expose a direct connection endpoint to the standby. Amazon Redshift with DMS is a valid analytics architecture but adds significant complexity, cost, and setup time; DMS replication latency can exceed 5 minutes depending on batch settings, potentially violating the freshness requirement. RDS Proxy improves connection pooling and failover speed but does not separate read workloads from the primary; it does not route queries to a replica by itself.

CRR with Delete Marker Replication enabled replicates objects to eu-west-1 within minutes and also replicates delete markers, satisfying the accidental-deletion replication requirement. Versioning (required for CRR) must be enabled on both buckets; it also protects objects from permanent deletion because a delete operation only adds a delete marker—objects can be recovered by removing the marker. Together, these two features meet all stated requirements. — SRR replicates within the same Region; chaining two SRR rules would not directly replicate to eu-west-1 and adds unnecessary complexity when CRR does this natively. — A Lifecycle rule to Glacier Instant Retrieval addresses cost optimization, not deletion protection or replication, and would make objects harder to access rapidly. — S3 Object Lock in Compliance mode is a very strong control (prevents deletion even by root), but the scenario asks for protection from accidental deletion; Versioning already handles this and is simpler. More importantly, Object Lock is not listed as a core requirement here—it is an optional enhancement. — A Multi-Region Access Point simplifies client-side access routing but does not replicate objects; it has no bearing on replication or deletion protection.

Enabling RDS Multi-AZ creates a synchronous standby replica in a different AZ. In the event of an AZ failure or instance issue, RDS automatically fails over to the standby, typically within 1–2 minutes, meeting the 30-minute RTO. Enabling automated backups with point-in-time recovery allows the database to be restored to any second within the retention window (up to 35 days), easily satisfying the 1-hour RPO since transaction logs are continuously shipped to S3. A read replica in the same Region is not automatically promoted during failures and requires manual intervention, which may not meet the 30-minute RTO. Migrating to DynamoDB is a disruptive architectural change and is not a straightforward path for relational MySQL workloads. Taking manual snapshots every 15 minutes is operationally complex, error-prone, and still does not guarantee the 1-hour RPO as reliably as automated point-in-time recovery.

Step Functions Task states support a native Retry field where you can specify an array of retry configurations, including ErrorEquals (which errors to retry), MaxAttempts (maximum retry count), IntervalSeconds (initial wait), and BackoffRate (multiplier applied to the wait interval on each retry). Setting MaxAttempts to 3 and BackoffRate to a value greater than 1 (e.g., 2.0) implements exponential backoff automatically within the state machine, with no additional states needed. A Catch block handles errors that exhaust all retries (or errors not covered by Retry) by transitioning to a different state—it is meant for error recovery/fallback, not for retry logic. Using a manual Wait-and-loop pattern via Catch is possible but verbose and error-prone compared to the built-in Retry field. An activity worker with a heartbeat is a long-polling pattern for external workers and is unrelated to automatic retry with backoff. A Parallel state runs branches concurrently and collects all results; it cannot select the first successful result and discard others without additional coordination logic.

Correct (B): Decoupling the slow third-party shipping API call via SQS makes the synchronous API path fast and resilient—the Lambda function writes to the DB, publishes a message to SQS, and returns success immediately. A separate async Lambda consumer handles the shipping API call with its own retry logic, DLQ, and visibility timeout, eliminating timeouts cascading to the customer. Correct (D): Implementing an idempotency key (e.g., using the order ID as a unique constraint or an idempotency table) ensures that if the Lambda function is retried due to a timeout, the database write is a no-op for already-processed requests, preventing duplicate orders. Option A is wrong because increasing the timeout to 15 minutes doesn't resolve the root cause—customers would just wait longer before receiving a 504, and the synchronous dependency on the shipping API remains; it also increases costs. Option C is wrong because setting reserved concurrency to 1 would serialize all requests, creating a bottleneck that destroys scalability and does not address duplicates from retries. Option E is wrong because ALB has a maximum timeout of 4000 seconds, but swapping load balancers doesn't address the architectural flaw of synchronous coupling to a slow third-party API. Option F is wrong because API Gateway caching caches responses for GET requests; it does not help with POST order submissions and does not address timeouts or duplicates.