New Year Sale 2026! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions
Mail Us support@pass4success.com
Location US
Mob_nav_barsMENU

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


by Glenn at Jan 28, 2025, 03:23 PM

Limited Time Offer

25%

Off

Get Premium SAA-C03 Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

0/2000 characters
Submit Cancel
Audria
2 months ago
Not sure about B, can the reader endpoint handle all those analytical queries?
upvoted 0 times
...
Rebeca
2 months ago
A seems too basic for high availability needs.
upvoted 0 times
...
Marshall
2 months ago
I think C is better for performance with read replicas.
upvoted 0 times
...
Cherrie
3 months ago
Wait, D relies on nightly snapshots? That’s risky!
upvoted 0 times
...
Lenita
3 months ago
Option B sounds solid with the Multi-AZ cluster setup.
upvoted 0 times
...
Melodie
3 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
3 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
4 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
4 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
4 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
4 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
4 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
4 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
5 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
12 months 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
11 months 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
11 months 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
11 months 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
12 months 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
1 year 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
11 months 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
12 months 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
12 months 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
1 year 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
1 year 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
1 year 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
11 months ago
Definitely, having separate replicas for each type of query can help maintain performance.
upvoted 0 times
...
Walker
12 months ago
It's important to ensure that the performance of transactional queries is not impacted by analytical queries.
upvoted 0 times
...
Alyce
12 months ago
I agree, using read replicas across AZs can help balance the load.
upvoted 0 times
...
Theodora
1 year ago
Option C sounds like a good choice for this scenario.
upvoted 0 times
...
...
Tiara
1 year 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
1 year 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
1 year 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
1 year 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
1 year 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
1 year ago
I agree, having separate instances for transactional and analytical queries is key to maintaining performance.
upvoted 0 times
...
Olive
1 year 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
1 year 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
1 year ago
User 1: I think option B is the best choice for our situation.
upvoted 0 times
...
...
Shanice
1 year 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