AWS Design Resilient Architectures 6

Question 1

A media streaming company experiences unpredictable traffic spikes during live events. Their application tier runs on EC2 instances behind an Application Load Balancer. During a recent event, the Auto Scaling group took 8 minutes to provision new instances, causing degraded performance. Which combination of strategies would BEST reduce scale-out latency?

Accepted Answer

Use predictive scaling with warm pools to pre-initialize instances before anticipated spikes

Answer

Predictive scaling uses machine learning to forecast demand and proactively scales capacity before it's needed. Warm pools keep pre-initialized EC2 instances in a stopped or running state, dramatically reducing scale-out time from minutes to seconds since instances are already bootstrapped. This combination addresses both anticipating the spike (predictive scaling) and eliminating instance initialization delay (warm pools). Increasing cooldown periods would make scaling slower, not faster. NLB doesn't reduce provisioning time. Reducing the evaluation period to 10 seconds isn't a supported CloudWatch configuration for Auto Scaling.

Question 2

An e-commerce platform uses DynamoDB for its product catalog. During flash sales, a small subset of popular items receives 90% of read traffic, causing hot partition issues and throttling. The application uses eventually consistent reads. Which solution eliminates the hot partition problem with the LEAST operational overhead?

Accepted Answer

Implement DynamoDB Accelerator (DAX) as a caching layer in front of DynamoDB

Answer

DAX is a fully managed, highly available, in-memory cache specifically for DynamoDB that delivers microsecond read performance. Hot partition issues occur because the same partition key is read repeatedly — DAX absorbs these repetitive reads at the cache layer before they ever reach DynamoDB, eliminating throttling with minimal operational overhead and no application-side key sharding logic. Adding random suffixes requires scatter-gather queries and significant application changes. Auto-scaling with provisioned capacity still doesn't prevent hot partition throttling since the problem is partition-level, not table-level. Global tables add cross-region replication complexity and don't solve hot partitions within a region.

Question 3

A financial services company runs a critical payment processing application across two Availability Zones. They want to achieve a Recovery Time Objective (RTO) of less than 1 minute and a Recovery Point Objective (RPO) of zero for their RDS database. Which configuration meets BOTH objectives?

Accepted Answer

Configure RDS Multi-AZ deployment — the standby replica is synchronously replicated and failover is automatic

Answer

RDS Multi-AZ uses synchronous replication to a standby instance in a different AZ, ensuring RPO of zero (no data loss since every write is confirmed on the standby before acknowledging to the application). Automatic failover typically completes in 60-120 seconds, meeting an RTO under 2 minutes — and AWS SLA targets sub-60-second DNS failover for most engines. Read replicas use asynchronous replication (non-zero RPO) and require manual promotion (longer RTO). Daily snapshots have RPO of up to 24 hours and cannot restore in 1 minute. Aurora is excellent but the question specifically asks about RDS Multi-AZ which already achieves the stated objectives without adding Aurora complexity.

Question 4

A SaaS company's microservices architecture uses SQS queues between services. During downstream service outages, unprocessed messages accumulate and eventually expire, causing permanent data loss. What is the MOST resilient pattern to prevent message loss without modifying the upstream producer services?

Accepted Answer

Configure a Dead Letter Queue (DLQ) with a redrive policy and set up alerting to replay messages after recovery

Answer

A Dead Letter Queue with a redrive policy captures messages that fail processing after a configured number of attempts, preventing them from expiring in the main queue. After the downstream service recovers, messages can be replayed from the DLQ back to the source queue using the SQS console or StartMessageMoveTask API. This requires no changes to upstream producers and provides a durable safety net for all failed/unprocessed messages. Increasing retention alone doesn't prevent loss if the outage exceeds the retention period or if maxReceiveCount is reached. FIFO queues address ordering, not durability during outages. SSE and VPC endpoints address security and network routing, not message durability.

Question 5

An organization runs a multi-tier web application in a single AWS Region. They need to design for regional disaster recovery with an RTO of 4 hours and RPO of 1 hour, while minimizing costs. Which DR strategy BEST fits these requirements?

Accepted Answer

Pilot light with core components (database replication) running in a secondary region and AMIs pre-built for rapid scale-out

Answer

Pilot light keeps only the most critical core components running in the secondary region (typically the database, replicating continuously for sub-1-hour RPO), with application tier AMIs pre-built and ready to launch. This achieves RPO of under 1 hour via continuous DB replication and RTO of 4 hours since instances can be launched from pre-built AMIs and scaled out — all at significantly lower cost than warm standby or multi-site. Warm standby would meet the requirements but costs more than needed since it maintains a scaled-down running fleet. Multi-site active/active is the most expensive option and overkill for a 4-hour RTO. Backup and restore typically cannot reliably achieve 4-hour RTO for multi-tier applications at scale.

AWS Practice Test

AWS Practice Test

AWS Design Resilient Architectures 6