SAP-C02 Practice Question 39: Minimal Downtime Database Cutover
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 4 · question 9 of 10
A retailer must move a 6 TB self-managed MySQL 8.0 database from its data centre to Amazon Aurora MySQL-Compatible Edition. A 10 Gbps AWS Direct Connect connection is already in place. A rehearsal showed that a logical dump and restore of the full data set takes about 11 hours.
The business will approve only a 15-minute cutover window, during which the application is stopped. The team must be able to demonstrate to the release board, before the window opens, that the rows in the target match the rows in the source, and the schema does not need to change because the source and target engines are compatible.
What should the migration team do?
Show answer and explanation
Answer:
AWS DMS offers a "full load plus CDC" task type that migrates the existing data and then keeps the target updated from changes on the source. For MySQL, DMS reads those changes from the row-based binary logs, so the 11-hour bulk copy happens while the application is still running and is not inside the outage window. By the time the window opens, the target is within seconds of the source, and the 15 minutes are spent stopping the application, letting the last transactions apply, and repointing connections. DMS data validation compares source and target rows and reports differences, which is the evidence the release board wants before the window rather than after it. One caveat worth knowing: AWS notes that CDC is not real-time replication and latency varies with load, which is why the plan waits for latency to approach zero rather than assuming it.
Option B produces the right end state through the most fragile possible path. Hand-applying binlogs with a custom script during a 15-minute window offers no validation, no retry, and no way to prove correctness to the board.
Option C is wrong on both halves. The migration is homogeneous, so no schema conversion is needed, and a CDC-only task replicates ongoing changes to a target that is assumed to already hold the data; with no full load, the 6 TB of existing rows never arrive.
Option D is a legitimate way to seed an Aurora MySQL cluster, and it is faster than a logical dump, but it is a point-in-time copy with no ongoing replication. The application would have to stay down for the whole upload and restore, far beyond 15 minutes.
Reference: Creating tasks for ongoing replication using AWS DMS