Deal of The Day! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

Amazon SAA-C03 Exam - Topic 4 Question 54 Discussion

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

Amazon SAA-C03 Exam - Topic 4 Question 54 Discussion

Actual exam question for Amazon's SAA-C03 exam
Question #: 54
Topic #: 4
[All SAA-C03 Questions]

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.

Show Suggested Answer Hide Answer
Suggested Answer: C

Key Requirements:

High availability and automatic recovery.

Separate transactional and analytical queries with minimal performance impact.

Allow up to a 4-hour lag for analytical queries.

Analysis of Options:

Option A:

Multi-AZ deployments provide high availability but do not include read replicas for separating transactional and analytical queries.

Analytical queries on the secondary DB instance would impact the transactional workload.

Incorrect Approach: Does not meet the requirement of query separation.

Option B:

Multi-AZ DB clusters provide high availability and include a reader endpoint. However, these are better suited for Aurora and not RDS for MySQL.

Incorrect Approach: Not applicable to standard RDS for MySQL.

Option C:

Multiple read replicas allow separation of transactional and analytical workloads.

Queries can be pointed to a replica in a different AZ, ensuring no impact on transactional queries.

Correct Approach: Meets all requirements with high availability and query separation.

Option D:

Creating nightly snapshots and read-only databases adds significant operational overhead and does not support the 4-hour lag requirement.

Incorrect Approach: Not practical for dynamic query separation.

AWS Solution Architect Reference:

Amazon RDS Read Replicas

Multi-AZ Deployments


Contribute your Thoughts:

0/2000 characters
Audria
8 months ago
Not sure about B, can the reader endpoint handle all those analytical queries?
upvoted 0 times
...
Rebeca
9 months ago
A seems too basic for high availability needs.
upvoted 0 times
...
Marshall
9 months ago
I think C is better for performance with read replicas.
upvoted 0 times
...
Cherrie
9 months ago
Wait, D relies on nightly snapshots? That’s risky!
upvoted 0 times
...
Lenita
9 months ago
Option B sounds solid with the Multi-AZ cluster setup.
upvoted 0 times
...
Melodie
9 months ago
I recall something about automated backups in option D, but it seems like creating a read-only database every night could introduce delays. I wonder if that would meet the 4-hour lag requirement.
upvoted 0 times
...
Sueann
10 months ago
I’m a bit confused about the difference between read replicas and standby instances. I feel like option C might be the best fit, but I need to double-check the lag requirements.
upvoted 0 times
...
Eleni
10 months ago
I think option B sounds familiar from our practice questions, especially with the reader endpoint for analytical queries. It seems like a solid choice for minimizing performance impact.
upvoted 0 times
...
Diane
10 months ago
I remember that Multi-AZ deployments are great for high availability, but I'm not sure if they handle the analytical queries as well as read replicas do.
upvoted 0 times
...
Kizzy
10 months ago
I'm not sure I fully understand the difference between the Multi-AZ deployment and the read replica options. I'll need to do some more research on the specific features of each to make the best choice.
upvoted 0 times
...
Pamela
10 months ago
I'm feeling pretty confident about this one. Option A seems like the most straightforward approach to meet the requirements, with the transactional and analytical queries separated across different instances.
upvoted 0 times
...
Pearly
11 months ago
Okay, I've got a strategy here. I think option B is the way to go - the Multi-AZ DB cluster with the reader endpoint for the analytical queries. That should give us the high availability and performance isolation we need.
upvoted 0 times
...
Natalya
11 months ago
Hmm, I'm a bit confused by the different deployment options. I'll need to review the details of each one to understand the pros and cons before making a decision.
upvoted 0 times
...
Carin
11 months ago
This looks like a tricky question, but I think I can tackle it. I'll need to carefully consider the requirements for high availability, automatic recovery, and separating transactional and analytical queries.
upvoted 0 times
...
Alline
2 years ago
Option B for the win! I love the idea of a multi-AZ cluster. It's like having a backup plan for your backup plan. #HighAvailabilityFTW
upvoted 0 times
Corazon
1 year ago
User 2: I agree, having that extra layer of redundancy is key for high availability. Plus, pointing the analytical queries to the reader endpoint is a smart move to prevent performance issues.
upvoted 0 times
...
Aracelis
1 year ago
User 2: I agree! It's always good to have a backup plan for your backup plan, especially when it comes to critical applications.
upvoted 0 times
...
Hubert
1 year ago
User 1: Option B sounds like a solid choice. Having two standby instances in a Multi-AZ cluster is definitely a good backup plan.
upvoted 0 times
...
Jenelle
1 year ago
User 1: Option B sounds like a solid choice. Having two standby instances in a Multi-AZ cluster is a great way to ensure high availability.
upvoted 0 times
...
...
Charlesetta
2 years ago
Option A is decent, but I'd be worried about the performance impact on the transactional queries if the analytical queries are hitting the same instance, even in a different AZ.
upvoted 0 times
Azalee
1 year ago
User 4: Yeah, having separate replicas for analytical queries could definitely help in maintaining the performance of the critical application.
upvoted 0 times
...
Venita
2 years ago
User 3: Option C does sound like a good solution to keep the performance of transactional queries unaffected by analytical queries.
upvoted 0 times
...
Willard
2 years ago
User 2: I agree, that could be a concern. Maybe option C would be better since it uses multiple read replicas across different AZs.
upvoted 0 times
...
Dana
2 years ago
User 1: Option A is decent, but I'd be worried about the performance impact on the transactional queries if the analytical queries are hitting the same instance, even in a different AZ.
upvoted 0 times
...
...
Keena
2 years ago
This is a tough one, but I think Option D is the way to go. Automating the backups and creating a separate read-only database for analytics is a clever approach that keeps the transactional queries unaffected.
upvoted 0 times
...
Veronika
2 years ago
I'm leaning towards Option C. Utilizing multiple read replicas across AZs is a simpler yet effective way to achieve the desired result without the overhead of a full-blown cluster.
upvoted 0 times
Lynna
1 year ago
Definitely, having separate replicas for each type of query can help maintain performance.
upvoted 0 times
...
Walker
2 years ago
It's important to ensure that the performance of transactional queries is not impacted by analytical queries.
upvoted 0 times
...
Alyce
2 years ago
I agree, using read replicas across AZs can help balance the load.
upvoted 0 times
...
Theodora
2 years ago
Option C sounds like a good choice for this scenario.
upvoted 0 times
...
...
Tiara
2 years ago
I personally prefer option D. Creating a read-only database from the most recent snapshot each night for analytical queries seems like a simple and efficient solution.
upvoted 0 times
...
Shanice
2 years ago
That's a good point, Susy. But won't pointing the analytical queries to the reader endpoint in option B affect the performance of transactional queries?
upvoted 0 times
...
Susy
2 years ago
I disagree, I think option B is better. Having two standby instances in a Multi-AZ cluster can provide better fault tolerance and scalability for both types of queries.
upvoted 0 times
...
Marjory
2 years ago
Option B seems the most comprehensive solution. Having a multi-AZ DB cluster with two standby instances and using the reader endpoint for analytical queries ensures both high availability and isolation of the workloads.
upvoted 0 times
Gerardo
2 years ago
Definitely, it's important to ensure that one type of query doesn't impact the other in a critical application deployment.
upvoted 0 times
...
Stanton
2 years ago
I agree, having separate instances for transactional and analytical queries is key to maintaining performance.
upvoted 0 times
...
Olive
2 years ago
Option B seems the most comprehensive solution. Having a multi-AZ DB cluster with two standby instances and using the reader endpoint for analytical queries ensures both high availability and isolation of the workloads.
upvoted 0 times
...
Dorthy
2 years ago
User 2: I agree, having a Multi-AZ DB cluster with two standby instances and using the reader endpoint for analytical queries sounds like a solid plan.
upvoted 0 times
...
Belen
2 years ago
User 1: I think option B is the best choice for our situation.
upvoted 0 times
...
...
Shanice
2 years ago
I think option A sounds like a good choice. Having a standby instance in a different AZ for analytical queries seems like a good way to ensure high availability.
upvoted 0 times
...

Save Cancel