Q100 — AWS SAA-C03 Ch.14
Question 100 of 100 | ← Chapter 14
Q1100. A company is deploying a critical application by using Amazon RDS for MySQL. The application must be highly available and must recover automatically. The company needs to support interactive users (transactional queries) and batch reporting (analytical queries) with no more than a 4-hour lag. The analytical queries must not affect the performance of the transactional queries.Which solution will meet these requirements?
- A. Configure Amazon RDS for MySQL in a Multi-AZ DB instance deployment with one standby instance.Point the transactional queries to the primary DB instance. Point the analytical queries to a secondary DB instance that runs in a different Availability Zone.
- B. Configure Amazon RDS for MySQL in a Multi-AZ DB cluster deployment with two standby instances.Point the transactional queries to the primary DB instance. Point the analytical queries to the reader endpoint.
- C. Configure Amazon RDS for MySQL to use multiple read replicas across multiple Availability Zones.Point the transactional queries to the primary DB instance. Point the analytical queries to one of the replicas in a different Availability Zone. ✓
- D. Configure Amazon RDS for MySQL as the primary database for the transactional queries with automated backups enabled. Configure automated backups. Each night, create a read-only database from the most recent snapshot to support the analytical queries. Terminate the previously created database.
Correct Answer: C. Configure Amazon RDS for MySQL to use multiple read replicas across multiple Availability Zones.Point the transactional queries to the primary DB instance. Point the analytical queries to one of the replicas in a different Availability Zone.
Explanation
To address the requirements for a critical application using Amazon RDS for MySQL, we need to consider factors such as high availability, automatic recovery, support for both transactional and analytical queries, and minimal impact on transactional query performance from analytical queries.Let's evaluate each option:A. Configure Amazon RDS for MySQL in a Multi-AZ DB instance deployment with one standby instance. Point the transactional queries to the primary DB instance. Point the analytical queries to a secondary DB instance that runs in a different Availability Zone.A Multi-AZ deployment provides high availability and automatic failover for the primary instance. However, this option suggests manually managing a separate secondary instance for analytical queries, which does not provide an automated or seamless solution.Managing this secondary instance, ensuring it stays in sync, and handling failover could be complex and error-prone.B. Configure Amazon RDS for MySQL in a Multi-AZ DB cluster deployment with two standby instances. Point the transactional queries to the primary DB instance. Point the analytical queries to the reader endpoint.Amazon RDS for MySQL does not support a Multi-AZ DB cluster deployment with reader endpoints in the traditional sense like Aurora does.This option is not applicable for RDS for MySQL as described. C. Configure Amazon RDS for MySQL to use multiple read replicas across multiple Availability Zones. Point the transactional queries to the primary DB instance. Point the analytical queries to one of the replicas in a different Availability Zone.This option provides a highly available setup with the primary instance and multiple read replicas. Transactional queries are handled by the primary instance, ensuring optimal performance. Analytical queries are directed to a read replica, which does not impact the performance of transactional queries.Read replicas are automatically synchronized with the primary instance, ensuring minimal lag and consistency.D. Configure Amazon RDS for MySQL as the primary database for the transactional queries with automated backups enabled. Configure automated backups. Each night, create a read-only database from the most recent snapshot to support the analytical queries. Terminate the previously created database.This option involves manual snapshot management and creation of a new read-only database each night. It does not provide real-time or near-real-time data for analytical queries, with a significant lag due to the nightly snapshot process.Terminating and recreating the database each night introduces complexity and potential downtime. Given these considerations, Option C provides the most suitable solution to meet the requirements:High availability and automatic recovery through the use of a primary instance and read replicas. Separate handling of transactional and analytical queries with minimal impact on transactional performance.Minimal lag for analytical queries due to real-time synchronization with the primary instance.