Disaster Recovery practice questions

A single-AZ Aurora cluster

Why it fails: A single-AZ Aurora cluster operates entirely within one Availability Zone in a single Region, so it cannot protect against a Regional disaster. While Aurora's storage engine inherently replicates data six ways across three AZs for high availability within a Region, this does nothing to provide cross-Region failover or recovery. If the entire Region becomes unavailable, the cluster is unreachable and you would have to restore from backups, leading to a high RTO and no true DR capability.

An ElastiCache Redis replica

Why it fails: An ElastiCache Redis replica is an in-memory key/value cache, not a durable relational database and not an Aurora DR mechanism. It does not natively integrate with Aurora's replication or failover, and any data written into the cache would be lost on restart, making it unsuitable as a recovery point. Using it to serve reads would require application-level cache warm-up and synchronization, and it cannot be promoted to become the source of truth for the Aurora database.

Manual snapshots copied monthly

Why it fails: Manually copying Aurora snapshots to another Region once a month introduces a maximum RPO of 30 days, because any transactions committed after the snapshot are lost. Restoring a snapshot into a new Aurora cluster can also take tens of minutes or longer, resulting in a high RTO. This approach also requires operational effort to trigger and track copies, and it does not provide any automated failover or continuous replication, so it fails to meet the requirement for fast disaster recovery.

Wait for AWS to automatically fail over the read replica to become the new primary

Why it fails: AWS does not automatically fail over cross-region read replicas. While Multi-AZ deployments do provide automatic same-region failover to a standby, a cross-region replica is intended only for manual promotion during DR, which requires a deliberate API call and connection-string updates. Waiting for AWS to auto-failover will leave the primary and replica in a stalled state and applications unavailable.

Restore the primary database from the most recent automated snapshot in us-west-2

Why it fails: Restoring the primary from the most recent automated snapshot is inferior because automated snapshots are typically taken once or a few times per day, whereas the read replica continuously applies changes from the primary, leaving a much smaller recovery point objective (RPO). Additionally, automated snapshots are stored in the source region (us-east-1) by default; unless cross-region snapshot copy is enabled, the snapshot isn't even available in us-west-2. Restoring a snapshot would require copying it first and would still yield data as of the snapshot time, losing hours of committed transactions.

Create a new RDS instance in us-west-2 and manually restore data from application logs

Why it fails: Manually rebuilding from application logs is not a valid RDS disaster recovery path because application logs capture business events, not the transactional database changes needed to reconstruct table state. Even if you had a full backup, replaying logs would be an error-prone manual process and would still lose transactions committed after the log cutoff. The existing read replica already contains a near-current, MySQL/Postgres-compatible copy of the production database, so using it is far faster and more reliable.

S3 lifecycle transition to Glacier Flexible Retrieval

Why it fails: S3 Lifecycle transitions alter the storage class of objects within the same bucket and Region; they never move data to a different geographic location. While Glacier Flexible Retrieval offers low-cost archival storage, it does not provide a redundant copy in another Region, so it cannot meet a cross-Region disaster recovery requirement. To copy objects to a second Region, you must use replication, not a lifecycle rule.

An EBS snapshot schedule

Why it fails: EBS snapshots are point-in-time backups of Amazon Elastic Block Store volumes, which are block-level storage attached to EC2 instances. They have no effect on objects stored in Amazon S3, and they cannot move or copy data between Regions for S3-based content. Since the ticket system stores documents in S3, configuring an EBS snapshot schedule is entirely outside the scope of the data being protected.

A CloudFront distribution

Why it fails: A CloudFront distribution caches content at edge locations worldwide, improving latency and reducing load on the origin, but it is not a durable storage copy that persists independently. If the origin S3 bucket is deleted or the source Region experiences a disaster, CloudFront edge caches are not a reliable backup and do not provide cross-Region data replication. CloudFront is a content delivery service, not a disaster recovery replication mechanism.

Enable S3 lifecycle policies to automatically move objects to Glacier after 30 days only.

Why it fails: Lifecycle policies that transition objects to Glacier after 30 days only reduce storage costs by moving data to cold storage, but they do not protect against accidental overwrites or deletes. Without versioning, a write or delete permanently replaces or removes the only copy, and Glacier's retrieval times make rapid recovery impractical. Additionally, this approach lacks any cross-Region copy, so it does not provide resilience against an entire Region becoming unavailable.

Disable all versioning and rely on AWS Backup to restore objects from a scheduled backup window.

Why it fails: Disabling versioning removes the ability to recover from accidental overwrites or deletes because old object states are immediately discarded. AWS Backup can restore objects from scheduled snapshots, but the backup window and restore process introduce significant RPO and RTO, meaning recent changes may be lost and recovery could take hours. Versioning provides near-instant, per-object rollback that backups cannot match, and the lack of replication still leaves the data vulnerable to Regional failures.

Enable S3 Block Public Access and SSE-S3 encryption, without using versioning or replication.

Why it fails: Block Public Access and SSE-S3 encryption are security controls that prevent unauthorized public access and encrypt data at rest, but they do not address data resilience. These features do not create additional object versions, nor do they replicate data across Regions, so an overwrite, delete, or Regional outage still results in permanent loss. Security and encryption are necessary for protecting data from threats, but they are independent of availability and recovery requirements.

Active-active

Why it fails: Active-active (multi-site active-active) serves live production traffic from two or more Regions simultaneously, requiring full application stacks, synchronized data, and global traffic routing in every location. This architecture therefore multiplies infrastructure and operational costs, introduces data-conflict and consistency challenges, and is far more expensive than the minimal-footprint approach the requirement is asking for. If the business need is only to survive a regional outage with reduced cost, active-active over-provisions for that goal.

Single-AZ deployment

Why it fails: A single-AZ deployment places all resources within one Availability Zone, which is a physically isolated data center facility inside a single Region. Because an entire Region sustains an outage—for example, a natural disaster or loss of utility power affecting all AZs—this topology has no capacity to fail over to another geographic location. Even if you mitigate with multi-AZ replication, you remain confined to that one Region and cannot meet the protection requirement.

Blue/green deployment

Why it fails: Blue/green deployment is a release-management technique where two identical environments coexist and traffic is switched from the current 'blue' version to the new 'green' version after validation. It does not by itself create any geographically distributed standby architecture, nor does it include data replication or failover mechanisms to another Region. While it enables rapid rollback and zero-downtime application updates, it is not a disaster recovery strategy and cannot address a full Region outage.

Pilot light, because only the database needs to be running in the secondary Region.

Why it fails: Pilot light keeps only a minimal set of components active in the secondary Region. In this exhibit, the database replica is already current, but the measured recovery time still exceeds the RTO because the application tier must be started from zero.

Active-active, because both Regions should always serve traffic to guarantee the RTO.

Why it fails: Active-active can provide very fast recovery, but it requires both Regions to run at production scale and introduces significant operational complexity. The requirement asks for the least always-on cost, so this is more than necessary.

Backup and restore, because restoring from backups is the least expensive DR model available.

Why it fails: Backup and restore is the lowest-cost disaster recovery model, but it is the slowest to recover. In this scenario, the measured recovery time already exceeds the 15-minute RTO at 18 minutes even with a warm database replica, and a true backup/restore approach would require rehydrating snapshots, rebuilding EC2 instances, and redeploying the application stack—typically taking hours, not minutes. It would also introduce RPO risk because any data changes after the last backup would be lost, making it unsuitable for this workload's recovery objectives.

Configure an AWS Lambda function triggered by S3 event notifications to copy each object to the destination bucket.

Why it fails: A Lambda-based copy works but introduces custom code that must be maintained, monitored, and error-handled. It also may not meet the 15-minute window under heavy load or if the function fails. This approach has higher operational overhead than a managed replication feature and is less reliable for disaster recovery.

Use AWS DataSync to schedule a recurring task that synchronizes the source bucket to the destination bucket every 15 minutes.

Why it fails: DataSync is designed for large-scale data movement between on-premises storage and AWS, or between AWS storage services, but it is not event-driven. A scheduled task every 15 minutes may miss the window and requires managing task execution and reporting. It adds operational overhead and does not provide near-real-time replication.

Enable S3 Same-Region Replication (SRR) to a bucket in us-east-1, then use S3 Batch Operations to copy objects to us-west-2 nightly.

Why it fails: Same-Region Replication only replicates within the same Region, so it does not provide cross-Region disaster recovery. A nightly batch copy is far too slow to meet a 15-minute objective and requires manual job creation and monitoring. This combination does not satisfy the cross-Region and timeliness requirements.

A single-AZ Aurora cluster

Why it fails: A single-AZ Aurora cluster confines all database instances to one Availability Zone within a single Region, providing no cross-Region redundancy. Although Aurora's distributed storage maintains six copies across three AZs, those copies all reside in the same Region, so a regional outage takes the entire database offline. This design offers local high availability but cannot meet the requirement for fast cross-Region disaster recovery.

An ElastiCache Redis replica

Why it fails: An ElastiCache Redis replica is an in-memory data store, not a persistent replica of Aurora's transactional data. It does not receive Aurora's binlog or storage-level updates, and it cannot be promoted to a database writer, so it provides no failover or data recovery capability. While it can cache reads and improve performance, it is entirely irrelevant as a disaster recovery mechanism for Aurora MySQL.

Manual snapshots copied monthly

Why it fails: Manually copying snapshots monthly means the most recent recoverable data is up to 30 days old, resulting in an RPO of up to a month, which is unacceptable for a ticket booking system. Restoring a snapshot to a new cluster involves provisioning and warm-up delays that commonly take tens of minutes or more, yielding a poor RTO. Furthermore, manual snapshot restore requires manual orchestration and traffic redirection, so it cannot deliver the fast, automated failover the requirement demands.

S3 lifecycle transition to Glacier Flexible Retrieval

Why it fails: An S3 lifecycle rule that transitions objects to Glacier Flexible Retrieval only changes the storage class of existing objects within the same bucket and geographic Region. It does not create a second copy in another Region, nor does it protect against regional loss or bucket deletion. While it lowers storage costs for archival data, it is not a disaster recovery mechanism and offers no replication or failover capability.

An EBS snapshot schedule

Why it fails: EBS snapshot schedules capture point-in-time backups of Amazon EBS volumes, not S3 objects. Although those snapshots are physically stored in S3 as private block-level images, they cannot be used to restore individual uploaded documents, and the schedule does not replicate S3 bucket content across Regions. Therefore, this option provides no disaster recovery benefit for the ticket booking system's S3-based document storage.

A CloudFront distribution

Why it fails: A CloudFront distribution places cached copies of S3 objects at edge locations for lower latency, but it is not a durable, independent copy of the data. CloudFront's cache expires based on configurable TTLs, and if the origin S3 bucket is lost or deleted, the edge caches are not a reliable source for recovery. Using CloudFront alone does not replicate data across Regions and therefore does not fulfill the requirement for disaster recovery.

A single-AZ Aurora cluster

Why it fails: A single-AZ Aurora cluster confines all cluster resources to one Availability Zone (and one region), so while Aurora's storage engine replicates data locally, there is no data copy or running instance in another Region. In a region-wide outage, the cluster remains unavailable and there is no standby in a different region to fail over to, making it unsuitable for cross-region DR scenarios.

Manual snapshots copied monthly

Why it fails: Manual snapshots taken monthly and copied to another Region provide an RPO of up to one month, meaning you could lose nearly a month of trading data. Recovery from a snapshot requires restoring an entire DB cluster from the snapshot, then re-configuring applications, which can take tens of minutes or longer, resulting in a high RTO. This does not meet the 'fast' DR requirement since both RPO and RTO are very poor.

An ElastiCache Redis replica

Why it fails: ElastiCache Redis is an in-memory data store, not a database replication mechanism for Aurora. It cannot accept writes from Aurora's storage engine, nor can it be promoted to replace an Aurora primary; it serves only as a cache in front of an existing database. Using a Redis replica does not provide any form of Aurora disaster recovery because the cached data is ephemeral and not a durable copy of the Aurora MySQL database.

An EBS snapshot schedule

Why it fails: An EBS snapshot schedule automates point-in-time backups of Amazon EBS volumes attached to EC2 instances, capturing block-level data rather than individual S3 objects. Since S3 is a managed object store with its own 99.999999999% durability model, EBS snapshots have no mechanism to scan, copy, or protect objects in S3 buckets, so they cannot provide the required cross-region DR copy.

S3 lifecycle transition to Glacier Flexible Retrieval

Why it fails: An S3 lifecycle rule can transition objects to S3 Glacier Flexible Retrieval after a specified age to reduce storage costs, but it keeps the objects in the same S3 bucket and the same AWS Region. The objects remain in the original Region, so if that Region becomes unavailable, the documents are still unavailable for retrieval. Glacier Flexible Retrieval provides low-cost archival storage, not geographic redundancy.

A CloudFront distribution

Why it fails: CloudFront is a global content delivery network that caches objects at edge locations near viewers to improve latency and reduce origin load, but those edge caches are ephemeral and are not a durable backup copy. It cannot replicate objects to a second S3 bucket for DR, and cached content can be evicted or expire. Therefore, a CloudFront distribution alone does not satisfy a cross-region disaster recovery requirement.

A single-AZ Aurora cluster

Why it fails: A single-AZ Aurora cluster stores all its data and replicas in one Availability Zone within a single Region. It provides high availability across AZs only if you choose Multi-AZ, but a single-AZ deployment has no cross-Region replication and no mechanism to fail over to another geographic location. Thus it cannot satisfy the requirement for fast remote recovery after a regional outage; all writes and reads remain tied to that one Region.

An ElastiCache Redis replica

Why it fails: An ElastiCache Redis replica is an in-memory cache, not a durable or authoritative database, and it is not part of Aurora's replication topology. It can speed up read-heavy workloads by caching frequently accessed data, but it does not replicate Aurora's transactional data or provide a database failover target. Relying on it for DR would lose committed writes and fail to satisfy RPO/RTO requirements for a ticket booking system.

Manual snapshots copied monthly

Why it fails: Manual snapshots copied monthly produce a very high RPO — up to a month of lost ticket bookings — and require time-consuming restore operations before the database is usable. Although snapshots can be copied to another Region, recovery would involve restoring a full DB cluster and replaying any subsequent binary logs, which is slow and operationally complex. This approach does not meet the need for fast failover or low data loss, making it unsuitable compared to Aurora Global Database.

An EBS snapshot schedule

Why it fails: EBS snapshots capture block volumes in a single Region and cannot copy S3 objects, which are not stored on EBS. It is tempting because snapshot schedules are a familiar backup mechanism, and they would be correct when protecting EC2 instance volumes rather than an S3 bucket.

S3 lifecycle transition to Glacier Flexible Retrieval

Why it fails: A lifecycle transition moves objects between storage classes within one Region; it never creates a cross-Region copy, so the disaster-recovery requirement stays unmet. It is tempting because lifecycle rules do automate data movement, and they would be correct when the goal is cost reduction through colder storage tiers.

A CloudFront distribution

Why it fails: CloudFront caches content at edge locations for low-latency delivery; it does not replicate objects into a second Region, so no cross-Region copy exists. It is tempting as a global content-delivery service, and it would be correct when the requirement is accelerating access to static assets for distributed users.

A single-AZ Aurora cluster

Why it fails: A single-AZ Aurora cluster, even with Aurora's multiple storage nodes, only spans Availability Zones within one AWS Region; it does not replicate any data to another Region. While it can provide high availability by creating Aurora Replicas in different AZs, those replicas share the same regional storage and failover is contained to that Region. If the entire Region suffers a disaster, the single-AZ cluster becomes unreachable and data is not recoverable elsewhere, so it fundamentally lacks the cross-Region DR capability required for this scenario.

An ElastiCache Redis replica

Why it fails: ElastiCache Redis is an in-memory data store used to cache frequent reads or session data, not a database replication mechanism for Aurora. It does not persist transactional records from the ticket booking system, nor does it contain the underlying Aurora database files; therefore, it cannot be promoted to a primary database or used to restore lost data. Redis replication merely maintains copies of the cache across nodes for cache availability, which is separate from and cannot substitute for Aurora's cross-Region disaster recovery.

Manual snapshots copied monthly

Why it fails: Manual snapshots copied monthly produce an RPO of up to 30 days because they only capture a point-in-time state that is renewed monthly. To recover, you would need to restore a new Aurora cluster from the freshest snapshot, which takes substantial time for large databases and can lose every transaction made since that snapshot. This approach fails the 'fast' requirement of the ticket booking system, as RTO would be measured in hours or longer, and RPO would be unacceptably high for a production system that needs continuous availability.

Set up Amazon RDS Multi-AZ deployment to enable automatic failover to a standby replica in a different Availability Zone within the primary Region.

Why it fails: While Amazon RDS Multi-AZ deployments provide high availability and automatic failover within a single AWS Region, they do not protect against a regional disaster. If the entire primary AWS Region becomes unavailable, the Multi-AZ standby replica in a different Availability Zone within that same region would also be affected, failing to meet the multi-region disaster recovery requirement.

Use an Amazon RDS for MySQL single-AZ deployment in the primary Region and take daily snapshots copied to the secondary Region.

Why it fails: A single-AZ RDS deployment lacks high availability within the primary region, making it vulnerable to AZ failures. Furthermore, relying on daily snapshots for multi-region disaster recovery results in a high Recovery Point Objective (RPO), meaning up to 24 hours of data could be lost. The manual restoration process from snapshots also leads to a high Recovery Time Objective (RTO), making this approach unsuitable for robust DR.

Backup and restore only, with no continuously running infrastructure in the secondary Region.

Why it fails: Backup and restore in disaster recovery stores data snapshots or databases in the secondary Region (e.g., S3 cross-Region replication, EBS snapshots, RDS snapshots) but has absolutely no running infrastructure there. To recover, you must rebuild the entire environment from scratch—creating EC2 instances, installing software, restoring data, and validating the system—which normally takes many hours or even days, far exceeding the 6-hour RTO. Additionally, data loss is potentially higher because RPO is tied to the last backup or replication cycle, while the lack of pre-provisioned resources makes RTO unpredictable.

Pilot light, keeping only the minimum resources needed to bootstrap the environment.

Why it fails: Pilot light keeps only the most critical infrastructure running—such as a replicated database and a minimal compute core—while the rest of the application stack remains stopped. When a disaster occurs, you must deploy and configure all application servers, load balancers, and auxiliary services before scaling to full capacity; this bootstrap process can easily consume most or all of the 6-hour RTO window, especially for a complex retail platform. Because only base resources are warm, it provides faster recovery than backup-and-restore but still risks missing a strict recovery time objective.

Multi-site active-active, serving production traffic from both Regions at all times.

Why it fails: Multi-site active-active serves production traffic concurrently from both Regions, which demands full capacity in each location and active-active database replication (e.g., DynamoDB global tables or multi-writer Aurora) to handle writes from both sides. Running and operating two full production environments continuously is substantially more expensive and operationally complex than needed for a disaster recovery plan, and it introduces challenges like conflict resolution, data consistency, and cross-Region latency that are overkill for meeting a 6-hour RTO.

Backup & Restore: RPO seconds, RTO minutes

Why it fails: The Backup & Restore strategy fundamentally relies on periodic data backups, which inherently leads to an RPO measured in hours, not seconds. Furthermore, the extensive process of provisioning new infrastructure and restoring data from backups means the RTO is typically 24 hours or more, making a recovery time of minutes unachievable for this method.

Multi-Site Active/Active: RPO hours, RTO 24+ hours

Why it fails: This option is incorrect as the Multi-Site Active/Active strategy is designed for maximum availability and minimal disruption. It employs synchronous data replication and active traffic distribution across multiple regions, which inherently results in a near-zero RPO and RTO. An RPO of hours and an RTO of 24+ hours are characteristic of the least resilient Backup & Restore strategy, not an active/active setup.

Pre-provision EC2 instances in the disaster recovery region and keep them running 24/7.

Why it fails: Pre-provisioning and continuously running EC2 instances in a disaster recovery region represents a 'hot standby' strategy. While this approach offers the lowest possible Recovery Time Objective (RTO), it is significantly more expensive due to the ongoing operational costs of maintaining duplicate, fully scaled infrastructure 24/7. For many applications, a more cost-effective strategy like pilot light or warm standby can achieve acceptable RTOs without such high expenditure.

Store Amazon Machine Images (AMIs) in the source region and use AWS Lambda to copy them after a disaster.

Why it fails: Storing Amazon Machine Images (AMIs) only in the source region and attempting to copy them via AWS Lambda *after* a disaster introduces significant delays, severely impacting the Recovery Time Objective (RTO). AMIs are region-specific, and for an effective disaster recovery strategy, pre-copying or regularly replicating AMIs to the DR region is essential. Relying on post-disaster replication would prolong recovery efforts unnecessarily.

Set up an AWS Direct Connect link between the primary and DR regions for faster data transfer.

Why it fails: AWS Direct Connect establishes a dedicated, private network connection from an on-premises data center directly to AWS. It is designed for hybrid cloud architectures, not for inter-region connectivity *between* two AWS Regions. Data transfer and communication between different AWS Regions occur over the highly resilient AWS global network, often utilizing services like VPC peering or AWS Transit Gateway, making Direct Connect irrelevant for this specific inter-region DR scenario.

Move all objects to S3 Glacier Instant Retrieval and apply a lifecycle policy to keep only the latest object copy.

Why it fails: S3 Glacier Instant Retrieval is an archive storage class designed for long-lived data with millisecond access, but it has no inherent versioning, deletion protection, or cross-Region redundancy. Applying a lifecycle rule to keep only the latest object copy would actually purge all older versions (if any existed) and the single remaining copy is still vulnerable to deletion or a Regional outage. This option intentionally discards historical versions, contradicting the requirement to retain previous versions for recovery.

Use S3 server-side encryption with KMS keys and rely on access logs to manually recover the deleted objects.

Why it fails: Server-side encryption with AWS KMS (SSE-KMS) protects object confidentiality by encrypting data at rest, but it does not increase durability and has no mechanism to protect against deletion or to store history. S3 access logs can confirm that a DELETE request was made and by whom, yet logs record request metadata, not object contents, so they cannot rebuild the deleted file's bytes. Without versioning or replication, the original uploads are gone forever, making this a security-monitoring aid rather than a data recovery solution.

Enable S3 bucket policies that deny DeleteObject, but do not enable versioning or replication.

Why it fails: A bucket policy that denies s3:DeleteObject can block ordinary IAM users from issuing deletes, but it cannot prevent deletes from the AWS account root user, lifecycle expirations, or a compromised administrative role, so it only narrows some future mistakes. Because versioning is not enabled, the currently deleted objects were permanently removed and no prior copy exists to restore. Without replication, there is also no second Region copy, so the policy provides neither recovery for existing deletions nor resilience against a regional failure.