AWS Certified Solutions Architect - Professional

Get started today

Ultimate access to all questions.

Explanation:

The correct answer is A.

The company requires a single source of truth for the database with real-time data visibility across us-east-1 (US) and eu-west-1 (Europe). Both regions must support writes, while European customers need low application latency (local endpoint) and no stale data.

Only Aurora Global Database with write forwarding natively meets all these requirements in a managed way:

Sub-second replication from primary to secondary Region.
Applications in the secondary Region can issue writes locally; Aurora transparently forwards them to the primary writer.
The primary commits the change, then replicates it back to all secondary Regions (near real-time visibility for everyone).
Reads are served locally from the secondary cluster with very low latency.

Why Option A Is Correct

Option A follows the exact official, recommended migration path from RDS for MySQL to Aurora MySQL and then extends it to a Global Database:

Create an Amazon Aurora MySQL read replica of the existing RDS for MySQL DB instance (in us-east-1).
Replication uses MySQL binary log and happens with no impact on the source.
Pause application writes to the original RDS for MySQL instance (e.g., by setting the read_only parameter or application-level quiescing).
This prevents new writes from being missed during the cutover.
Wait for replication lag to reach zero, then promote the Aurora replica to a standalone Aurora MySQL DB cluster.
Promotion breaks the replication link and makes the Aurora cluster fully independent and writable.
Reconfigure the US application to use the new Aurora cluster endpoint and resume writes.
Add eu-west-1 as a secondary Region to the Aurora cluster → this creates an Aurora Global Database.
The secondary cluster in Europe starts with read-only replication from the primary (us-east-1).
Enable write forwarding on the global database (secondary cluster).
This allows the European application to send writes to its local endpoint; Aurora forwards them to the primary in us-east-1.
Deploy the European application in eu-west-1 and configure it to use the Aurora MySQL endpoint (reader or cluster endpoint) in the secondary Region.

Result:

US customers write to the primary in us-east-1.
European customers read locally (low latency) and write locally (writes forwarded transparently).
All changes propagate in near real time via Aurora’s fast global replication.
Single source of truth with no custom replication or conflict resolution needed.

This process has near-zero downtime when executed properly and is the standard method documented by AWS.

Why the Other Options Are Incorrect

Option B: RDS for MySQL supports cross-Region read replicas only. There is no native support for “replicate write queries back” or bidirectional replication. Implementing this would require complex, unmanaged MySQL logical replication with high risk of conflicts and lag.
Option C: Copying a snapshot creates a one-time copy, not continuous replication. Setting up MySQL logical replication between two separate RDS for MySQL instances is manual, error-prone, has higher lag, and does not support Aurora-style write forwarding (plain RDS MySQL lacks this feature).
Option D: Incorrect terminology. There is no direct “Convert” operation that turns an RDS for MySQL instance into an Aurora MySQL DB cluster. The proper path requires creating an Aurora read replica and then promoting it (as described in A). Using the word “Convert” makes this option imprecise for the exam.

Key Exam Takeaways

RDS MySQL → Aurora MySQL migration (minimal downtime) = Create Aurora read replica → wait for lag = 0 → (pause writes) → Promote to standalone cluster.
Aurora Global Database + Global Write Forwarding is the recommended AWS-managed pattern for active writes from multiple Regions with low latency and strong consistency.
Write forwarding requires Aurora MySQL compatible with MySQL 5.7 or higher and must be explicitly enabled. Applications in secondary Regions should set the aurora_replica_read_consistency parameter (e.g., 'session') to enable forwarding for the session.
Look for keywords like “write forwarding”, “secondary Region”, and the detailed migration steps in Professional-level questions.

This question tests precise knowledge of Aurora migration paths versus RDS limitations and when to use Aurora Global Database features.

Correct Choice: A

Explanation:

The correct answer is A.

Only Aurora Global Database with write forwarding natively meets all these requirements in a managed way:

Sub-second replication from primary to secondary Region.
Applications in the secondary Region can issue writes locally; Aurora transparently forwards them to the primary writer.
The primary commits the change, then replicates it back to all secondary Regions (near real-time visibility for everyone).
Reads are served locally from the secondary cluster with very low latency.

Why Option A Is Correct

Option A follows the exact official, recommended migration path from RDS for MySQL to Aurora MySQL and then extends it to a Global Database:

Create an Amazon Aurora MySQL read replica of the existing RDS for MySQL DB instance (in us-east-1).
Replication uses MySQL binary log and happens with no impact on the source.
Pause application writes to the original RDS for MySQL instance (e.g., by setting the read_only parameter or application-level quiescing).
This prevents new writes from being missed during the cutover.
Wait for replication lag to reach zero, then promote the Aurora replica to a standalone Aurora MySQL DB cluster.
Promotion breaks the replication link and makes the Aurora cluster fully independent and writable.
Reconfigure the US application to use the new Aurora cluster endpoint and resume writes.
Add eu-west-1 as a secondary Region to the Aurora cluster → this creates an Aurora Global Database.
The secondary cluster in Europe starts with read-only replication from the primary (us-east-1).
Enable write forwarding on the global database (secondary cluster).
This allows the European application to send writes to its local endpoint; Aurora forwards them to the primary in us-east-1.
Deploy the European application in eu-west-1 and configure it to use the Aurora MySQL endpoint (reader or cluster endpoint) in the secondary Region.

Result:

US customers write to the primary in us-east-1.
European customers read locally (low latency) and write locally (writes forwarded transparently).
All changes propagate in near real time via Aurora’s fast global replication.
Single source of truth with no custom replication or conflict resolution needed.

This process has near-zero downtime when executed properly and is the standard method documented by AWS.

Why the Other Options Are Incorrect

Option B: RDS for MySQL supports cross-Region read replicas only. There is no native support for “replicate write queries back” or bidirectional replication. Implementing this would require complex, unmanaged MySQL logical replication with high risk of conflicts and lag.
Option C: Copying a snapshot creates a one-time copy, not continuous replication. Setting up MySQL logical replication between two separate RDS for MySQL instances is manual, error-prone, has higher lag, and does not support Aurora-style write forwarding (plain RDS MySQL lacks this feature).
Option D: Incorrect terminology. There is no direct “Convert” operation that turns an RDS for MySQL instance into an Aurora MySQL DB cluster. The proper path requires creating an Aurora read replica and then promoting it (as described in A). Using the word “Convert” makes this option imprecise for the exam.

Key Exam Takeaways

RDS MySQL → Aurora MySQL migration (minimal downtime) = Create Aurora read replica → wait for lag = 0 → (pause writes) → Promote to standalone cluster.
Aurora Global Database + Global Write Forwarding is the recommended AWS-managed pattern for active writes from multiple Regions with low latency and strong consistency.
Write forwarding requires Aurora MySQL compatible with MySQL 5.7 or higher and must be explicitly enabled. Applications in secondary Regions should set the aurora_replica_read_consistency parameter (e.g., 'session') to enable forwarding for the session.
Look for keywords like “write forwarding”, “secondary Region”, and the detailed migration steps in Professional-level questions.

This question tests precise knowledge of Aurora migration paths versus RDS limitations and when to use Aurora Global Database features.

Correct Choice: A

Comments (0)

No comments yet.

A company has deployed its database on an Amazon RDS for MySQL DB instance in the us-east-1 Region and needs to make its data available to customers in Europe. European customers require access to the same data as US customers without tolerating high application latency or stale data. Both US and European customers need to write to the database and see updates from the other group in real time. Which solution meets these requirements?

Exam-Like

Last updated: April 25, 2026 at 14:02

Create an Amazon Aurora MySQL replica of the RDS for MySQL DB instance, pause application writes to the RDS DB instance, promote the Aurora Replica to a standalone DB cluster, reconfigure the application to use the Aurora database and resume writes, add eu-west-1 as a secondary Region to the DB cluster, enable write forwarding on the DB cluster, deploy the application in eu-west-1, and configure the application to use the Aurora MySQL endpoint in eu-west-1.

31.3%

Add a cross-Region replica in eu-west-1 for the RDS for MySQL DB instance, configure the replica to replicate write queries back to the primary DB instance, deploy the application in eu-west-1, and configure the application to use the RDS for MySQL endpoint in eu-west-1.

18.8%