AWS DMS: Change Data Capture for Near-Zero Downtime

A full load is a photo of the database. By the time it finishes, the business has moved on. AWS DMS CDC (change data capture) keeps reading changes from the source after the full load, so the target stays a few seconds behind and the final outage is minutes instead of hours.

You’ll turn on MS-CDC on onprem-sql, run a full-load-and-cdc task with validation, make live changes and watch them arrive, then practise the cutover. After that you’ll break it in two ways that really happen on migration projects.

TimeYou needBy the end you can
100 minutesLesson 47 done (onprem-sql, saat-sql-se, the DMS endpoints and security groups). Cost: about USD 3 if you finish within two hours, mostly the two SQL Server Standard licenses. At the end you delete saat-sql-se and the DMS pieces; onprem-sql stays stopped for Lessons 49 and 50.Prepare a self-managed SQL Server source for CDC, run full-load-and-cdc with validation, read table statistics, plan a cutover, and fix credential and validation problems.

What it is, in one line

AWS DMS CDC replays inserts, updates and deletes from the source transaction log onto the target after the full load, so you can switch over with very little downtime.

In Simple Words

Copying a notebook while someone keeps writing

You’re copying a friend’s notebook, but they keep writing in it. You copy all the pages first. Then you sit next to them and copy each new line as soon as they write it.

When it’s time to leave, you ask them to put the pen down for one minute. You copy the last line, check both notebooks match, and go. That one minute is your downtime.

DMS does the same: full load copies the pages, CDC copies each new line from the transaction log, and cutover is the short pause at the end.

Engineer's View

How DMS CDC works with SQL Server

DMS reads the source transaction log (and log backups, if the log was truncated) and applies committed changes to the target in commit order. For the log to hold enough detail, a self-managed source needs the FULL or BULK_LOGGED recovery model, a full backup, and either MS-REPLICATION (a distributor and publication, for tables with primary keys) or MS-CDC (sys.sp_cdc_enable_db and sys.sp_cdc_enable_table, required for tables without a primary key).

The simple path gives the DMS user sysadmin. A non-sysadmin setup exists, with certificate-signed procedures and the enableNonSysadminWrapper attribute, and that’s what production should use.

DMS 3.4.7 and later can also set up MS-CDC for you with SetUpMsCdcForTables=true. On RDS for SQL Server sources, you use msdb.dbo.rds_cdc_enable_db instead.

Watch CDCLatencySource and CDCLatencyTarget in CloudWatch, and use table statistics for inserts, updates, deletes and validation. With validation on, DMS compares rows between source and target and records differences in awsdms_validation_failures_v1 on the target. If DMS stops for a while, the source log must be kept until it catches up, otherwise the task fails and you reload.

How it works, step by step

Here is what happens in a full-load-and-cdc task.

1DMS notes where the log is

When the task starts, DMS records the current log position, then begins the full load.

How AWS DMS change data capture reads the transaction log and applies changes

2Full load, then cached changes

While tables load, changes keep arriving. DMS caches them and applies them as soon as each table finishes, so nothing is missed.

3Ongoing replication

From then on, DMS reads each committed change from the log and applies it to the target, usually within seconds.

4Cut over

The cutover is a short, planned sequence:

Near-zero downtime cutover steps with AWS DMS CDC

The source stays as it was until you are sure. If the new system misbehaves, the old one is still there for rollback.

✅ Checkpoint: You can explain why CDC needs the full recovery model and MS-CDC or MS-REPLICATION, and list the cutover steps in order.

Hands-on lab: keep RDS in sync with CDC and cut over

Sign in, start both servers and look up what Lesson 47 left:

cd C:\aws-lab
aws login --profile saat-admin
$env:AWS_PROFILE = 'saat-admin'
$v = Get-Content C:\aws-lab\saat-vpc.json | ConvertFrom-Json
$src = aws ec2 describe-instances --filters "Name=tag:Name,Values=onprem-sql" "Name=instance-state-name,Values=stopped,running" --query "Reservations[0].Instances[0].InstanceId" --output text
aws ec2 start-instances --instance-ids $src | Out-Null
.\Start-SqlLab.ps1 -Db saat-sql-se -LocalPort 11434
do { Start-Sleep 20; $p = aws ssm describe-instance-information --filters "Key=InstanceIds,Values=$src" --query "InstanceInformationList[0].PingStatus" --output text } until ($p -eq 'Online')
$dmsSg = aws ec2 describe-security-groups --filters "Name=group-name,Values=saat-dms-sg" --query "SecurityGroups[0].GroupId" --output text
$srcSg = aws ec2 describe-security-groups --filters "Name=group-name,Values=saat-onprem-sql-sg" --query "SecurityGroups[0].GroupId" --output text
$srcEp = aws dms describe-endpoints --filters "Name=endpoint-id,Values=saat-onprem-src" --query "Endpoints[0].EndpointArn" --output text
$tgtEp = aws dms describe-endpoints --filters "Name=endpoint-id,Values=saat-rds-se-tgt" --query "Endpoints[0].EndpointArn" --output text
"$src $dmsSg $srcSg"

You should see something like this:

Tunnel ready on 127.0.0.1,11434 for saatadmin (password is in SQLCMDPASSWORD for this window)
i-0a1b2c3d4e5f60718 sg-0d1e2f3a4b5c6d7e8 sg-0a9b8c7d6e5f4a3b2

If you deleted saat-sql-se after Lesson 47, recreate it with the first command from that lesson and create the SaatShop database before going on.

1Prepare the source for CDC

Paste this whole block. It adds a helper that runs SQL on onprem-sql, resets dms_user’s password, and turns on MS-CDC:

function Invoke-Src([string]$Sql) {
  $line = 'sqlcmd -S . -E -C -h -1 -W -d SaatShop -Q "SET NOCOUNT ON; ' + $Sql + '"'
  @{ commands = @($line) } | ConvertTo-Json | Set-Content src-cmd.json
  $cmd = aws ssm send-command --document-name AWS-RunPowerShellScript --instance-ids $src --parameters file://src-cmd.json --query Command.CommandId --output text
  do { Start-Sleep 5; $st = aws ssm get-command-invocation --command-id $cmd --instance-id $src --query Status --output text 2>$null } until ($st -in 'Success', 'Failed', 'TimedOut')
  aws ssm get-command-invocation --command-id $cmd --instance-id $src --query StandardOutputContent --output text
}
$dmsPw = aws secretsmanager get-random-password --password-length 20 --exclude-punctuation --require-each-included-type --query RandomPassword --output text
Invoke-Src "ALTER LOGIN dms_user WITH PASSWORD = '$dmsPw'; ALTER SERVER ROLE sysadmin ADD MEMBER dms_user;" | Out-Null
aws dms modify-endpoint --endpoint-arn $srcEp --password $dmsPw | Out-Null
aws dms modify-endpoint --endpoint-arn $tgtEp --password $env:SQLCMDPASSWORD | Out-Null
Invoke-Src "ALTER DATABASE SaatShop SET RECOVERY FULL; BACKUP DATABASE SaatShop TO DISK = 'C:\sqlbak\saatshop-cdc.bak' WITH INIT; EXEC sys.sp_cdc_enable_db; EXEC sys.sp_cdc_enable_table @source_schema = N'dbo', @source_name = N'Orders', @role_name = NULL, @supports_net_changes = 1; SELECT CONCAT(name, ' | ', recovery_model_desc, ' | cdc ', is_cdc_enabled) FROM sys.databases WHERE name = 'SaatShop';"

You should see something like this (the last lines):

BACKUP DATABASE successfully processed 6330 pages in 0.412 seconds (120.017 MB/sec).
Job 'cdc.SaatShop_capture' started successfully.
Job 'cdc.SaatShop_cleanup' started successfully.
SaatShop | FULL | cdc 1

The full backup starts the log chain, and MS-CDC creates two SQL Agent jobs: one captures changes, the other cleans old ones. Both endpoints now have current passwords.

The target’s managed password rotates every 7 days, which is why you refresh it each session. dms_user is sysadmin to keep the lab short; production uses the non-sysadmin setup from the DMS guide.

2Start the replication instance and the CDC task

Paste this whole block (about 15 minutes, most of it the replication instance):

$ri = aws dms create-replication-instance --replication-instance-identifier saat-dms --replication-instance-class dms.t3.medium --allocated-storage 20 --replication-subnet-group-identifier saat-dms-subnets --vpc-security-group-ids $dmsSg --no-publicly-accessible --no-multi-az --tags Key=course,Value=saatvedha-aws Key=lesson,Value=48 --query ReplicationInstance.ReplicationInstanceArn --output text
aws dms wait replication-instance-available --filters "Name=replication-instance-arn,Values=$ri"
foreach ($ep in $srcEp, $tgtEp) { aws dms test-connection --replication-instance-arn $ri --endpoint-arn $ep | Out-Null }
foreach ($ep in $srcEp, $tgtEp) { aws dms wait test-connection-succeeds --filters "Name=endpoint-arn,Values=$ep" }
'{ "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "dbo-all", "object-locator": { "schema-name": "dbo", "table-name": "%" }, "rule-action": "include" } ] }' | Set-Content mappings.json
'{ "Logging": { "EnableLogging": true }, "FullLoadSettings": { "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD" }, "ValidationSettings": { "EnableValidation": true } }' | Set-Content task-cdc.json
$task = aws dms create-replication-task --replication-task-identifier saat-shop-cdc --source-endpoint-arn $srcEp --target-endpoint-arn $tgtEp --replication-instance-arn $ri --migration-type full-load-and-cdc --table-mappings file://mappings.json --replication-task-settings file://task-cdc.json --query ReplicationTask.ReplicationTaskArn --output text
aws dms wait replication-task-ready --filters "Name=replication-task-arn,Values=$task"
aws dms start-replication-task --replication-task-arn $task --start-replication-task-type start-replication | Out-Null
aws dms wait replication-task-running --filters "Name=replication-task-arn,Values=$task"
do { Start-Sleep 20; $ts = aws dms describe-table-statistics --replication-task-arn $task --query "TableStatistics[0].[TableState,FullLoadRows,ValidationState]" --output text; $ts } until ($ts -match 'Table completed' -and $ts -match 'Validated')

You should see something like this:

Before load     0       Not enabled
Full load       21504   Pending records
Table completed 50003   Pending records
Table completed 50003   Validated

The full load finished and validation confirmed all 50,003 rows match. The task is still running: it’s now following the source’s transaction log.

3Make live changes and watch them arrive

Paste this whole block:

Invoke-Src "INSERT dbo.Orders (Customer, Amount) SELECT TOP (100) CONCAT(N'Live ', ROW_NUMBER() OVER (ORDER BY (SELECT NULL))), 150.00 FROM sys.all_objects; UPDATE dbo.Orders SET Amount = 2999.00 WHERE OrderId = 1; DELETE dbo.Orders WHERE OrderId = 2; SELECT COUNT(*) FROM dbo.Orders;"
Start-Sleep 60
aws dms describe-table-statistics --replication-task-arn $task --query "TableStatistics[].[TableName,Inserts,Updates,Deletes,ValidationState]" --output text
sqlcmd -S "127.0.0.1,11434" -U saatadmin -C -d SaatShop -h -1 -Q "SET NOCOUNT ON; SELECT COUNT(*) FROM dbo.Orders; SELECT Amount FROM dbo.Orders WHERE OrderId = 1;"

You should see something like this:

50102
Orders  100     1       1       Validated
      50102
    2999.00

100 inserts, one update and one delete reached saat-sql-se within a minute, and the counts match. The app on onprem-sql never stopped.

AWS DMS CDC task saat-shop-cdc with ongoing replication, validated table statistics and low latency
The CDC task in DMS: inserts, the update and the delete applied, validation passed, latency in seconds.
AWS DMS CDC lab output: inserts, updates and deletes applied and validated
Changes arriving and validated on the target. Something like this.

4Practise the cutover

In real life you stop the app first. Here nothing else writes, so check, compare and stop the task:

$srcCount = (Invoke-Src "SELECT COUNT(*) FROM dbo.Orders;").Trim()
$tgtCount = (sqlcmd -S "127.0.0.1,11434" -U saatadmin -C -d SaatShop -h -1 -W -Q "SET NOCOUNT ON; SELECT COUNT(*) FROM dbo.Orders;" | Select-Object -First 1).Trim()
"source $srcCount  target $tgtCount"
aws dms stop-replication-task --replication-task-arn $task | Out-Null
aws dms wait replication-task-stopped --filters "Name=replication-task-arn,Values=$task"
aws dms describe-replication-tasks --filters "Name=replication-task-arn,Values=$task" --query "ReplicationTasks[0].Status" --output text

You should see something like this:

source 50102  target 50102
stopped

That’s the cutover moment: counts match, validation is clean, and the task is stopped. Next you’d change the app’s connection string to the RDS endpoint. In a real move, the target would already have the full schema from Lesson 49, with identity columns, defaults and indexes.

✅ Checkpoint: MS-CDC is on for SaatShop, the task ran full-load-and-cdc with validation, 100 inserts, 1 update and 1 delete arrived, both sides show 50,102 orders, and the task is stopped.

Break It, Then Fix It

Two problems that turn up on real migrations.

1Break it: the target password rotates

Rotate saat-sql-se’s managed master password, as AWS does every 7 days, then test the target endpoint:

$secretArn = aws rds describe-db-instances --db-instance-identifier saat-sql-se --query "DBInstances[0].MasterUserSecret.SecretArn" --output text
aws secretsmanager rotate-secret --secret-id $secretArn | Out-Null
Start-Sleep 90
aws dms test-connection --replication-instance-arn $ri --endpoint-arn $tgtEp | Out-Null
do { Start-Sleep 15; $cs = aws dms describe-connections --filters "Name=endpoint-arn,Values=$tgtEp" --query "Connections[0].Status" --output text } until ($cs -ne 'testing')
aws dms describe-connections --filters "Name=endpoint-arn,Values=$tgtEp" --query "Connections[0].[Status,LastFailureMessage]" --output text

You’ll get something like this:

failed  Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider ODBC general error., Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 28000 NativeError: 18456 Message: [unixODBC][Microsoft][ODBC Driver for SQL Server][SQL Server]Login failed for user 'saatadmin'.

The endpoint still holds last week’s password. A task that is already running keeps its connections, but it fails the next time it reconnects, often at 3 a.m. Fix: read the new password and update the endpoint (production endpoints should read the secret from Secrets Manager instead, so rotation can’t break them):

$s = aws secretsmanager get-secret-value --secret-id $secretArn --query SecretString --output text | ConvertFrom-Json
$env:SQLCMDPASSWORD = $s.password
aws dms modify-endpoint --endpoint-arn $tgtEp --password $s.password | Out-Null
aws dms test-connection --replication-instance-arn $ri --endpoint-arn $tgtEp | Out-Null
aws dms wait test-connection-succeeds --filters "Name=endpoint-arn,Values=$tgtEp"
aws dms describe-connections --filters "Name=endpoint-arn,Values=$tgtEp" --query "Connections[0].Status" --output text

You should see this:

successful

2Break it: someone writes to the target before cutover

Resume the task, change a row on the target directly, then ask DMS to revalidate:

aws dms start-replication-task --replication-task-arn $task --start-replication-task-type resume-processing | Out-Null
aws dms wait replication-task-running --filters "Name=replication-task-arn,Values=$task"
sqlcmd -S "127.0.0.1,11434" -U saatadmin -C -d SaatShop -Q "UPDATE dbo.Orders SET Amount = 1.00 WHERE OrderId = 3;"
aws dms reload-tables --replication-task-arn $task --tables-to-reload SchemaName=dbo,TableName=Orders --reload-option validate-only | Out-Null
do { Start-Sleep 20; $vs = aws dms describe-table-statistics --replication-task-arn $task --query "TableStatistics[0].[ValidationState,ValidationFailedRecords]" --output text; $vs } until ($vs -notmatch 'Pending')
sqlcmd -S "127.0.0.1,11434" -U saatadmin -C -d SaatShop -Q "SELECT TABLE_NAME, [KEY], FAILURE_TYPE FROM awsdms_validation_failures_v1"

You’ll get something like this:

Mismatched records      1
TABLE_NAME KEY                 FAILURE_TYPE
---------- ------------------- ------------
Orders     {"OrderId": 3}      RECORD_DIFF
AWS DMS CDC problems: rotated target password and validation mismatch
Both problems and their fixes. Something like this.

Someone “just tested” the app against the new server, and now one row differs from the source. CDC won’t repair it on its own, because nothing changed that row on the source.

Validation is how you catch this before go-live. Fix: reload the table from the source; validation then runs again:

aws dms reload-tables --replication-task-arn $task --tables-to-reload SchemaName=dbo,TableName=Orders --reload-option data-reload | Out-Null
do { Start-Sleep 20; $vs = aws dms describe-table-statistics --replication-task-arn $task --query "TableStatistics[0].[TableState,ValidationState]" --output text; $vs } until ($vs -match 'Table completed' -and $vs -match 'Validated')
sqlcmd -S "127.0.0.1,11434" -U saatadmin -C -d SaatShop -h -1 -Q "SET NOCOUNT ON; SELECT Amount FROM dbo.Orders WHERE OrderId = 3;"

You should see something like this:

Table completed Validated
    3200.00

Now clean up everything DMS used. onprem-sql goes back to normal (CDC off, no sysadmin for dms_user, simple recovery) and stays stopped for Lessons 49 and 50:

aws dms stop-replication-task --replication-task-arn $task | Out-Null
aws dms wait replication-task-stopped --filters "Name=replication-task-arn,Values=$task"
aws dms delete-replication-task --replication-task-arn $task | Out-Null
aws dms wait replication-task-deleted --filters "Name=replication-task-arn,Values=$task"
aws dms delete-replication-instance --replication-instance-arn $ri | Out-Null
aws dms delete-endpoint --endpoint-arn $srcEp | Out-Null
aws dms delete-endpoint --endpoint-arn $tgtEp | Out-Null
aws dms wait replication-instance-deleted --filters "Name=replication-instance-arn,Values=$ri"
aws dms delete-replication-subnet-group --replication-subnet-group-identifier saat-dms-subnets
Invoke-Src "EXEC sys.sp_cdc_disable_db; ALTER SERVER ROLE sysadmin DROP MEMBER dms_user; ALTER DATABASE SaatShop SET RECOVERY SIMPLE; DROP TABLE IF EXISTS dbo.awsdms_truncation_safeguard;" | Out-Null
aws ec2 revoke-security-group-ingress --group-id $srcSg --ip-permissions "IpProtocol=tcp,FromPort=1433,ToPort=1433,UserIdGroupPairs=[{GroupId=$dmsSg}]" | Out-Null
aws ec2 revoke-security-group-ingress --group-id $v.DbSg --ip-permissions "IpProtocol=tcp,FromPort=1433,ToPort=1433,UserIdGroupPairs=[{GroupId=$dmsSg}]" | Out-Null
aws ec2 delete-security-group --group-id $dmsSg
aws ec2 stop-instances --instance-ids $src | Out-Null
.\Stop-SqlLab.ps1 -Db saat-sql-se -KeepDbRunning
aws rds delete-db-instance --db-instance-identifier saat-sql-se --skip-final-snapshot --query "DBInstance.DBInstanceStatus" --output text
Remove-Item mappings.json, task-cdc.json, src-cmd.json

✅ Checkpoint: You fixed a rotated password by updating the endpoint and a validation mismatch by reloading the table. The DMS task, instance, endpoints, subnet group and saat-dms-sg are gone, saat-sql-se is deleting, and onprem-sql is stopping with CDC turned off.

This happened at work

The cutover that waited for a report

A hospital group moved its appointments database to RDS using DMS CDC. Latency was under five seconds for three weeks. On cutover night, latency suddenly climbed to 40 minutes.

A monthly report had started on the source at 11 p.m. and updated two million rows in one transaction. DMS can only apply a change after it’s committed, so the target waited for the report to finish, then worked through the backlog. The cutover window was almost gone before latency came back down.

They moved the cutover to the next night, after pausing batch jobs and watching CDCLatencySource on a CloudWatch dashboard. The runbook now lists every scheduled job on the source and says when to turn each one off.

Common mistakes and troubleshooting

MistakeWhat happensWhat to do
Source in SIMPLE recoveryCDC can’t read changes reliablyFULL recovery and a full backup first
Tables without primary keys and no MS-CDCUpdates and deletes not capturedEnable MS-CDC for those tables
Passwords typed into endpointsTask fails after rotationSecrets Manager for endpoints, or refresh after rotation
Testing apps against the target earlySilent differencesKeep the target read-only; turn on validation
Log backups deleted or moved while DMS is behindTask fails, full reload neededKeep log backups until DMS has passed them
Big batch jobs during cutoverLatency spikes for hoursPause batch jobs; watch CDCLatencySource

Interview questions

Click a question to open it. Each one is written the way an interviewer would ask it. Under it you will see why they ask it and one way you could answer, in your own words.

Fresher level

1. Can you explain in simple words what CDC means in AWS DMS?

Why they ask this: They want to check that you understand how DMS keeps the target up to date after the first copy. This is the idea behind low-downtime migrations.

How you might answer: CDC stands for change data capture. After the full load copies the existing data, DMS keeps reading committed changes from the source transaction log and applies them to the target.

I explain it like copying a notebook and then writing down every new line your friend adds, so both stay the same.

2. You want to run CDC from a SQL Server source. What do you need to set up on the source first?

Why they ask this: They want to see that you know the prerequisites, because CDC tasks fail quickly when the source isn’t ready.

How you might answer: The database needs FULL or BULK_LOGGED recovery and a full backup taken. Then I need MS-REPLICATION for tables with primary keys, or MS-CDC, which is needed for tables without primary keys.

If the source is RDS, I enable it with rds_cdc_enable_db, because I don’t have sysadmin there.

3. How would you tell your manager the target database has caught up with the source?

Why they ask this: They want to know you measure progress with real numbers instead of guessing. It also shows you know which DMS metrics matter.

How you might answer: I’d show the CDCLatencySource and CDCLatencyTarget metrics, and both should be close to zero. I’d also check the table statistics in the task.

Finally I’d confirm validation shows Validated for the tables, so I know the data matches and not just the timing.

2–5 years experience

4. It’s the middle of a migration and CDC latency jumps from a few seconds to an hour. What do you check?

Why they ask this: They want to see a calm, step-by-step approach. The key point is knowing which metric tells you whether the source side or the target side is slow.

How you might answer: First I compare CDCLatencySource with CDCLatencyTarget, because that tells me which side is behind. If the source side is high, I look for long-running transactions or batch jobs on the source.

If the target side is high, I check how fast the target can apply changes, which means indexes, triggers, LOBs and instance size. I also check CPU and memory on the replication instance, and the network.

5. Why would you turn on validation in a DMS task, and what does it cost you?

Why they ask this: They want to see that you care about data quality and also understand the extra load it brings.

How you might answer: Validation compares rows between source and target and records any mismatches. It catches problems that a simple row count would miss.

The cost is extra load on both databases and on the replication instance, so I size things with that in mind.

6. Walk me through how you’d do the cutover at the end of a DMS migration.

Why they ask this: They want to see that you follow a clear order of steps and keep a way back. A messy cutover is where most migrations go wrong.

How you might answer: I freeze changes and stop the app, then wait for latency to reach zero. I compare counts and check validation, and only then stop the task.

Next I switch the connection strings or DNS, and enable jobs and triggers on the target. I keep the source as it is so I can roll back if needed.

Senior level

7. Your team is about to cut over a big DMS migration. How would you design the rollback plan?

Why they ask this: They want to see how you handle risk and make decisions under pressure. Senior people are expected to plan for failure, not just success.

How you might answer: I keep the source untouched, and if the business needs it I run a reverse CDC task from the target back to the source after cutover. That way the old database stays current.

I agree a decision deadline for rolling back, test the rollback during a rehearsal, and keep DNS TTLs low so a switch back is quick.

8. Say you’re asked to migrate 200 databases with DMS. How would you organise the work?

Why they ask this: They want to see if you can scale a process beyond one database. They are looking for templates, automation, monitoring and a plan in waves.

How you might answer: I’d group the databases by size and change rate, and build standard endpoint and task templates in IaC. Each wave would get DMS Serverless or a right-sized instance, with endpoint passwords in Secrets Manager.

I’d set CloudWatch alarms on latency and errors, keep validation on, and use a cutover runbook for each wave.

Quick quiz

Q1. What does CDC add after a full load?

  1. Index creation
  2. Ongoing changes from the log
  3. Backups
  4. Schema conversion
Show answer

B — It replays inserts, updates and deletes.

Q2. Which recovery model does a CDC source need?

  1. SIMPLE
  2. FULL or BULK_LOGGED
  3. Any
  4. None
Show answer

B — Changes must stay in the log for DMS.

Q3. Why did the target endpoint fail with login failed?

  1. Network
  2. The managed password rotated
  3. Express edition
  4. Validation
Show answer

B — The endpoint held the old password.

Q4. What caught the row changed on the target?

  1. Row counts
  2. Validation
  3. CloudTrail
  4. Backups
Show answer

B — Validation compares row values.

Q5. What is the right order at cutover?

  1. Switch app, then stop task
  2. Stop app, wait for zero latency, compare, stop task, switch
  3. Delete source first
  4. Reload all tables
Show answer

B — Let the last changes arrive before switching.

Quick recap

  • full-load-and-cdc copies the data, then follows the transaction log.
  • A self-managed source needs FULL recovery, a full backup and MS-CDC or MS-REPLICATION.
  • Validation and CDC latency tell you when it’s safe to cut over.
  • Rotated passwords break endpoints; use Secrets Manager.
  • Never write to the target before cutover.

Next lesson

Lesson 49: DMS Schema Conversion and SCT → You’ll convert SaatShop’s schema, procedures and triggers, and see what DMS needs help with.

Further reading: AWS DMS CDC

Want to go deeper into AWS DMS CDC? Read Capturing data changes for ongoing replication from SQL Server and AWS DMS data validation. You can also see the full plan for this course on the AWS Cloud Administration course page.

Scroll to Top