CCNA Design Resilient Questions

DynamoDB automatically replicates data across multiple Availability Zones within an AWS Region, providing high availability and durability. Enabling point-in-time recovery (PITR) allows restoration to any point in time within the last 35 days, protecting against accidental writes or deletions. This solution meets both the durability and recovery requirements without additional complexity.

S3 Cross-Region Replication asynchronously copies objects to a bucket in another Region, and versioning is required for replication. With typical replication times well under 15 minutes, this meets the RPO and provides a target bucket that can be used within the 1-hour RTO.

An Auto Scaling group spanning both Availability Zones automatically replaces instances in the surviving AZ when one AZ fails, and ALB health checks remove failed targets. This provides resilience without manual intervention, directly satisfying the compliance requirement for AZ failure tolerance.

Amazon SQS standard queues guarantee at-least-once delivery, so no event is lost, and duplicates are possible; consumers must therefore be idempotent. This satisfies the stated requirement that duplicate processing is acceptable if consumers handle idempotency.

Amazon RDS point-in-time recovery (PITR) restores a new DB instance to any fraction of a second within the backup retention window by replaying transaction logs from the last automated snapshot. Launching a separate instance preserves the production database untouched, allowing you to validate the restored data at 90 minutes ago before promoting it and updating the application connection string. After approval, you can cut over by renaming the instances or changing the DNS endpoint, minimizing downtime and risk.

Enabling Elastic Load Balancing health checks on the Auto Scaling group means the group uses the load balancer's health status rather than only EC2 status checks, so instances that fail application-level checks are replaced. This ensures automatic recovery from unhealthy instances, which is the second requirement. The target group health check defines what the load balancer considers healthy.

Spreading the Auto Scaling group across multiple Availability Zones lets the load balancer route to healthy instances when one zone fails, and Multi-AZ RDS maintains a synchronous standby in another zone with automatic failover to the same endpoint. Together these provide automatic, hands-off recovery for both compute and database tiers.

A public ACM certificate that includes the apex domain and a wildcard covers all current and future tenant subdomains, and DNS validation allows ACM to renew the certificate automatically as long as the validation records remain in place. Attaching it to the Application Load Balancer HTTPS listener provides TLS termination without redeploying the application when tenants are added.

A Multi-AZ RDS deployment keeps a synchronous standby in another Availability Zone and automatically fails over when the primary fails. This matches the requirement for minimal manual intervention and preserves the same database endpoint, so the application does not need connection string changes. It is the standard AWS choice for resilient relational databases.

Aurora Global Database is the correct choice because it uses storage-based replication to synchronize data across multiple AWS Regions with a typical latency of under one second. It supports up to five secondary Regions, and when a regional failure occurs, you can promote a secondary Region to primary in about a minute, giving you a very low RPO and RTO for fast disaster recovery. This managed feature also enables low-latency global reads and automatic failover, making it vastly superior to any snapshot-based approach.

Amazon EFS is a regional, managed NFS file system that provides standard POSIX file semantics, including file locking and consistent reads/writes, making it ideal for concurrent access from many EC2 instances. By configuring mount targets in multiple Availability Zones, the service achieves high availability and fault tolerance while instances in any AZ can access the same shared file data.

Configuring a Dead-Letter Queue (DLQ) with a redrive policy is the most effective solution. This mechanism automatically moves messages that fail processing a specified number of times (maxReceiveCount) from the source queue to the DLQ. This prevents 'poison pill' messages from continuously consuming worker resources and allows for their isolation, analysis, and eventual reprocessing or discarding without impacting the main message flow.

Amazon SQS is a fully managed message queue that decouples order-producing services from warehouse processing consumers. It durably stores messages, allowing bursts of orders to be buffered while consumers poll and process at a controlled rate, and it supports retries via visibility timeout and dead-letter queues for failed processing. This makes SQS the correct choice for absorbing spikes and ensuring no order is lost during high demand.

S3 Cross-Region Replication automatically replicates objects to a bucket in another Region asynchronously, typically within minutes. It requires versioning on both buckets and an IAM role. Once configured, it operates with no additional infrastructure, providing low operational overhead and meeting the 15-minute replication goal for most objects.

Multi-AZ maintains a synchronous standby replica in a second Availability Zone; on AZ failure, RDS automatically promotes it and repoints the DNS endpoint, typically within 60–120 seconds. Because the application reconnects via the same endpoint, no code changes are needed, satisfying the in-Region automatic failover and minimal-change constraints.

Route 53 failover routing implements an active-passive pattern by defining a primary record (the desired region) paired with a health check that continuously verifies endpoint availability. When that health check returns an unhealthy status, Route 53 automatically removes the primary record from the response and answers DNS queries with the secondary (failover) record, which also has its own health check settings to ensure the backup is truly reachable. This gives you deterministic, health-driven failover where all traffic shifts to the secondary region after the primary's health check fails, exactly matching the requirement.

Aurora Global Database is the correct answer because it replicates MySQL data at the storage layer to up to five secondary AWS Regions with typical replication latency under one second. This enables a promoted secondary cluster to become the primary in minutes, yielding a Recovery Time Objective (RTO) of roughly 1–2 minutes and a Recovery Point Objective (RPO) measured in seconds. Unlike snapshot-based backups, this is continuous, automatic replication that keeps the ticket booking system’s data nearly current in the disaster recovery Region, making it the only option that satisfies fast DR while preserving data consistency at scale.

S3 Cross-Region Replication requires versioning enabled on both the source and destination buckets and asynchronously replicates every new object upload to a chosen destination Region. This creates a geographically separate, durable copy of the trading dashboard's documents, satisfying disaster-recovery requirements without manual intervention. Versioning is also essential because CRR relies on object version IDs to track replication state and to replicate delete markers or overwrites consistently.

Aurora Replicas in different Availability Zones provide redundant read capacity, and the cluster reader endpoint automatically distributes connections across healthy replicas. If a zone fails, Aurora removes the affected replica from the endpoint, so the application keeps reading without changing connection strings, satisfying the low-overhead and no-reconfiguration requirements.

This sequencing avoids a “no healthy targets” window. By keeping capacity stable (or maintaining a minimum healthy percentage) and waiting for the new instances to be marked healthy by the ALB, traffic is only sent to healthy targets during replacement.

A dead-letter queue with an appropriate maxReceiveCount is the formal SQS mechanism for poison messages. When a message is received more times than the configured threshold (e.g., 5), SQS automatically moves it to the DLQ using the source queue's redrive policy, isolating it from normal traffic. This lets the main queue continue processing healthy messages, while engineers can inspect and debug the quarantined messages later without disrupting the workflow.

Amazon EBS volumes are network-attached block storage that persists independently of the instance and remains available across stop and start operations within the same Availability Zone. Data is retained when the host is replaced, which directly fixes the loss the team observed. This is the standard persistent storage choice for EC2 databases.

Deploying an Auto Scaling group across subnets in at least two Availability Zones (AZs) is the core of high availability. Each AZ is an isolated failure domain, so if one AZ fails, the ASG continues to run instances in the other AZ(es). Coupled with ELB or ASG health checks, the group automatically detects unhealthy instances—whether due to EC2 failure or AZ impairment—and replaces them, maintaining desired capacity and absorbing request traffic. This design avoids any single point of failure at both the compute and network layers.

Bucket versioning preserves every object revision, so an accidental overwrite creates a new version while the prior data remains intact, and a delete merely adds a delete marker rather than erasing the object. This directly satisfies the stem's requirement to protect the daily financial exports against accidental overwrite or deletion.

Amazon SQS decouples ingestion from database writes, absorbing traffic spikes as a buffer while the processing function consumes at a controlled rate. It also enables safe retries via visibility timeouts and dead-letter queues, preventing duplicate order records and timeouts.

Promoting the us-west-2 read replica is the correct DR procedure. Promotion converts the read replica into a standalone writable DB instance, and because the replica continuously replays transactions from the primary, it typically has only seconds of lag. After promotion, applications must update their connection strings to the new endpoint in us-west-2. This is the standard, lowest-RPO approach for cross-region failover.

Idempotency ensures that repeated deliveries of the same instruction do not cause repeated side effects. By persisting a record keyed by instruction ID (or enforcing a unique constraint in a transactional store), the service can detect duplicates and safely skip or reconcile them even if SQS redelivers the message.

Route 53 failover routing (primary/secondary) is designed for active-passive regional DR. When the primary health check fails, Route 53 automatically stops returning the primary alias and returns the secondary alias target; attaching health checks ensures the change is driven by the /status endpoint health.

Route 53 failover routing with health checks monitors the primary endpoint and automatically redirects DNS queries to the secondary record when it becomes unhealthy. This satisfies the automatic failover requirement, and the routing policy remains enforceable during normal operations.

Aurora global database replicates data to a secondary Region with a typical latency of under one second, meeting the 1-second RPO. Failover to the secondary Region can be completed in under a minute, meeting the 1-minute RTO. This is the only option that provides both low RPO and low RTO across Regions for MySQL-compatible workloads.

Warm standby keeps core services and a scaled-down but functional environment running in the secondary Region with continuous replication, achieving the 15-minute RPO and roughly one-hour RTO. It avoids the cost of full duplicate capacity while remaining far faster than a rebuild.

Cross-zone load balancing on a Network Load Balancer distributes traffic evenly across registered targets in every enabled Availability Zone, so a single impaired zone does not concentrate load on the surviving instances. With targets registered in all three zones, the load balancer's health checks automatically remove unhealthy targets and continue routing to the rest. This delivers both even connection distribution and unattended zone-failure tolerance.

ElastiCache for Redis with Multi-AZ provides automatic failover to a replica in another AZ, and the session data is externalized from the EC2 instances. When an instance is replaced, it can retrieve the session from the Redis cluster, so users remain authenticated. This design decouples session state from the compute layer and survives an AZ failure.

A Multi-AZ RDS deployment provides synchronous standby replication in another Availability Zone and automatic failover if the primary AZ becomes unavailable. This directly matches the requirement to keep the database serving after an AZ failure. It is the simplest resilient design change when the application needs high availability rather than just backups.

CloudFront caching with appropriate TTLs is correct because it stores static content at edge locations, allowing the website to be served to users from cache even when the S3 origin is temporarily unavailable. As long as the TTL has not expired, users experience no interruption, and the cached content provides a buffer against origin outages. This makes the service more resilient, provided the TTL balances freshness and availability.

Point-in-time restore is the correct recovery method when automated backups are enabled and the team needs the database just before a known corruption event. Restoring to 10:29 UTC brings the data back to the last safe moment before the migration began. Creating a new instance first avoids modifying the damaged database until the restored copy is validated.

Using SQS as a buffer between the event source and Lambda is correct because SQS decouples event producers from the consumer, smoothing traffic spikes by buffering messages until Lambda can poll them. The visibility timeout provides built-in retry logic: if Lambda fails to process a message, it becomes visible again for another attempt, and after a configured Maximum Receives threshold, the message is automatically diverted to a dead-letter queue for later analysis. This pattern ensures that no order event is lost, supports backpressure, and lets you isolate recurring processing failures without disrupting the continuous flow of valid events.

RDS Multi-AZ creates a synchronous standby replica in a separate Availability Zone and automatically flips the DNS endpoint to the standby within seconds if the primary instance fails, a network partition occurs, or an AZ becomes unavailable. This is the only option that provides true high availability with no manual intervention, making it the correct answer because it directly addresses resilience to an entire Availability Zone failure.

Placing subnets in at least two Availability Zones (AZs) and attaching health checks to the Auto Scaling group allows the group to detect and replace unhealthy instances while maintaining desired capacity across AZs. If one AZ fails, the remaining healthy instances in the other AZ continue serving traffic, and Auto Scaling launches new instances in the surviving AZs to compensate. Health checks (ELB or EC2 status checks) drive the replacement process, and distributing subnets across AZs makes the architecture resilient to both instance-level and AZ-level failures, which is the key requirement for a fault-tolerant trading dashboard.

Cross-Region Replication copies objects asynchronously to a bucket in another AWS Region, satisfying the disaster-recovery constraint. Versioning must be enabled on both source and destination because replication requires it to track object versions and propagate deletions or overwrites correctly.

With target group health checks enabled and configured correctly, the ALB evaluates each target's health and stops routing requests to targets marked unhealthy. As long as healthy targets exist in the other AZ, the ALB preserves reachability.

Route 53 failover routing with health checks is the control-plane mechanism that implements active-passive regional failover. You configure a primary record with a health check that probes the primary endpoint's HTTP or TCP status, and a secondary record pointing to the standby region; when the health check fails, Route 53 stops returning the primary and starts resolving to the standby. The health check must be created separately and attached to the primary record set, and low TTLs or alias records are recommended so DNS clients quickly pick up the failed-over answer.

An Auto Scaling group spanning all three Availability Zones keeps capacity balanced across zones and, with ELB health checks enabled, automatically terminates and replaces instances that fail load balancer health checks. If one Availability Zone fails, the group launches replacement capacity in the remaining zones without operator involvement, which is exactly the resilience the scenario requires.

Idempotency ensures that repeated processing attempts produce the same result. The consumer should use a stable idempotency key (for example, a business transaction ID) and record completion in durable storage. If the key already indicates the payment succeeded, the consumer skips charging again.

Configuring a Lambda dead-letter queue (DLQ) or an asynchronous failure destination is the correct solution because Lambda will automatically send events that have exhausted built-in retries to a specified SQS queue, SNS topic, or other destination. This preserves the failed event payload and metadata, enabling you to inspect, replay, or alert on the failure. For asynchronous invocations, this is the standard pattern for building resilient, observable serverless workflows.

Distributing the Auto Scaling group across two Availability Zones and attaching the load balancer to subnets in both zones lets the fleet continue serving traffic if one zone fails. The load balancer health checks remove unhealthy instances automatically, and the group replaces them, so the workload survives the loss without manual action.

Amazon S3 is a regional service with high durability, so intermediate files survive an Availability Zone failure. An Auto Scaling group spanning multiple Availability Zones replaces failed instances automatically, and new instances can read the intermediate files from the S3 bucket. This meets both the resilience and minimal data loss requirements.

Configuring a dead-letter queue (an SQS queue or SNS topic) or an asynchronous failure destination causes Lambda to route the event to that target after the configured retry attempts are exhausted. The original event payload is preserved in the DLQ or delivered to a destination such as SQS, SNS, EventBridge, or another Lambda function, allowing operators to inspect and later reprocess the failed inventory events. This is the correct mechanism for capturing failed asynchronous invocations for analysis.

RDS Multi-AZ failover preserves the database endpoint name, not the underlying IP address. When the standby is promoted, AWS updates the DNS record to point to the new primary. Using the RDS endpoint allows the application to follow that change, and retry logic helps the client recover from the short disconnect that occurs during failover.

A dead-letter queue (SQS/SNS) or a failure destination is the correct mechanism because Lambda, after exhausting its default two retries, can route the original event payload to a configured target. A DLQ preserves the raw event and allows a separate process to consume, inspect, and reprocess it, while a failure destination offers richer metadata, such as the request ID and response context, and can send to SQS, SNS, Lambda, or EventBridge. This gives a durable record of failed async invocations and decouples error handling from the main processing function.

This makes Auto Scaling replace instances that fail the load balancer health check even when EC2 status checks still pass. The exhibit shows the application health endpoint returns 500 while EC2 checks remain passing, so EC2-only health checks miss the failure. ELB-based health checks align replacement with real application availability.

Deletion protection blocks table deletion outright, satisfying the accidental-delete requirement with a managed AWS-native control needing no custom tooling. Pair it with point-in-time recovery for continuous backups, enabling restore to any second within the 35-day window and meeting the low RPO.

Aurora Global Database replicates storage across Regions with typical lag under one second, giving low RPO and rapid promotion of a secondary Region to primary during disaster recovery. Single-Region Aurora replicas cannot deliver cross-Region failover at that recovery speed.

An Auto Scaling group spanning multiple Availability Zones distributes instances across AZs, so the application survives an AZ failure. An Application Load Balancer distributes traffic and performs health checks, routing only to healthy instances. This provides both high availability and horizontal scalability, directly addressing the requirements with minimal changes.

SNS delivers the message independently to each subscribed SQS queue. If downstream B fails to process a message, B can avoid deleting it from its own queue; after visibility timeout and retry attempts, SQS redrives messages to B’s DLQ. A and C are isolated because they have separate queues and DLQs, so B’s failures do not prevent deliveries to A and C.

Spreading the ASG across subnets in two Availability Zones removes the single-AZ failure domain, so the ALB can route to healthy targets in the surviving zone during maintenance. Pointing health checks at an application-ready path ensures instances register only when genuinely serving traffic, preventing the timeouts seen previously.

SQS Standard provides at-least-once delivery, so duplicates are expected. Idempotency ensures that re-processing the same instruction does not create incorrect side effects. Persisting a deterministic key/result allows the consumer to safely short-circuit duplicates after retries/timeouts.

A Multi-AZ deployment is the correct RDS feature for availability because Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone within the same Region. The primary DB instance writes data synchronously to the standby before committing, and if the primary fails or its AZ becomes unavailable, RDS automatically performs failover to the standby by updating the DNS endpoint, typically within 60–120 seconds without requiring manual intervention. This eliminates the need for application-level failover logic and provides a clear improvement in availability for an RDS MySQL instance.

Point-in-time restore uses the automated backups and transaction logs to rebuild the database to an exact time before the bad change. The exhibit confirms the requested restore time is within the restorable window, and the business wants to validate the restored copy before switching traffic. Restoring to a new instance first is the safest way to recover without risking the current production database.

Amazon SQS standard queues provide durable storage across multiple Availability Zones and at-least-once delivery, meaning every message is guaranteed to be delivered eventually, but duplicates can occasionally occur due to the distributed architecture. Consumers must be idempotent so that processing the same event multiple times has the same effect as processing it once, preventing duplicate medical records or actions. This design satisfies the requirement while maintaining the high throughput needed by a patient portal.

A DLQ with a redrive policy isolates poison messages. After a message is received and fails processing more than the configured maxReceiveCount, SQS moves it to the DLQ, preventing it from continually blocking retries in the source queue.

Deploying subnets (and therefore EC2 instances) in at least two Availability Zones removes any single AZ as a point of failure. An Auto Scaling group distributed across those subnets works with a load balancer's health checks to detect unhealthy instances, terminate them, and launch replacement capacity in a healthy AZ. If one AZ fails entirely, the ASG can continue to meet desired capacity in the surviving AZ and the load balancer routes traffic away from unhealthy targets, keeping the dashboard available.

Failover routing is the Route 53 policy intended for this use case. Route 53 returns the primary record while its health check passes, and automatically serves the secondary record when the primary health check fails. That provides DNS-based Regional failover without manual intervention.

Compliance mode enforces a write-once-read-many model in which no principal, including the root user, can overwrite or delete a locked object version before the retention date expires. Objects stay readable throughout the period, satisfying the availability clause. A 30-day retention directly matches the stated recovery window, and the protection is enforced by S3 itself rather than by policy that could be changed.

Amazon EFS is a fully managed, regional file storage service that provides a standard POSIX file system interface (NFSv4.1) for EC2 instances. By configuring mount targets in multiple Availability Zones, instances across the VPC can concurrently read and write to the same file system with shared file locking and metadata guarantees. This architecture delivers both high availability and elastic scalability, making it the appropriate shared storage layer for a warehouse integration service that must be accessed by multiple compute resources simultaneously.

An AZ outage reduces the number of AZs where the ASG can place instances. With only two AZs, losing one significantly limits capacity and can cause temporary shortages and uneven load distribution, even if existing targets are marked healthy. Expanding the ASG to subnets in three (or more) AZs provides additional placement options so the ASG can maintain the desired number of instances across the remaining AZ(s). The ALB will continue routing only to healthy targets, and the system is more likely to sustain stable response times during the outage.

Amazon SQS is a fully managed message queue that decouples the order ingestion service from the backend workers. Producers send order messages to the queue, and consumers poll messages at their own sustainable rate, which naturally absorbs bursts—the queue itself acts as a temporary, durable buffer. The visibility timeout ensures in-flight messages are not processed by multiple workers, and a dead-letter queue captures poison messages after repeated failures. Because SQS retains messages for up to 14 days and integrates with Auto Scaling via the ApproximateNumberOfMessages metric, it is the correct service for handling unpredictable spikes in order volume.

Using an Amazon SQS standard queue meets the at-least-once requirement: SQS stores messages durably across multiple Availability Zones and redelivers any message that is not deleted before the visibility timeout expires, so every event is processed at least once. Because standard queues can occasionally deliver duplicate copies, your consumer design must be idempotent—e.g., by tracking a unique event ID or a deterministic processing key—so that repeated handling of the same event does not corrupt patient data. This combination gives you high throughput, operational simplicity, and no single point of failure, which is why it is the correct choice.

Deletion protection is a DynamoDB table attribute that blocks DeleteTable operations until explicitly disabled, while tightly scoped IAM policies that deny dynamodb:DeleteTable reduce the risk of a single misissued CLI command or console action taking down a payments table. Without this guard, an accidental deletion is immediate and permanent, taking all data, indexes, and backup history with it. It is therefore a required complement to backup features.

Route 53 failover routing is designed specifically for active-passive failover: you create two alias records pointing to the two ALBs, one marked PRIMARY and the other SECONDARY, each with an associated health check. Under normal conditions, Route 53 returns the PRIMARY record, but if that record's health check fails, Route 53 automatically stops returning it and returns the SECONDARY record instead. This gives the company an automated, DNS-level failover that does not depend on client latency, manual weight changes, or client-side load balancing.

Because SQS Standard is at-least-once, the consumer must assume duplicates are possible. Persisting a record keyed by paymentInstructionId (or using a database unique constraint) lets the consumer detect that a given instruction was already processed successfully and safely skip the charge or merge results deterministically.

Spreading the Auto Scaling group across subnets in at least two Availability Zones with health checks enabled ensures instances in a surviving AZ absorb traffic when one fails. This satisfies the requirement to tolerate a single AZ failure using AWS-native controls.

SQS provides at-least-once delivery, meaning the same message can be delivered to a consumer more than once, especially during network timeouts or consumer crashes. An idempotent handler design ensures that processing a duplicate message does not cause duplicate side effects, such as creating duplicate database records or processing the same payment twice. This is typically achieved by storing a unique message identifier or business key and checking for prior processing before executing the business logic. Idempotency is the fundamental corrective control for SQS's inherent lack of exactly-once semantics.