RDS Multi AZ practice questions

A database administrator needs to ensure that an Amazon RDS for MySQL instance can withstand an Availability Zone failure and provide low-latency reads for a reporting application. Which TWO steps should be taken?

Trap 1: Use EBS Snapshots to back up the database every 5 minutes.

While snapshots are important for disaster recovery, they do not provide high availability or low-latency reads. Restoring from a snapshot is a manual process that takes time, and taking snapshots every 5 minutes would create significant performance overhead on the database. It is not a replacement for the automated failover provided by Multi-AZ.

Trap 2: Enable Enhanced Monitoring with a 1-second granularity.

Enhanced Monitoring provides detailed metrics about the OS and processes running on the RDS instance. While helpful for troubleshooting performance issues, it does not contribute to the resilience of the database or provide any mechanisms for surviving an Availability Zone failure. It is a monitoring tool rather than an architectural availability feature.

Trap 3: Implement a Network Load Balancer in front of the RDS instance.

Network Load Balancers are used to distribute traffic to EC2 instances or IP addresses, but they are not typically used in front of Amazon RDS. RDS handles its own DNS-based failover for Multi-AZ. Adding an NLB would introduce unnecessary complexity and is not a standard or recommended practice for managing RDS database connections.

A
Enable Multi-AZ deployment for the RDS instance.
Multi-AZ deployment is the standard feature for high availability in Amazon RDS. It creates a standby instance in a different Availability Zone and uses synchronous replication. In the event of a failure, RDS automatically fails over to the standby, ensuring the database remains available without manual intervention or data loss during the transition.
B
Create a Read Replica in a different Availability Zone.
Read Replicas allow you to scale out read-heavy workloads by providing an asynchronous copy of the primary database. By placing a Read Replica in a different AZ, you provide the reporting application with a dedicated endpoint for queries, reducing the load on the primary instance and improving overall application performance and latency.
C
Use EBS Snapshots to back up the database every 5 minutes.
Why it fails: While snapshots are important for disaster recovery, they do not provide high availability or low-latency reads. Restoring from a snapshot is a manual process that takes time, and taking snapshots every 5 minutes would create significant performance overhead on the database. It is not a replacement for the automated failover provided by Multi-AZ.
D
Enable Enhanced Monitoring with a 1-second granularity.
Why it fails: Enhanced Monitoring provides detailed metrics about the OS and processes running on the RDS instance. While helpful for troubleshooting performance issues, it does not contribute to the resilience of the database or provide any mechanisms for surviving an Availability Zone failure. It is a monitoring tool rather than an architectural availability feature.
E
Implement a Network Load Balancer in front of the RDS instance.
Why it fails: Network Load Balancers are used to distribute traffic to EC2 instances or IP addresses, but they are not typically used in front of Amazon RDS. RDS handles its own DNS-based failover for Multi-AZ. Adding an NLB would introduce unnecessary complexity and is not a standard or recommended practice for managing RDS database connections.

Question 2hardmultiple choice

Refer to the exhibit. The web application is showing high latency and 503 errors. The database CPU usage is low. What is the most likely cause and solution?

Exhibit

{
  "log_entry": "[ERROR] Database connection pool exhausted. Waiting for available connection.",
  "status": "503 Service Unavailable",
  "latency": "4500ms"
}

Trap 1: Increase the RDS instance size to handle more connections.

Increasing the instance size does not resolve connection exhaustion if the application code is not managing connections properly. The bottleneck is the connection pool management, not the CPU or memory resources. RDS Proxy is the purpose-built solution to handle database connection pooling and multiplexing effectively.

Trap 2: Enable Multi-AZ failover to distribute the load.

Multi-AZ is for high availability and failover, not for load balancing connections. Enabling it will not fix connection pool exhaustion. The database still has a limit on the number of concurrent connections it can support, and Multi-AZ does not provide additional read/write endpoints for connection pooling.

Trap 3: Add more read replicas to the RDS cluster.

Read replicas are used to scale read traffic, not to manage application connection pools. Each replica has its own connection limits, and adding them won't solve the issue of connection exhaustion on the primary instance. RDS Proxy is required to handle the underlying connection pool architecture properly.

A
Increase the RDS instance size to handle more connections.
Why it fails: Increasing the instance size does not resolve connection exhaustion if the application code is not managing connections properly. The bottleneck is the connection pool management, not the CPU or memory resources. RDS Proxy is the purpose-built solution to handle database connection pooling and multiplexing effectively.
B
Implement Amazon RDS Proxy for connection pooling.
RDS Proxy sits between the application and the database, managing a pool of connections and reusing them. This prevents connection exhaustion at the database level and ensures that the application doesn't experience wait times for new connections. It is the ideal solution for high-concurrency, connection-intensive database workloads.
C
Enable Multi-AZ failover to distribute the load.
Why it fails: Multi-AZ is for high availability and failover, not for load balancing connections. Enabling it will not fix connection pool exhaustion. The database still has a limit on the number of concurrent connections it can support, and Multi-AZ does not provide additional read/write endpoints for connection pooling.
D
Add more read replicas to the RDS cluster.
Why it fails: Read replicas are used to scale read traffic, not to manage application connection pools. Each replica has its own connection limits, and adding them won't solve the issue of connection exhaustion on the primary instance. RDS Proxy is required to handle the underlying connection pool architecture properly.

Question 3hardmulti select

A company is migrating a high-traffic web application to AWS. The application uses an Amazon RDS for MySQL database. The database experience high read pressure during business hours, but write activity remains consistent and low. Which TWO architectural changes will reduce costs while maintaining performance? (Select TWO.)

Trap 1: Scale up the primary RDS instance to a larger instance class with…

Scaling up the primary instance is a vertical scaling strategy that increases the cost of the entire database 24/7. Since the write activity is low, paying for a larger instance just to handle peak read traffic is inefficient compared to using Read Replicas, which can be scaled more granularly.

Trap 2: Switch the database to Amazon RDS for SQL Server to take advantage…

Switching to SQL Server from MySQL would likely increase costs due to licensing fees and architectural changes. MySQL is an open-source engine with no licensing costs. Moving to a commercial engine would be counterproductive for a project specifically focused on reducing the overall cost of the database layer.

Trap 3: Enable Multi-AZ for all Read Replicas to ensure high availability.

Enabling Multi-AZ on Read Replicas doubles the cost of each replica because AWS provisions a standby instance. While this improves availability, it is often unnecessary for read-only traffic that can be rerouted if a replica fails, making it a poor choice for a strategy focused strictly on cost reduction.

A
Create RDS Read Replicas and update the application to split read and write traffic.
Read Replicas allow the application to scale read capacity independently of the primary instance. By directing read queries to replicas, the primary instance can be smaller and less expensive, while the replicas handle the high read pressure during business hours at a lower cost than a single massive instance.
B
Scale up the primary RDS instance to a larger instance class with more RAM.
Why it fails: Scaling up the primary instance is a vertical scaling strategy that increases the cost of the entire database 24/7. Since the write activity is low, paying for a larger instance just to handle peak read traffic is inefficient compared to using Read Replicas, which can be scaled more granularly.
C
Use Amazon ElastiCache in front of the RDS database to cache frequent read queries.
Implementing ElastiCache reduces the load on the RDS database by serving frequently accessed data from memory. This allows the company to use a smaller RDS instance class and potentially fewer Read Replicas, leading to significant cost savings on the most expensive database components while improving application response times.
D
Switch the database to Amazon RDS for SQL Server to take advantage of License Inclusion.
Why it fails: Switching to SQL Server from MySQL would likely increase costs due to licensing fees and architectural changes. MySQL is an open-source engine with no licensing costs. Moving to a commercial engine would be counterproductive for a project specifically focused on reducing the overall cost of the database layer.
E
Enable Multi-AZ for all Read Replicas to ensure high availability.
Why it fails: Enabling Multi-AZ on Read Replicas doubles the cost of each replica because AWS provisions a standby instance. While this improves availability, it is often unnecessary for read-only traffic that can be rerouted if a replica fails, making it a poor choice for a strategy focused strictly on cost reduction.

Question 4mediummultiple choice

A company's web application requires a highly available database layer to survive an Availability Zone failure without manual intervention. The database must remain accessible during maintenance windows and ensure zero data loss. Which solution meets these requirements with the least operational overhead?

Trap 1: Configure RDS Read Replicas and manually promote them during an…

Read Replicas are designed for scaling read traffic rather than providing high availability. Promoting a replica manually requires human intervention and configuration changes, which increases the recovery time objective. Additionally, because replication is asynchronous, there is a risk of data loss if the primary instance fails before data is synchronized to the replica.

Trap 2: Deploy a Single-AZ RDS instance and use AWS Backup for hourly…

Single-AZ deployments are susceptible to outages if the specific Availability Zone fails. While snapshots provide a way to restore data, the restoration process is manual and time-consuming, leading to high downtime. This approach does not meet the requirement for automatic failover and high availability during maintenance or infrastructure failures.

Trap 3: Host a MySQL database on an Amazon EC2 instance with an EBS volume.

Running a database on a single EC2 instance introduces a single point of failure. Achieving high availability would require the architect to manually configure complex clustering software, replication, and failover scripts. This approach represents a high operational burden and does not leverage the managed high availability features provided by Amazon RDS.

A
Configure RDS Read Replicas and manually promote them during an outage.
Why it fails: Read Replicas are designed for scaling read traffic rather than providing high availability. Promoting a replica manually requires human intervention and configuration changes, which increases the recovery time objective. Additionally, because replication is asynchronous, there is a risk of data loss if the primary instance fails before data is synchronized to the replica.
B
Deploy a Single-AZ RDS instance and use AWS Backup for hourly snapshots.
Why it fails: Single-AZ deployments are susceptible to outages if the specific Availability Zone fails. While snapshots provide a way to restore data, the restoration process is manual and time-consuming, leading to high downtime. This approach does not meet the requirement for automatic failover and high availability during maintenance or infrastructure failures.
C
Implement an Amazon RDS Multi-AZ deployment.
Amazon RDS Multi-AZ uses synchronous replication to a standby instance in a different AZ, providing automatic failover and data redundancy. If the primary instance fails, AWS automatically updates the DNS record to point to the standby. This meets the high availability and zero-intervention requirements while handling maintenance windows with minimal impact on application uptime.
D
Host a MySQL database on an Amazon EC2 instance with an EBS volume.
Why it fails: Running a database on a single EC2 instance introduces a single point of failure. Achieving high availability would require the architect to manually configure complex clustering software, replication, and failover scripts. This approach represents a high operational burden and does not leverage the managed high availability features provided by Amazon RDS.

Question 5mediummulti select

A solutions architect is designing a caching layer for a high-traffic web application that uses a multi-node cluster. The architect needs to ensure high availability and the ability to scale horizontally while supporting complex data types such as sorted sets and lists. Which TWO features of Amazon ElastiCache for Redis support these requirements?

Trap 1: Support for multi-threaded execution.

Redis is primarily a single-threaded engine for command execution, although recent versions have introduced some background threading for I/O. Memcached is typically the choice for multi-threaded performance, but it lacks the complex data structures and high availability features like Multi-AZ and replication required in this scenario.

Trap 2: Automatic data compression at the cache level.

Amazon ElastiCache does not provide native automatic data compression at the service level. Compression is typically handled by the application code before the data is sent to the cache. Relying on the cache for compression would introduce unnecessary latency and CPU overhead on the cache nodes.

Trap 3: Use of UDP protocol for low-latency writes.

Redis uses the TCP protocol to ensure reliable delivery of data and commands. While UDP can be faster in some networking contexts, it is not supported by ElastiCache for Redis because reliability and data integrity are paramount for a persistent data store and caching engine.

A
Multi-AZ with automatic failover.
This feature provides high availability by automatically detecting a primary node failure and promoting a replica to primary in a different Availability Zone. This minimizes downtime and ensures that the caching layer remains performant and available even during infrastructure failures in a single zone.
B
Support for multi-threaded execution.
Why it fails: Redis is primarily a single-threaded engine for command execution, although recent versions have introduced some background threading for I/O. Memcached is typically the choice for multi-threaded performance, but it lacks the complex data structures and high availability features like Multi-AZ and replication required in this scenario.
C
Redis Cluster mode for horizontal scaling.
Redis Cluster mode allows data to be partitioned across multiple shards. This enables the cache to scale horizontally by adding more shards, providing increased memory capacity and throughput. This is essential for high-performing applications that outgrow the capacity of a single primary node.
D
Automatic data compression at the cache level.
Why it fails: Amazon ElastiCache does not provide native automatic data compression at the service level. Compression is typically handled by the application code before the data is sent to the cache. Relying on the cache for compression would introduce unnecessary latency and CPU overhead on the cache nodes.
E
Use of UDP protocol for low-latency writes.
Why it fails: Redis uses the TCP protocol to ensure reliable delivery of data and commands. While UDP can be faster in some networking contexts, it is not supported by ElastiCache for Redis because reliability and data integrity are paramount for a persistent data store and caching engine.

Question 6mediummulti select

A company is designing a mission-critical database architecture using Amazon RDS. Which TWO steps should the architect take to ensure high availability and data durability? (Select TWO.)

Trap 1: Configure a Read Replica in the same Availability Zone.

Placing a Read Replica in the same Availability Zone as the primary database does not improve resilience against AZ-level failures. For true disaster recovery and high availability, read replicas should be placed in different Availability Zones or even different AWS Regions to survive localized physical infrastructure outages or network issues.

Trap 2: Set the storage type to General Purpose SSD (gp2) only.

The storage type choice (gp2, gp3, or io1) affects performance and throughput but does not inherently provide high availability or durability. While SSDs offer better performance than magnetic storage, they do not replicate data across zones or prevent database downtime in the event of an infrastructure failure or primary node crash.

Trap 3: Disable the deletion protection feature for all instances.

Disabling deletion protection increases the risk of accidental resource termination, which is the opposite of a resilient architecture. Deletion protection should be enabled for production databases to prevent human error from resulting in data loss, as it requires an additional step to modify the instance before it can be deleted.

A
Enable Multi-AZ deployment for the RDS instance.
Multi-AZ deployment ensures that a synchronous standby instance is maintained in a separate Availability Zone. In the event of a primary instance failure, RDS automatically promotes the standby to primary, significantly reducing downtime and ensuring the database remains available for critical application traffic without manual intervention or data loss.
B
Configure a Read Replica in the same Availability Zone.
Why it fails: Placing a Read Replica in the same Availability Zone as the primary database does not improve resilience against AZ-level failures. For true disaster recovery and high availability, read replicas should be placed in different Availability Zones or even different AWS Regions to survive localized physical infrastructure outages or network issues.
C
Enable automated backups with a defined retention period.
Automated backups are essential for data durability and point-in-time recovery. By retaining backups for a specific period, the organization can recover the database to any second within the retention window, providing a robust safety net against accidental data deletion, corruption, or catastrophic failures that impact the primary database instance.
D
Set the storage type to General Purpose SSD (gp2) only.
Why it fails: The storage type choice (gp2, gp3, or io1) affects performance and throughput but does not inherently provide high availability or durability. While SSDs offer better performance than magnetic storage, they do not replicate data across zones or prevent database downtime in the event of an infrastructure failure or primary node crash.
E
Disable the deletion protection feature for all instances.
Why it fails: Disabling deletion protection increases the risk of accidental resource termination, which is the opposite of a resilient architecture. Deletion protection should be enabled for production databases to prevent human error from resulting in data loss, as it requires an additional step to modify the instance before it can be deleted.

Question 7mediummulti select

A company is running a development environment on Amazon RDS for MySQL. The environment is only used by developers during business hours (09:00 to 17:00, Monday through Friday). The company wants to minimize costs for these database instances. Which TWO actions should the company take?

Trap 1: Convert the RDS instances to Multi-AZ deployments.

Multi-AZ deployments provide high availability and failover support by maintaining a synchronous standby in a different Availability Zone. This doubles the hourly cost of the database instance. Since this is a development environment where high availability is not a requirement, Multi-AZ would significantly increase costs without providing necessary value.

Trap 2: Purchase All Upfront Reserved Instances for the development…

Reserved Instances (RIs) provide a discount for a committed term of 1 or 3 years. However, RIs are most cost-effective for instances that run 24/7. If an instance is stopped for more than 60-70% of the time, the savings from stopping the instance actually exceed the discount provided by an RI.

Trap 3: Move the databases to Amazon DynamoDB to utilize on-demand scaling.

While DynamoDB On-Demand can be cost-effective, migrating from a relational MySQL database to a NoSQL DynamoDB table requires a complete rewrite of the application code and data schema. The operational and development costs of such a migration usually far outweigh the simple infrastructure savings achieved through instance scheduling.

A
Stop the RDS instances when they are not in use.
Stopping an RDS instance is highly effective for cost reduction in development environments. While the instance is stopped, you are not charged for compute hours or licensed software. You only pay for the provisioned storage and any manual snapshots, making it ideal for workloads that are strictly limited to business hours.
B
Convert the RDS instances to Multi-AZ deployments.
Why it fails: Multi-AZ deployments provide high availability and failover support by maintaining a synchronous standby in a different Availability Zone. This doubles the hourly cost of the database instance. Since this is a development environment where high availability is not a requirement, Multi-AZ would significantly increase costs without providing necessary value.
C
Use AWS Instance Scheduler to automate the start and stop times.
AWS Instance Scheduler allows you to define recurring schedules for starting and stopping EC2 and RDS instances. Automating this ensures that the instances are consistently turned off outside of business hours, maximizing cost savings and preventing human error where instances might be accidentally left running over weekends or holidays.
D
Purchase All Upfront Reserved Instances for the development environment.
Why it fails: Reserved Instances (RIs) provide a discount for a committed term of 1 or 3 years. However, RIs are most cost-effective for instances that run 24/7. If an instance is stopped for more than 60-70% of the time, the savings from stopping the instance actually exceed the discount provided by an RI.
E
Move the databases to Amazon DynamoDB to utilize on-demand scaling.
Why it fails: While DynamoDB On-Demand can be cost-effective, migrating from a relational MySQL database to a NoSQL DynamoDB table requires a complete rewrite of the application code and data schema. The operational and development costs of such a migration usually far outweigh the simple infrastructure savings achieved through instance scheduling.

Question 8hardmulti select

A financial application stores data in Amazon Aurora. The architecture must survive a regional outage. Which TWO steps should the architect take to meet this requirement?

Trap 1: Enable Aurora Multi-AZ deployment in the primary region.

Multi-AZ deployment ensures high availability within a single region by protecting against AZ failures. However, it does not provide protection against a full AWS region failure. Regional disaster recovery requires cross-region replication strategies to ensure data availability should the primary geographic site become completely unreachable or suffer degradation.

Trap 2: Schedule daily Amazon RDS snapshots and copy them to an S3 bucket…

Storing snapshots in the same region as the database does not protect against a regional failure. If the entire region goes offline, the snapshots stored there are inaccessible. Snapshots must be copied to a different region to satisfy cross-region disaster recovery requirements and ensure data is eventually recoverable.

Trap 3: Enable Performance Insights on all Aurora instances.

Performance Insights is a database performance tuning and monitoring tool. It provides visibility into database load and query performance but plays no role in high availability or disaster recovery. Monitoring and resilience are distinct architectural concerns that require different sets of services and configuration settings to address effectively.

A
Enable Aurora Multi-AZ deployment in the primary region.
Why it fails: Multi-AZ deployment ensures high availability within a single region by protecting against AZ failures. However, it does not provide protection against a full AWS region failure. Regional disaster recovery requires cross-region replication strategies to ensure data availability should the primary geographic site become completely unreachable or suffer degradation.
B
Create an Aurora Global Database with a secondary region.
Aurora Global Database is specifically designed for regional disaster recovery. It uses dedicated infrastructure to replicate data to secondary regions with minimal latency, typically under one second. This configuration allows for rapid promotion of a secondary region to read-write status in the event of a primary regional failure.
C
Schedule daily Amazon RDS snapshots and copy them to an S3 bucket in the same region.
Why it fails: Storing snapshots in the same region as the database does not protect against a regional failure. If the entire region goes offline, the snapshots stored there are inaccessible. Snapshots must be copied to a different region to satisfy cross-region disaster recovery requirements and ensure data is eventually recoverable.
D
Promote the secondary region to primary if the primary region becomes unavailable.
Promoting a secondary region is the critical step in regional failover for Aurora Global Database. When the primary region fails, the secondary database can be promoted to standalone status for full read-write capabilities. This manual or automated switch allows the application to resume operations in a healthy, separate geographic location.
E
Enable Performance Insights on all Aurora instances.
Why it fails: Performance Insights is a database performance tuning and monitoring tool. It provides visibility into database load and query performance but plays no role in high availability or disaster recovery. Monitoring and resilience are distinct architectural concerns that require different sets of services and configuration settings to address effectively.

Question 9hardmultiple choice

A company runs a mission-critical web application on EC2. The database is on RDS. How should the architect ensure the fastest possible recovery time objective (RTO) if the primary database instance fails?

Trap 1: Configure an RDS Read Replica in a different region and promote it…

While this provides regional disaster recovery, promoting a read replica to a standalone instance is a manual or semi-automated process that takes significantly longer than a standard Multi-AZ failover. It is not the fastest way to recover from an instance-level failure within the same region.

Trap 2: Take hourly automated snapshots and restore from the latest…

Restoring from a snapshot involves creating a new database instance, which can take several minutes to hours depending on the database size. This results in a very high RTO, which is unsuitable for mission-critical applications that require minimal downtime and continuous availability during unexpected database infrastructure failures.

Trap 3: Back up the database to S3 and use a standby EC2 instance to run a…

This self-managed approach is prone to human error and adds significant complexity to the recovery process. It lacks the seamless, automated failover capabilities provided by RDS Multi-AZ, leading to a much longer and less predictable RTO, making it an inferior choice for mission-critical production database environments.

A
Configure an RDS Read Replica in a different region and promote it if the primary fails.
Why it fails: While this provides regional disaster recovery, promoting a read replica to a standalone instance is a manual or semi-automated process that takes significantly longer than a standard Multi-AZ failover. It is not the fastest way to recover from an instance-level failure within the same region.
B
Enable RDS Multi-AZ deployment.
RDS Multi-AZ is specifically designed for high availability. It maintains a synchronous secondary standby in another AZ. Upon detecting a failure, RDS automatically initiates a failover process. This is the fastest, most reliable way to maintain database availability and minimize downtime for mission-critical applications without manual intervention.
C
Take hourly automated snapshots and restore from the latest snapshot upon failure.
Why it fails: Restoring from a snapshot involves creating a new database instance, which can take several minutes to hours depending on the database size. This results in a very high RTO, which is unsuitable for mission-critical applications that require minimal downtime and continuous availability during unexpected database infrastructure failures.
D
Back up the database to S3 and use a standby EC2 instance to run a database engine.
Why it fails: This self-managed approach is prone to human error and adds significant complexity to the recovery process. It lacks the seamless, automated failover capabilities provided by RDS Multi-AZ, leading to a much longer and less predictable RTO, making it an inferior choice for mission-critical production database environments.