Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 247 discussion

Who would know this stuff man...

C,E "An active, long-running transaction can slow the process of creating the read replica. We recommend that you wait for long-running transactions to complete before creating a read replica. If you create multiple read replicas in parallel from the same source DB instance, Amazon RDS takes only one snapshot at the start of the first create action. When creating a read replica, there are a few things to consider. First, you must enable automatic backups on the source DB instance by setting the backup retention period to a value other than 0. This requirement also applies to a read replica that is the source DB instance for another read replica" https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html

A isn't correct because binary log is just for external DB instance.

Answer is C and E https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html

A. Enable binlog replication on the RDS primary node: Direct Impact: Enabling binlog replication is crucial for setting up read replicas, which will directly help in distributing the read load and improving read performance. E. Enable automatic backups on the source instance by setting the backup retention period to a value other than 0: Direct Impact: Automatic backups are necessary to ensure data integrity when creating read replicas. This setup is critical for maintaining consistent and reliable replicas.

B and D don't have anything to do with the question. E is a must have before doing major architecture changes A is not something you need to do explicitly when creating read replicas as it is managed by RDS C makes sense * I think the options are really badly worded which makes it confusing. I doubt this is a real question.

An active, long-running transaction can slow the process of creating the read replica. We recommend that you wait for long-running transactions to complete before creating a read replica. If you create multiple read replicas in parallel from the same source DB instance, Amazon RDS takes only one snapshot at the start of the first create action. When creating a read replica, there are a few things to consider. First, you must enable automatic backups on the source DB instance by setting the backup retention period to a value other than 0. This requirement also applies to a read replica that is the source DB instance for another read replica

To improve the read performance of a database in Amazon RDS for MySQL by adding a read replica, you should take the following actions: Enable binlog replication on the RDS primary node: This allows the primary node to stream its binary logs to the read replica, enabling data replication. A. Enable binlog replication on the RDS primary node. Allow long-running transactions to complete on the source DB instance: Before creating a read replica, it's advisable to let any long-running transactions complete to ensure consistency between the source and the replica. C. Allow long-running transactions to complete on the source DB instance. The other options are not directly related to setting up a read replica:

A - it's essential for continuous replication E - it's essential for setting up replication, initial data in replica is based on latest backup other options: B - we're not designing for HA, and it's related to mutli-AZ RDS deployments C - is this needed for adding read replica? D - it's not a dynamodb to create global table

A. Enabling binlog replication is not something you need to do manually before creating a read replica. Amazon RDS for MySQL manages replication internally, and it's not necessary to enable binlog replication explicitly. B. Choosing a failover priority is related to Multi-AZ configurations and automatic failover, but it is not specifically required when adding a read replica. D. Creating a global table and specifying AWS Regions is related to Aurora Global Databases, which is not the same as creating a read replica for a standard RDS instance.

**C. Long-running transactions can prevent the read replica from catching up with the source DB instance. Allowing these transactions to complete before creating the read replica can help ensure that the replica is able to stay synchronized with the source. **E. Automatic backups must be enabled on the source DB instance for read replicas to be created. This is done by setting the backup retention period to a value other than 0.

Bin log (binary log) is a specific terminology to MySQL, it is a write-only file that logs all history and used for purposes such as point-in-time recovery and transaction replication. Option A is technically correct but on AWS RDS, this MySQL feature is turned on by setting backup retention period > 0, that is why we must enable backup before replication can work (for MySQL, at least) => Option E is the more general answer for AWS RDS. Option C is just a recommendation from AWS official documentation, it is there to prevent data mismatch on primary and secondaries when the long-running transactions have not been complete yet.

Before a MySQL DB instance can serve as a replication source, make sure to enable automatic backups on the source DB instance. To do this, set the backup retention period to a value other than 0. This requirement also applies to a read replica that is the source DB instance for another read replica. Automatic backups are supported for read replicas running any version of MySQL. You can configure replication based on binary log coordinates for a MySQL DB instance https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.ReadReplicas.html

A E. Binlog is needed for on-going replication setup and DB backup is needed for setup the replication DB

Correction: c and e

A and e

A. enables the binary log replication feature on the RDS primary node, which is necessary for setting up a read replica. B. determines the order in which DB instances are promoted to the primary role during a failover scenario. It is not directly related to adding a read replica to address slow reads. C. ensures that any ongoing transactions on the source DB instance are allowed to finish before implementing the change. It helps maintain data integrity and consistency during the transition to the read replica. D. is a feature specific to DynamoDB. It allows for multi-region replication and high availability in DynamoDB, but it is not applicable in this scenario. E. ensures that regular backups are taken for the source DB instance. This is important for data protection and recovery purposes, as it allows for point-in-time restoration in case of any issues during or after the addition of the read replica.