AWS Design Resilient Architectures 4

Question 1

A financial services company runs a critical payment processing application on EC2 instances behind an Application Load Balancer. During peak transaction periods, the application experiences latency spikes. The team wants to implement auto scaling but must ensure that in-flight transactions are never dropped when instances are terminated. Which configuration achieves this?

Accepted Answer

Enable connection draining (deregistration delay) on the target group and configure scale-in protection during transaction processing

Answer

Connection draining (deregistration delay) causes the load balancer to stop sending new requests to a deregistering instance while allowing in-flight requests to complete, up to the configured timeout. Combined with scale-in protection on instances processing active transactions, this ensures zero dropped transactions during scale-in events. The other options either waste resources, misattribute capabilities to NLB, or only partially address the problem.

Question 2

An e-commerce platform stores session data in a single ElastiCache Redis node. The team is concerned about session data loss if the node fails. They want a solution that provides automatic failover with minimal data loss and no application code changes. What should they implement?

Accepted Answer

ElastiCache Redis with cluster mode disabled and Multi-AZ enabled with automatic failover

Answer

ElastiCache Redis with cluster mode disabled and Multi-AZ enabled creates a primary node with a synchronous replica in a different AZ. If the primary fails, automatic failover promotes the replica to primary within seconds, with the same endpoint — requiring no application code changes. Cluster mode would require sharding logic changes. Memcached has no replication or failover capability. Switching to DynamoDB with DAX would require significant application refactoring.

Question 3

A company has a microservices architecture where Service A calls Service B synchronously via REST API. When Service B experiences high load and slows down, the slow responses cause thread pool exhaustion in Service A, eventually causing Service A to fail as well. This is an example of cascading failure. Which AWS-native approach best prevents this failure pattern?

Accepted Answer

Implement Amazon SQS between Service A and Service B to decouple them asynchronously

Answer

Introducing SQS between the services converts the synchronous call to an asynchronous pattern, completely eliminating cascading failure. Service A publishes messages to SQS and returns immediately; Service B consumes at its own pace. Thread pool exhaustion in Service A is impossible because it no longer waits on Service B. App Mesh circuit breakers help but still require synchronous call patterns. An ALB only distributes load but doesn't prevent Service A from waiting. Larger instances delay but don't prevent the cascading failure under sufficient load.

Question 4

A multi-tier web application uses RDS MySQL with a single primary instance. A recent incident showed that a developer accidentally ran a DELETE without a WHERE clause, deleting critical data. Automated daily snapshots exist but restoring takes 45 minutes. The company's RPO is 5 minutes and RTO is 15 minutes. Which configuration meets both requirements?

Accepted Answer

Enable RDS automated backups with a backup retention period and use Point-in-Time Recovery (PITR) to restore to just before the deletion

Answer

RDS Point-in-Time Recovery uses transaction logs captured every 5 minutes (combined with automated backups) to restore a DB to any second within the retention period, meeting the 5-minute RPO. Restoration to a new instance typically completes in 10-15 minutes, meeting the 15-minute RTO. Multi-AZ replicates all changes including the accidental DELETE synchronously — it provides HA for instance failures, not logical data errors. A read replica also receives the DELETE statement in near-real-time. AWS Backup does not support 5-minute backup intervals for RDS.

Question 5

A global SaaS application is deployed in us-east-1. The architecture team wants to implement a warm standby disaster recovery strategy in eu-west-1 with an RTO under 30 minutes. The application uses RDS PostgreSQL and S3. Which combination of services achieves warm standby for this data tier?

Accepted Answer

RDS cross-region read replica in eu-west-1 promoted during failover, and S3 Cross-Region Replication for the S3 buckets

Answer

A cross-region RDS read replica maintains a continuously updated copy in eu-west-1 with typical replication lag under 1 minute; promotion to standalone primary takes 5-10 minutes, well within the 30-minute RTO. S3 CRR asynchronously replicates objects to the target region, keeping the storage tier in sync. DMS adds unnecessary complexity and cost for this use case. S3 versioning alone provides no replication. Backup restoration can take hours, violating the RTO. Aurora Global Database is a valid and arguably better option, but the question asks specifically about RDS PostgreSQL, and option A is the correct warm standby pattern for standard RDS.

AWS Practice Test

AWS Practice Test

AWS Design Resilient Architectures 4