RDS Multi AZ practice questions

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.

Immediately reboot the RDS instance and rely on the reboot to roll back the bad writes.

Why wrong: Rebooting an Amazon RDS instance primarily restarts the underlying operating system and database engine processes. While it can resolve some operational issues by clearing memory caches and reinitializing services, it does not provide a mechanism to logically roll back committed transactions or undo incorrect writes that have already been persisted to storage. Committed data remains durable across reboots, making this action ineffective for recovering from application-level data corruption.

Create a new Read Replica from the current primary and use it as the recovered database after applying reverse migrations.

Why wrong: A read replica copies the current state, including the bad writes. Reverse migrations are an application-level strategy and are not equivalent to restoring to an earlier transaction time (and may not correctly undo all effects).

Temporarily disable Multi-AZ to speed up storage rollback, then re-enable Multi-AZ.

Why wrong: Disabling Multi-AZ for an Amazon RDS instance is a configuration change that removes the synchronous standby replica, reducing high availability and failover capabilities. Multi-AZ is designed for disaster recovery and automatic failover in case of an Availability Zone outage or primary instance failure, not for data recovery from logical errors like incorrect writes. There is no "storage rollback" feature associated with Multi-AZ, and disabling it would only increase downtime risk without addressing the data corruption.

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.

Use the same partition key (customerId), but increase the table’s provisioned capacity for that tenant.

Why wrong: Increasing provisioned capacity can raise the overall throughput ceiling, but DynamoDB throttling for a hot partition is driven by per-partition limits (and uneven item/key distribution), not just by the table’s total capacity. If nearly all ACME writes still target the same partition (same customerId value), that single partition can remain the bottleneck, so throttling and p99 latency can persist during spikes.

Switch to on-demand capacity mode and keep the partition key unchanged.

Why wrong: On-demand capacity automatically scales the table’s overall capacity, but it does not remove per-partition request limits. If all ACME traffic still targets one partition key value, that partition can still become hot and throttle, so p99 latency and ProvisionedThroughputExceeded events can continue during spikes.

Enable Global Tables so that reads are served from a nearby replica for ACME.

Why wrong: Global Tables can reduce network latency and improve availability across regions, but they do not address hot partitions within a region. If ACME’s writes concentrate on a single partition key value, the corresponding partition in each replica can still be the throttling bottleneck for that tenant.

Deploy the Aurora cluster with a single DB instance to reduce complexity and cost.

Why wrong: Deploying an Aurora cluster with only a single DB instance, even if it's the primary writer, significantly compromises high availability. If that single instance or its underlying Availability Zone experiences an outage, the database will become unavailable, leading to application downtime. While it might reduce immediate cost, it fails to meet the requirement for a highly available and resilient architecture.

Place the EC2 instances in a single Availability Zone to ensure data locality with the primary database.

Why wrong: Placing all EC2 instances in a single Availability Zone creates a single point of failure, directly contradicting the goal of a highly available and resilient architecture. While it might offer marginal latency benefits for data locality, the risk of a complete application outage if that specific AZ experiences an issue far outweighs any perceived advantage. High availability mandates distribution across multiple AZs.

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.

S3 Cross-Region Replication

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

EBS snapshots every hour

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

Read replicas only

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

Keep the same key design and increase only the table’s provisioned RCUs and WCUs.

Why wrong: More capacity can help only if the workload is broadly distributed. A single hot partition key can still bottleneck even when table capacity is raised. This option does not change the skewed access pattern that is causing throttling on one partition.

Replace the table reads with a Scan operation to distribute the load across all partitions.

Why wrong: A Scan reads many items and is far more expensive and slower than a targeted Query. It would increase latency and consume more capacity, not reduce it. Scans are not a solution for a hot key or for low-latency repeated reads.

Move the table to another Availability Zone so the hot tenant uses a different storage node.

Why wrong: DynamoDB is a regional service and its partitioning behavior is not solved by picking a different AZ. The issue is logical data skew, not a single-AZ placement problem. Moving the table would not change the hot partition key pattern.

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.

Multi-AZ RDS primary failure: Requires manual promotion of a read replica

Why wrong: This statement is incorrect because Amazon RDS Multi-AZ deployments are specifically designed for automatic failover. Upon detecting a primary instance failure, AWS automatically switches the DNS record to a synchronously replicated standby instance in another Availability Zone, eliminating the need for manual promotion or intervention. Manual promotion is characteristic of single-AZ RDS with read replicas, not Multi-AZ.

RDS primary failure with read replicas: Automatically fails over to an Aurora replica

Why wrong: This option incorrectly mixes different database technologies and failover mechanisms. Amazon RDS read replicas are used with traditional MySQL, PostgreSQL, etc., and require manual promotion upon primary failure. Furthermore, an "Aurora replica" is a component of an Amazon Aurora cluster, which is a distinct database engine and does not interoperate directly with standard RDS read replicas for failover.

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 wrong: 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 wrong: 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.

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.

Backup and restore only, relying on scheduled snapshots and manual restores during incidents.

Why wrong: Backup/restore can meet data-loss tolerance in some cases, but RTO of 1 hour is often too aggressive for manual restores.

Pilot light, keeping only minimal infrastructure in the secondary Region and starting full services after failover.

Why wrong: Pilot light is cheaper, but RTO of 1 hour may not be achievable if full compute/services must be brought up from near-zero.

Active/active, routing production traffic to both Regions continuously and accepting dual-region complexity.

Why wrong: Active/active best fits very low RTO and high availability, but it usually costs more than the stated budget constraints.

S3 lifecycle policy

Why wrong: Lifecycle policies manage object storage cost, not RDS read load.

Multi-AZ standby and route reads to the standby

Why wrong: The Multi-AZ standby is not used for normal read scaling.

A larger NAT gateway

Why wrong: NAT throughput does not solve database read contention.

Increase the EC2 instance size and keep all application servers in the same subnet.

Why wrong: Bigger instances add capacity, but they do not protect against the entire Availability Zone becoming unavailable.

Replace the Application Load Balancer with a Network Load Balancer in a single Availability Zone.

Why wrong: A single-AZ load balancer still leaves the application vulnerable to an AZ outage and does not add redundant capacity.

Add an Amazon RDS read replica and point the application to the replica endpoint.

Why wrong: Read replicas help with read scaling, but they are not a direct replacement for automatic writer failover in this scenario.