RDS Multi AZ practice questions

Single-AZ DB deployment and rely on manual snapshot restore during failures.

Why wrong: Single-AZ deployments do not provide an always-on standby in another AZ. Manual snapshot restore is a recovery process that requires intervention and is typically not an automatic failover to an AZ-level standby.

Enable read replicas only, and promote a replica manually when the primary fails.

Why wrong: Read replicas are for scaling reads and do not provide the same high-availability failover behavior as Multi-AZ deployments. Manual promotion adds recovery time and does not meet the automatic failover requirement.

Enable point-in-time recovery (PITR) without configuring any Multi-AZ standby.

Why wrong: PITR helps recover from logical mistakes (for example, accidental writes/deletes) by restoring data to an earlier time, but it does not provide an automatically available standby in another AZ for failover.

Use an RDS single-AZ instance and periodically restore from automated backups if needed.

Why wrong: Single-AZ deployments do not provide automatic failover for an AZ outage. Restoring from backups requires manual or scripted intervention, increasing downtime.

Create a read replica in a different AZ and use it only when the primary fails.

Why wrong: A read replica does not automatically replace a failed primary instance. You would need manual promotion and application rerouting.

Use RDS with Multi-AZ disabled, but increase storage IOPS to prevent failover.

Why wrong: Performance changes do not address AZ availability. Storage IOPS does not provide automatic failover capabilities during an Availability Zone outage.

S3 Cross-Region Replication

Why wrong: S3 CRR applies to S3 objects, not RDS failover.

Read replicas only

Why wrong: Read replicas improve read scalability and can support DR, but they are not the primary automatic AZ failover feature.

EBS snapshots every hour

Why wrong: Snapshots help recovery but do not provide automatic high availability.

S3 Cross-Region Replication

Why wrong: S3 CRR applies to S3 objects, not RDS failover.

Read replicas only

Why wrong: Read replicas improve read scalability and can support DR, but they are not the primary automatic AZ failover feature.

EBS snapshots every hour

Why wrong: Snapshots help recovery but do not provide automatic high availability.

The database remains unavailable until an administrator manually creates a new instance.

Why wrong: Manual recreation is not how Multi-AZ is designed to recover from a primary failure.

Traffic is routed to a read replica in another Region for immediate continuity.

Why wrong: A read replica is not the same as a Multi-AZ standby, and another Region is a disaster recovery pattern.

The failed primary continues serving traffic while the standby synchronizes in the background.

Why wrong: A failed primary cannot continue serving traffic; the standby becomes active after failover.

Create a read replica in a different Availability Zone and configure the application to fail over manually.

Why wrong: Read replicas improve read scaling, but manual failover and replication lag can still harm failover objectives.

Switch the database to use EBS snapshots more frequently and restore in case of failure.

Why wrong: Snapshot restore is a backup/recovery approach and typically does not meet fast failover requirements.

Pin the DB to a specific instance type with higher CPU credits to prevent CPU-related disconnects.

Why wrong: Instance sizing affects performance but not AZ-level failover behavior or redundancy.

Switch the table to on-demand capacity mode so DynamoDB automatically removes partition limits.

Why wrong: On-demand mode simplifies capacity management, but it does not remove the physical partition throughput limits of a hot key.

Use a larger sort key attribute to increase the maximum write throughput for the tenant.

Why wrong: Sort key size does not change partition-level throughput, so it does not solve the hot partition bottleneck.

Move the table to a single larger provisioned throughput setting and keep the same key design.

Why wrong: Raising table capacity without changing the access pattern still leaves one partition overloaded by the same tenant key.

The standby instance can serve production read traffic to improve read scaling in standard RDS Multi-AZ.

Why wrong: In standard RDS Multi-AZ, the standby exists for high availability and failover, not for serving application reads. Read scaling requires a different pattern, such as read replicas or Aurora reader endpoints.

The application must permanently change its connection string to a new host after failover completes.

Why wrong: RDS uses the same database endpoint for the Multi-AZ deployment, so applications do not need to hardcode a new host after failover. The endpoint name stays stable, which reduces recovery complexity.

Multi-AZ provides protection against a full Region outage without any additional design changes.

Why wrong: Multi-AZ improves availability within a single Region, but it is not a regional disaster recovery solution. A full Region outage requires a multi-Region strategy such as pilot light, warm standby, or active-active.

Disable automated backups to reduce the time needed for failover.

Why wrong: Automated backups do not slow down RDS failover, and disabling them removes point-in-time recovery and other restore options. Backups are a recovery control, not a failover bottleneck.

Use a single-AZ deployment so the standby is not split across Zones.

Why wrong: A single-AZ deployment has no standby instance in another Availability Zone, so it cannot provide automatic failover for an instance or AZ failure. It is less resilient than Multi-AZ.

Replace the database with an Amazon S3 bucket and store rows as objects.

Why wrong: Amazon S3 is object storage, not a relational database engine. It does not provide transactional relational semantics or database-style automatic failover for this workload.

Add a read replica and promote it manually during an outage.

Why wrong: Incorrect. Read replicas are primarily for read scaling and disaster recovery patterns that usually require operational intervention. Manual promotion does not satisfy automatic failover, and it introduces more downtime and more runbook steps than a Multi-AZ deployment.

Store the current DB instance IP address in the application configuration file.

Why wrong: Incorrect. Hard-coding the IP address couples the application to one underlying instance and breaks the abstraction RDS provides. Failover changes the active instance, so the IP would become stale and connectivity would fail instead of recovering automatically.

Rely on nightly snapshots because they provide automatic failover to another Availability Zone.

Why wrong: Incorrect. Automated backups and snapshots are for point-in-time recovery and long-term restore, not live failover. They do not keep a standby database ready to take over immediately when the primary instance becomes unavailable.

Keep the deployment as single-AZ, but increase automated backup retention to 35 days.

Why wrong: Increasing backup retention improves point-in-time recovery and recovery from mistakes, but it does not create a standby instance in another AZ. It does not provide automatic failover when the primary instance fails.

Create a read replica in another Availability Zone, but keep Multi-AZ disabled.

Why wrong: A read replica provides additional read capacity and offloading, but it is not the same as the managed Multi-AZ synchronous standby used for automatic failover. Read replicas generally do not provide the same automated promotion behavior for the primary endpoint during an AZ outage.

Rely on restoring from the most recent manual snapshot after an outage.

Why wrong: Restoring from a snapshot is a manual recovery step and typically takes longer than an automated failover. It does not meet the requirement for automatic failover with minimal downtime.

Backup and restore only, because the existing daily backups are already in another Region.

Why wrong: Backup and restore typically takes too long to rebuild the environment and recover data for a 45-minute RTO, especially when application tiers and databases both need to be restored and validated.

Pilot light, because the recovery Region only needs minimal resources and can be scaled after a disaster.

Why wrong: Pilot light keeps only core components running in the recovery Region. That is cheaper, but it usually requires too much time to scale and activate the full stack to meet a 45-minute RTO.

Active-active, because it minimizes RTO by keeping both Regions fully live all the time.

Why wrong: Active-active provides the fastest recovery, but it is typically the most expensive option because both Regions must be fully provisioned and operating all the time. That conflicts with the stated budget constraint.

Create a read replica in another Availability Zone and promote it manually if needed.

Why wrong: A read replica can help with read scaling or disaster recovery, but manual promotion is not the same as automatic failover. It adds operational delay.

Increase the automated backup retention period to 30 days.

Why wrong: Longer backup retention helps with recovery from deletion or corruption, but it does not keep the database online during an Availability Zone failure. Backups are not failover.

Resize the DB instance to a larger class.

Why wrong: A larger instance may improve performance, but it does not protect against the loss of the Availability Zone. The same single point of failure would remain.

Keep tenantId as the partition key and rely on DynamoDB adaptive capacity to automatically remove all throttling.

Why wrong: Adaptive capacity may help with some workloads, but it cannot eliminate the fundamental issue when a single partition key (tenantId) receives sustained traffic beyond that partition’s throughput. For a hot tenant, you still need to distribute writes across multiple physical partitions.

Change the sort key to eventTimeBucket (for example, eventTime rounded to 1-minute buckets) while keeping the partition key as tenantId.

Why wrong: Changing only the sort key does not resolve hot partition issues because the partition key (tenantId) still concentrates all writes for that tenant into a single partition. DynamoDB distributes capacity primarily by partition key, not sort key.

Enable DAX and use it for write operations so throttled writes are served from cache instead of reaching DynamoDB.

Why wrong: DAX is a read-through cache designed to accelerate reads, not to absorb write throughput or bypass DynamoDB write capacity limits. Throttling on writes occurs before any cached read path, so DAX does not address the hot-partition write bottleneck.

Create a read replica in the same Availability Zone as the primary database.

Why wrong: A read replica helps with read scaling and some recovery scenarios, but it does not provide automatic failover like a Multi-AZ deployment.

Increase the backup retention period to 35 days.

Why wrong: Longer backups improve recovery options, but they do not provide automatic failover during an outage. Backups are still a restore-based process.

Move the database to an EC2 instance with an attached EBS volume.

Why wrong: Running the database on EC2 adds operational burden and usually reduces managed failover capability compared with RDS Multi-AZ.

Keep the read replica and automate promotion with a runbook after CloudWatch alarms fire.

Why wrong: Automation helps, but the underlying architecture still relies on manual-style promotion of an asynchronous replica rather than built-in high availability.

Use a cross-Region read replica so promotion happens faster during an AZ failure.

Why wrong: Cross-Region replication adds distance and is intended for disaster recovery, not fast automatic failover within one Region.

Increase the application retry count and keep the current database design.

Why wrong: Retries can hide brief transient failures, but they do not fix the manual promotion delay or the architecture’s failover characteristics.

Enable DynamoDB Streams so the table can process writes more quickly.

Why wrong: Streams capture changes after writes succeed, but they do not change partition distribution or write capacity pressure. The hot partition would still throttle under the same traffic pattern.

Switch the table to on-demand capacity mode and keep the same key design.

Why wrong: On-demand mode can absorb variable load, but it does not solve a single partition becoming hot. A skewed key can still throttle even when total table capacity increases automatically.

Add a global secondary index on eventTime and query the index instead of the base table.

Why wrong: A GSI changes the access pattern, but it still needs a well-distributed partition key. Indexing only by eventTime would not preserve tenant-scoped lookups and could introduce a new hot partition.

Switch from RDS Single-AZ to RDS Multi-AZ, keeping the EC2 instances in only AZ-a because failover will still reach them.

Why wrong: RDS failover helps database availability, but the observed checkout delay stems from lack of compute capacity in the impaired AZ.

Terminate the ALB and use a Network Load Balancer (NLB) in front of the existing single-AZ EC2 instances.

Why wrong: Changing load balancer type does not fix the dependency on instances only in AZ-a, so recovery will still be impacted.

Add more EC2 instances in AZ-a and increase the ALB health check thresholds to avoid unnecessary replacements during impairments.

Why wrong: Overprovisioning in a single AZ reduces but does not eliminate unavailability when that AZ is degraded and cannot serve traffic.

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

Why wrong: RDS cross-region read replicas do not automatically failover. Manual promotion is required. Only Multi-AZ provides automatic same-region failover.

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

Why wrong: The read replica is more current than a daily snapshot and is faster to promote. Snapshot restoration is the last resort when no replica exists.

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

Why wrong: Manually restoring data from application logs is not a valid DR procedure. Use the read replica which already contains synchronized production data.

Increase only the sort-key cardinality while leaving the partition key unchanged.

Why wrong: Incorrect because DynamoDB partitions primarily on the partition key. More sort-key variation does not distribute traffic across partitions when the same hot partition key still receives the load.

Move the table to the Standard-IA table class because throttling is usually caused by storage class selection.

Why wrong: Incorrect because table class affects storage cost and some access costs, not hot-partition distribution. It does not relieve a tenant-specific throughput bottleneck caused by an overloaded partition key.