Design Resilient Architectures: free practice questions

The SNS-to-SQS fan-out pattern is the canonical AWS solution for this requirement. Each downstream service gets its own SQS queue subscribed to the same SNS topic. SNS delivers a copy of every message to each queue independently, so a slow consumer (e.g., the recommendation engine) does not block faster consumers (e.g., cache invalidation). Each service controls its own polling rate, retry behavior, and dead-letter queue. A single SQS FIFO queue cannot fan out to multiple independent consumers; all consumers would compete for the same messages, and each message would only be processed once. Direct HTTPS subscriptions to SNS create tight coupling—if any subscriber's endpoint is slow or unavailable, it affects retry behavior and does not decouple processing speeds. A single Lambda fan-out function introduces a single point of failure and adds unnecessary latency; EventBridge rules can target multiple services directly without needing an intermediary Lambda.

Setting the visibility timeout to 30 minutes (greater than the maximum job duration of 25 minutes) ensures that a job's message does not become visible to other consumers while it is being processed. If Lambda is terminated, the message becomes visible after 30 minutes and is retried. The DLQ with maxReceiveCount of 3 automatically isolates jobs that fail repeatedly—all with no custom code. Option B sets the visibility timeout to 5 minutes, which is shorter than the minimum job duration of 10 minutes; this guarantees duplicate processing every time, which is worse than the original problem. Option C (DynamoDB + scheduled Lambda) requires significant custom code, violating the least-custom-code requirement. Option D (long polling + extended timeout) reduces overhead but does not prevent mid-job termination (Lambda maximum timeout is 15 minutes, but jobs can take up to 25 minutes); it also does not isolate consistently failing jobs.

Correct (B): Route 53 failover routing policies use health checks associated with the primary record. When the health check fails (the primary ALB becomes unhealthy), Route 53 stops returning the primary record and begins returning the secondary record — in this case the S3 static website endpoint. This is a common pattern for providing a graceful degradation page during outages. Incorrect (A): Route 53 failover routing does not require primary and secondary endpoints to be in different Regions. Both can be in the same Region. Cross-Region DR is a common use case, but it is not a requirement. Incorrect (C): Latency-based routing uses latency measurements to route users to the lowest-latency endpoint; this is a different routing policy from failover routing. Failover routing is exclusively health-check-driven. Incorrect (D): Amazon S3 static website endpoints are valid targets for Route 53 alias records and can be used as secondary failover targets. S3 is a supported alias target type in Route 53.

Connection draining (deregistration delay) ensures that when an instance is deregistered from the ALB—such as during a rolling deployment—the load balancer stops sending new requests to that instance but allows in-flight requests to complete gracefully before fully removing it. This eliminates 502 errors caused by abrupt connection termination. Cross-zone load balancing distributes traffic evenly across AZs but does not address in-flight connection handling during deregistration. Sticky sessions pin users to specific instances but would actually worsen the problem during deployments if users are pinned to a terminating instance. ALB access logging records request metadata for analysis but has no effect on connection handling.

Correct: A target tracking policy on the SQS ApproximateNumberOfMessagesVisible metric (or the derived 'backlog per instance' custom metric) directly aligns scaling with work in the queue—the fleet grows when messages accumulate and shrinks when the queue drains. This is the AWS-recommended pattern for queue-based workloads. Option B is wrong because scheduled scaling requires predictable timing; it cannot react to unexpected demand spikes and may add capacity before it is needed or miss irregular events. Option C is wrong because CPU utilization is a lagging indicator for queue-based workloads—instances may be idle waiting for messages while the queue grows, meaning CPU stays low even when the queue is deep, causing under-scaling. Option D is wrong because predictive scaling uses historical patterns to forecast load—it is useful for recurring, predictable load patterns but cannot react to unexpected spikes in queue depth and the scenario does not indicate the spikes are consistently predictable.