CCNA Design Resilient Architectures Questions

A dead-letter queue isolates poison messages that repeatedly fail processing, preventing them from consuming worker capacity. Making the handler idempotent by storing a durable processed-message key (e.g., using DynamoDB or a database) ensures that even if the same message is delivered more than once, duplicate side effects are avoided. This combination directly addresses both requirements: stopping poison messages from wasting resources and preventing duplicate processing.

An ElastiCache Redis replication group with automatic failover across multiple Availability Zones ensures that if the primary node or its AZ becomes impaired, a read-replica in another AZ is automatically promoted to primary. This allows the stateless web service to continue reading cached responses without interruption, satisfying both the maintenance and AZ impairment requirements.

The current architecture has a single point of failure: the ASG spans only one subnet (one AZ), so if that AZ fails, all EC2 instances are lost, and the ECS service cannot run any tasks. By increasing the ASG min size to at least 2 and ensuring it uses subnets in at least two AZs, the ASG will maintain at least one healthy instance in each AZ, allowing the ECS service to survive a single-AZ outage. This aligns with the AWS Well-Architected Framework's principle of deploying across multiple AZs for high availability.

RDS Multi-AZ keeps a synchronous standby in a second Availability Zone and fails over automatically, protecting committed orders. An Auto Scaling group across AZs maintains the web tier, and externalizing sessions to ElastiCache for Redis removes dependence on a single instance, so the application survives an AZ failure with minimal redesign.

Amazon SQS standard queues provide at-least-once delivery, which guarantees that every message is processed at least once, meeting the requirement that every event must be processed. Duplicate processing is acceptable because the consumer can be designed to handle idempotency. This is a managed, AWS-native service that aligns with the architecture review board's preference.

Making the payment step idempotent using a unique transaction identifier ensures that if the same message is processed multiple times due to a timeout, the payment is only charged once. This is a common pattern for handling at-least-once delivery semantics in Amazon SQS, where the worker must be designed to handle duplicate messages safely.

A dead-letter queue (DLQ) with an appropriate maxReceiveCount allows messages that repeatedly fail processing to be moved out of the source queue after a specified number of receive attempts. This prevents poison messages from blocking retries and consuming processing resources, without requiring custom operational scripts.

CloudFront caches responses from the S3 origin based on configured TTLs (Cache-Control or Expires headers). If the S3 origin experiences a short outage, CloudFront can still serve cached content to users as long as the TTL has not expired, ensuring availability without custom scripts. This is the most direct and resilient feature for this use case.

A single-instance Auto Scaling group is the managed way to keep exactly one healthy instance running and to replace it automatically when it is terminated or fails. Supplying the job through a launch template's user data means every replacement instance starts the job again, and because the job is idempotent, restarting from the beginning is acceptable. No custom alarm or recovery scripting is required.

Introducing an SQS queue between EventBridge and the consumer decouples the event delivery from the downstream payment API. During outages, events are stored durably in SQS and can be processed later without being lost. A Dead Letter Queue (DLQ) captures events that fail repeatedly, preventing poison messages from blocking the queue and ensuring no events age out due to retry exhaustion.

The recommended solution is to externalize session data to an ElastiCache for Redis cluster with Multi-AZ enabled and run the application in an Auto Scaling group across two Availability Zones behind an Application Load Balancer. This design ensures that session data survives instance failures and the application remains available if one AZ fails. The load balancer distributes traffic to healthy instances.

Scheduled EBS snapshots provide point-in-time backups of EBS volumes, which can be copied to another Region using the cross-Region snapshot copy feature. During recovery, you restore volumes from those snapshots in the target Region, ensuring the data is restorable after a major outage. This approach meets the requirements for frequent point-in-time recovery and cross-Region durability.

Distributing an Auto Scaling group across multiple Availability Zones (AZs) ensures that if one AZ fails, the remaining AZs continue to serve traffic. The Application Load Balancer (ALB) is already configured for at least two AZs, but the ASG’s single-AZ subnet placement creates a single point of failure. By adding subnets in at least two AZs to the ASG, the application becomes resilient to an AZ outage without any other architectural changes.

Aurora's storage layer replicates each data volume six ways across three Availability Zones, and placing the writer plus two Aurora Replicas in separate zones means a zone failure does not remove all compute endpoints. Aurora automatically promotes a surviving replica and repoints the cluster endpoint, so writes resume with no operator involvement, while the reader endpoint spreads read queries across the replicas for independent read scaling.

Amazon SNS (or EventBridge) enables asynchronous, fan-out messaging where a single payment-success event is published once and delivered independently to multiple downstream services (inventory, shipping, analytics) via SQS queues or other targets. This decouples the producer from consumer latency—analytics can take its time without blocking order processing—and ensures each consumer processes the event at its own pace, meeting the requirement for independent, non-blocking reactions.

Amazon SQS supports configuring a redrive policy with a Dead-Letter Queue (DLQ) that automatically moves messages after a specified number of receive attempts (maxReceiveCount). This isolates poison messages that fail validation and cause crashes, preventing them from being retried indefinitely and slowing down valid message processing. The worker can then focus on valid messages while the DLQ stores the problematic ones for later analysis or manual intervention.

S3 Object Lock requires versioning and enforces a retention period during which object versions cannot be deleted or overwritten by anyone, including the root user. Compliance mode cannot be shortened or bypassed, so it uniquely satisfies the requirement to prevent permanent deletion for at least 90 days while still allowing recovery of prior versions.

Placing subnets in at least two Availability Zones ensures that if one AZ fails, the Auto Scaling group can launch instances in the remaining healthy AZ, maintaining application availability. Health checks integrated with the Application Load Balancer allow the Auto Scaling group to automatically replace unhealthy instances without custom scripts, aligning with the requirement to avoid operational overhead.

The Aurora cluster writer endpoint always points to the current primary (writer) instance, even after a failover. By using this endpoint instead of a static instance endpoint, the application automatically resolves to the new writer without manual updates, eliminating connection errors and timeouts during failover transitions.

Point-in-time recovery (PITR) for DynamoDB enables continuous backups with 35-day granularity, allowing restoration to any second within that window. This directly satisfies the point-in-time recovery requirement without custom scripts, as it is a native AWS feature.

S3 Cross-Region Replication (CRR) automatically replicates objects to a destination bucket in a different AWS Region, meeting the disaster recovery requirement without custom scripts. Versioning must be enabled on both source and destination buckets for CRR to function, as it tracks object versions and ensures consistency during replication.

Configuring a redrive policy with a dead-letter queue (DLQ) allows messages that repeatedly fail processing to be moved out of the main queue after a specified number of receive attempts. Setting an appropriate visibility timeout greater than the maximum processing time ensures that messages are not made visible again before the consumer finishes processing, preventing premature retries. This directly isolates poison messages so they no longer block the processing of other messages in the queue.

An Auto Scaling group that spans at least two Availability Zones can replace a failed instance and can also launch instances in a healthy zone when one zone becomes unavailable. Attaching an Application Load Balancer provides a stable endpoint and health-based routing, delivering a managed, resilient architecture with minimal operational effort.

Implementing idempotent processing with a deduplication key (e.g., paymentId) ensures that even if duplicate messages arrive from SQS (due to retries or at-least-once delivery), the consumer can check a record of completed charges and safely ignore duplicates. This satisfies the business requirement of charging each payment at most once without relying on SQS’s best-effort deduplication or message ordering.

Deploying the ALB and Auto Scaling group across at least two Availability Zones (AZs) ensures that if one AZ fails, the ALB can route traffic to healthy EC2 instances in the remaining AZ(s). This is the fundamental AWS best practice for high availability: an ALB is a regional service that requires targets in multiple AZs to survive an AZ outage, and the Auto Scaling group must also span those AZs to maintain capacity. Without multi-AZ deployment, a single AZ failure makes the entire application unavailable regardless of instance health checks.

The Auto Scaling group's health check grace period allows instances to initialize without being marked unhealthy by the ELB health checks. By setting this grace period to exceed the ~2-minute artifact download time, the ASG will not replace instances that are still starting up, preventing the cascade of terminations and redeployments that caused the outage. This directly addresses the root cause—premature health check failures—without changing the health check configuration or reducing availability once the app is ready.

A primary failover record in Amazon Route 53 directs traffic to the primary ALB and is associated with a Route 53 health check. If the health check fails, Route 53 automatically fails over to the secondary failover record, ensuring high availability across Regions.

A dead-letter queue (DLQ) with a redrive policy and a maxReceiveCount allows messages that repeatedly fail processing to be moved to a separate queue after a specified number of receive attempts. This prevents poison pill messages from being retried indefinitely, freeing consumer capacity for valid messages. Amazon SQS automatically redirects messages to the DLQ once the maxReceiveCount threshold is exceeded, ensuring normal processing is not blocked.

Point-in-time recovery provides continuous backups that allow restoration to any second within the last 35 days, meeting the recovery requirement. DynamoDB global tables replicate the table across multiple AWS Regions and support automatic failover, meeting the Region-level availability requirement. Together, these two features address both dimensions of the scenario.

Using a dead-letter queue on the source SQS queue with a maximumReceiveCount ensures that messages are retried a limited number of times and then moved to a DLQ for separate handling. This prevents poison messages from blocking the queue and allows for later analysis or reprocessing, meeting the requirement to avoid infinite retries while not losing messages.

Resilience against an Availability Zone failure requires task capacity in more than one zone, and an Application Load Balancer with health checks directs traffic only to healthy tasks. Because the tasks are stateless and store output in S3, no shared state must be replicated. Application Auto Scaling with a target-tracking policy on ECSServiceAverageCPUUtilization then adjusts task count to match demand without manual intervention.

The web tier is currently deployed in a single Availability Zone (us-west-2a), so an outage of that AZ makes the entire tier unavailable. By attaching the Application Load Balancer and Auto Scaling group to subnets in a second Availability Zone, the application can continue serving traffic from the healthy AZ, achieving high availability with minimal architectural changes. This is the standard AWS best practice for multi-AZ resilience.

Amazon EFS provides a fully managed, POSIX-compliant NFSv4.1 shared file system that can be mounted concurrently across multiple Linux EC2 instances. By deploying mount targets in multiple Availability Zones, the file system remains accessible even if one AZ fails, satisfying the high-availability requirement without any custom scripts.

The requirement is legal-hold-style immutability that even administrators cannot override. S3 Object Lock in compliance mode enforces exactly that: protected object versions cannot be deleted or overwritten by any identity until the retention period lapses, and the retention cannot be shortened. Governance mode and replication both leave a path for privileged users to destroy the data.

B is correct because RDS Multi-AZ automatically synchronously replicates data to a standby in a different Availability Zone and triggers an automatic failover with zero manual intervention when an AZ failure occurs. This directly addresses the requirement to improve resilience while minimizing operational effort, as the failover is handled by AWS without any runbook execution or manual promotion.

The Aurora cluster writer endpoint always resolves to the current primary DB instance, even after a failover. By using this endpoint instead of a specific instance endpoint, the application automatically reconnects to the new writer without manual intervention or connection errors.

Amazon RDS automated backups enable point-in-time recovery (PITR) to any second within the retention window. By restoring to a timestamp between 10:00 and 10:30 UTC, you recover the database to a state before the corruption occurred, without affecting the current production instance. This minimizes risk to the running workload because the restore creates a new DB instance, leaving the original untouched until you are ready to switch.

Making payment processing idempotent using an idempotency key ensures that even if the same message is delivered multiple times due to at-least-once delivery semantics, the charge is applied only once. The consumer records a unique key (e.g., payment ID) in a durable store (like DynamoDB or Redis) and checks it before processing; if the key already exists, the charge is skipped. This directly prevents duplicate charges while still allowing safe retries, as the consumer can safely reprocess messages without side effects.

Enabling S3 versioning protects against accidental overwrites and deletes by preserving all object versions, while cross-Region replication (CRR) asynchronously replicates objects to a bucket in another Region, providing recovery from a full Region outage. With versioning enabled, CRR replicates both current and previous object versions, meeting the ~1-hour RPO (typically within minutes for new objects) and ensuring data durability across Regions.

Amazon SQS standard queues provide at-least-once delivery, ensuring every event is processed at least once, with the possibility of duplicates. Designing consumers to be idempotent handles duplicates without requiring custom scripts, aligning with the requirement to avoid operational overhead. This approach is serverless, scalable, and fits the warehouse integration use case.

A Lambda dead-letter queue (DLQ) or failure destination allows you to capture events that have exhausted all retry attempts from an asynchronous invocation. This ensures failed events are retained in Amazon SQS or SNS for later investigation, providing enforceable control during normal operations without impacting the function's ability to process successful events.

A failover routing policy is correct because it allows you to designate one record as primary and another as secondary. Route 53 will route traffic to the primary record as long as it is healthy, and automatically fail over to the secondary record when the primary is unhealthy. This directly meets the requirement to send new clients to the primary region when healthy and fail over to the secondary region.

The resilient pattern is to spread stateless compute across multiple Availability Zones and let the existing Regional Network Load Balancer route to whichever targets are healthy. Because the load balancer already has nodes in every enabled zone, adding an Auto Scaling group that spans zones gives the surviving zone capacity to absorb traffic, and cross-zone load balancing keeps distribution even. Session state already lives in ElastiCache, so no failover logic is needed in the application.

A dead-letter queue (DLQ) with an appropriate maxReceiveCount is the correct AWS-native solution for handling poison messages. When a message is repeatedly received from an SQS queue but fails processing, it is considered a poison message. By configuring a DLQ and setting a maxReceiveCount (e.g., 3 or 5), the message is automatically moved to the DLQ after exceeding that threshold, preventing it from blocking further retries and allowing the main queue to process valid messages.

Amazon SQS is the correct choice because it acts as a durable, fully managed message buffer that decouples the web tier from the fulfilment workers. When bursts of orders arrive, SQS queues the messages and allows workers to poll at their own pace, absorbing spikes without data loss. The built-in retry logic (visibility timeout and dead-letter queue) ensures failed processing attempts are automatically retried, and no custom operational scripts are needed.

Cross-Region Replication is the purpose-built S3 capability for maintaining an automatically updated, readable object copy in a different Region, and its asynchronous replication latency generally falls well inside a 15-minute window. Versioning on both buckets is a prerequisite, so the architect must enable it as part of the design. The other choices either keep data in one Region, move data only between storage classes, or route requests without creating a second copy.

DynamoDB is a fully managed, multi-AZ key-value store, so a single Availability Zone failure does not interrupt service and no database servers are managed. Global tables replicate data across Regions so users read from a nearby replica with low latency, and on-demand capacity removes the need to provision throughput, meeting both resilience and performance goals.

Route 53 failover routing allows you to create a primary record with an associated health check for Region A and a secondary record for Region B. When the health check for Region A fails, Route 53 automatically returns the secondary record's IP address, directing traffic to Region B. This directly meets the requirement for automatic failover based on application reachability.

S3 Cross-Region Replication is the AWS feature that asynchronously copies new and updated objects to a bucket in another Region. S3 Replication Time Control adds an SLA that 99.99% of objects replicate within 15 minutes, matching the compliance window. Disabling DeleteMarkerReplication keeps the destination copy intact when the source object is deleted, which is exactly the retention behaviour the compliance team requires.

Resilience against an Availability Zone failure for a stateless fleet is achieved by distributing capacity across multiple Availability Zones and letting the Auto Scaling group replace unhealthy instances using load balancer health checks. A single multi-AZ Auto Scaling group behind one Application Load Balancer with cross-zone load balancing delivers this with minimal operational effort, while still supporting CPU-based scaling.

Aurora Global Database is the correct choice because it provides a fully managed cross-Region disaster recovery solution with a typical RPO of 1 second or less, using storage-based replication that does not require custom scripts. This meets the low RPO requirement while avoiding operational overhead, as replication is handled automatically by the Aurora storage layer.

To withstand a Region failure with automatic failover, the application must be deployed in at least two Regions. Route 53 failover routing with health checks automatically redirects traffic to the secondary Region when the primary is unhealthy. This minimizes operational overhead because the failover is managed by Route 53 and does not require manual intervention.

For a stateful application that cannot be re-architected immediately, the practical resilience pattern is to run warmed instances in more than two Availability Zones so that a single zone loss leaves sufficient capacity already serving traffic. Warm-up and grace period settings are essential because they stop the Auto Scaling group from killing instances that are still rebuilding their in-memory caches, which would otherwise produce repeated restarts and prolonged unavailability.

The application is failing writes because it is connecting to the old writer instance's endpoint, which is no longer the writer after failover. The Aurora cluster writer endpoint is a DNS name that always points to the current primary (writer) instance, regardless of failovers. By using the cluster writer endpoint, the application automatically connects to the new writer after failover, eliminating the need to manually update connection strings.

Amazon S3 Standard is designed for 99.999999999% durability and automatically replicates data across multiple Availability Zones within a Region. It supports concurrent writes from multiple EC2 instances and is a cost-effective solution for storing and retrieving logs. This meets the durability and availability requirements.

Adding subnets from a second Availability Zone to both the ALB and the Auto Scaling group distributes the application across multiple AZs. This ensures that if one AZ fails, the ALB can route traffic to healthy targets in the remaining AZ, and the Auto Scaling group can maintain capacity by launching instances in the surviving AZ. This approach directly addresses the requirement to continue serving requests during an AZ failure with minimal operational complexity.

Health-checked load balancing is the mechanism that detects an unresponsive instance and removes it from the traffic path automatically. Because the tier is stateless and already spans three Availability Zones, the Application Load Balancer can shift requests to remaining healthy instances while the Auto Scaling group replaces the failed one.

The core problem is that both the application and database reside in a single Availability Zone. Relocating the database to Amazon RDS with Multi-AZ deployment gives automatic failover and removes database server management, while running the application in a multi-AZ Auto Scaling group provides compute redundancy. Together these changes let the application survive a zonal failure with minimal rework.

Making the payment workflow idempotent ensures that even if the same SQS Standard message is processed more than once (due to a visibility timeout), the duplicate charge is prevented by checking a unique order key before processing. This is the most robust solution for handling at-least-once delivery semantics of Standard queues without changing the queue architecture.

Point-in-time recovery (PITR) allows you to restore the RDS instance to any second within the backup retention window, such as just before the faulty migration at 10:00 UTC. This restores a complete, consistent database state, minimizing data loss and avoiding manual row-by-row recovery. Swapping application connectivity to the restored instance is the least disruptive approach, as it avoids complex manual data merging and reduces downtime.

The Aurora cluster writer endpoint is a DNS name that always resolves to the current writer instance in the cluster, even after a failover. By using this endpoint instead of a hard-coded instance-specific endpoint, the application automatically reconnects to the new writer without manual intervention, directly improving resiliency.

Making the consumer idempotent ensures that even if the same message is processed more than once (due to a timeout after the charge is submitted but before the message is deleted), the duplicate charge will be rejected. By storing a processed payment key (e.g., a unique transaction ID) and checking it before processing, the system can safely retry without causing duplicate payments. This approach preserves retry behavior while preventing duplicates, which is the core requirement.

These pairs match architecture elements with their resilience behaviors for surviving an Availability Zone failure, focusing on AWS services that provide high availability and fault tolerance.

Aurora Global Database is designed for cross-Region disaster recovery with a typical RPO of 1 second or less, using storage-based replication that does not impact database performance. It provides fast failover to a secondary Region and allows the primary Region to enforce write control during normal operations, meeting the low RPO and enforceable control requirements.

Zone resilience for the compute tier comes from running instances across multiple Availability Zones behind a load balancer, so a single zone loss does not remove all capacity. Accidental table deletion is mitigated by enabling point-in-time recovery, which allows restore to a recent point in time, and by restricting who holds the delete-table permission so the mistake is far less likely to recur.

Amazon EFS provides a fully managed, POSIX-compliant NFS file system that can be mounted concurrently on multiple Linux EC2 instances across different Availability Zones. By creating mount targets in each AZ, the file system remains accessible even if one AZ fails, because the other mount targets continue to serve traffic. EFS also supports lifecycle policies and IAM enforcement to control access during normal operations, meeting the requirement for enforceable control.

Enabling S3 versioning protects against accidental overwrites by preserving all object versions, allowing recovery of previous versions. Configuring Cross-Region Replication (CRR) automatically replicates objects to a destination bucket in another AWS Region, providing disaster recovery by maintaining a copy of the data in a separate geographic location.

Resilience across an Availability Zone failure requires both compute capacity in the surviving zones and durable, externalized job state. Distributing the Auto Scaling group across three zones keeps instances running, while an SQS queue with visibility timeouts and DynamoDB progress tracking lets interrupted jobs be reclaimed and retried automatically. This removes any dependency on the failed zone's instances or storage.

AWS Backup can create hourly snapshots of EBS volumes and copy them to a different AWS Region, meeting the 1-hour RPO by ensuring backups are taken every hour. S3 Cross-Region Replication (CRR) asynchronously replicates objects to a bucket in another region, keeping data synchronized within minutes and supporting the RPO. Amazon Route 53 with a failover routing policy and health checks can automatically redirect traffic to the DR region within seconds to minutes, enabling the 15-minute RTO by quickly failing over to pre-prepared infrastructure.

A dead-letter queue (DLQ) with a redrive policy is the correct solution because it allows messages that repeatedly fail processing to be moved to a separate queue after exceeding the maxReceiveCount. This isolates problematic messages for later investigation without blocking the main queue or causing infinite retries. The consumer catches the exception, so the message is not deleted and is returned to the queue for redelivery; the DLQ ensures that after a configurable number of attempts, the message is redirected instead of being retried indefinitely.