AWS DMS Interview Questions: 20 Real Questions with Reference-Grade Answers

AWS DMS Serverless reached general availability in 2023, removing the instance-sizing guesswork that used to trip up both engineers and interviewers. Panels have pivoted accordingly: expect fewer questions about replication instance classes and more about CloudWatch metrics, capacity unit scaling, and failure-recovery design. This guide turns those grilling points — plus a curated set of real reported questions — into concise, reference-grade answers.

What AWS DMS interviews actually test

AWS DMS interview questions cluster around five categories that mirror the migration lifecycle: core concepts (endpoint types, task modes, SCT positioning), migration design (LOB handling, multi-table parallelism, partitioning for large tables), in-flight monitoring (CloudWatch metric interpretation and remediation), resilience and security (IAM roles, KMS, task restart semantics), and capacity and cost (DCU range tuning, inter-AZ transfer optimization). Interview stage determines depth: recruiter screens test vocabulary, technical rounds probe metric interpretation, and design rounds require a full architecture narrative — source capture, network topology, target landing zone, and rollback plan — typically under 45 minutes. For context on where DMS fits inside an end-to-end practice, see the data migration interview questions guide.

In this article, we’ll cover the following 20 questions:

1. What is AWS DMS and when would you choose it over native tools?
2. What is the difference between full-load and CDC (change data capture) modes?
3. How do you configure source and target endpoints, and what commonly goes wrong?
4. How does a homogeneous migration differ from a heterogeneous one, and where does Schema Conversion fit?
5. How does ongoing replication (CDC) keep the target in sync?
6. How does DMS handle LOB columns, and what are the tradeoffs of full vs limited LOB mode?
7. How do you validate that the migrated data is correct?
8. A CDC task fails mid-migration — how do you resume without re-copying everything?
9. Walk me through a zero-downtime cutover using DMS.
10. What does FullLoadThroughputRowsTarget tell you, and what do you do when it drops?
11. What is the difference between CDCLatencySource and CDCLatencyTarget?
12. What do CDCChangesAppliedTarget and CDCIncomingChanges indicate during replication?
13. A full load is far slower than expected — which metrics do you check first?
14. What are the most common DMS task failures, and how do you diagnose them?
15. When do you use a Multi-AZ replication instance, and what does it protect against?
16. How do you secure data in transit and at rest in a DMS migration?
17. How do you connect DMS to a database in a private VPC, and what IAM is involved?
18. How do you size a replication instance, or pick DMS Serverless capacity?
19. When would you choose DMS Serverless over a provisioned replication instance?
20. How do you keep a large DMS migration from blowing the budget?

Core AWS DMS concepts every candidate is expected to know

What is AWS DMS and when would you choose it over native tools?

Concept: Service positioning and migration tool selection | Difficulty: junior | Stage: recruiter

Direct answer: AWS Database Migration Service (AWS DMS) is Amazon’s managed service that moves data between relational databases, data warehouses, NoSQL stores, and streaming platforms with minimal downtime. Working through dms interview questions, be clear on when DMS earns its keep: choose it when the migration must stay live under production load, when the source or target runs outside AWS, or when you need continuous replication before a cutover window. Native tools — Oracle Data Pump, pg_dump, mysqldump — are faster for offline, same-engine lifts but require downtime and offer no CDC pipeline. DMS fills the gap when neither side can tolerate a hard stop, or when the engines differ enough that a native export is not portable.

What they’re really probing: Whether you reflexively reach for DMS or can reason about trade-offs — cost, complexity, and latency overhead versus the simplicity of a native dump-and-restore.

DMS supports over 20 source and target engine types — Oracle, SQL Server, PostgreSQL, MySQL, Aurora, Redshift, MongoDB, and S3 among them. Official capability details are in the AWS DMS documentation.

What is the difference between full-load and CDC (change data capture) modes?

Concept: Replication modes and migration phases | Difficulty: mid | Stage: technical

Direct answer: DMS questions on replication modes appear in nearly every technical screen. Full load copies all existing rows in a single bulk pass — fast for initial seeding but it does not capture changes that occur during the transfer. CDC (change data capture) reads the source transaction log and replicates only the insert, update, and delete events after a start point, keeping target data continuously synchronized. Full load + CDC combines both: DMS completes the bulk copy, then switches to log-based replication so no changes are lost during the load phase. This combined mode is the standard approach for live migrations because it eliminates the gap between the seed snapshot and ongoing transactions.

What they’re really probing: Whether you understand transactional consistency during migration — specifically that a full-load-only approach misses in-flight writes and that CDC depends on source database logging being enabled and retained long enough.

CDC requires the source to expose a transaction log: binary logging on MySQL/Aurora MySQL, logical replication slots on PostgreSQL, or supplemental logging on Oracle. Per-engine prerequisites are in the source database prerequisites guide.

How do you configure source and target endpoints, and what commonly goes wrong?

Concept: Endpoint configuration and operational troubleshooting | Difficulty: mid | Stage: technical

Direct answer: An endpoint in AWS DMS defines the connection details for a data store — engine type, hostname or ARN, port, credentials, and engine-specific extra connection attributes. Both source and target endpoints are created independently of the replication instance and can be tested via TestConnection before any task runs. Store credentials in AWS Secrets Manager and reference them by ARN rather than embedding in plaintext. The replication instance must have network reachability to both endpoints — within the same VPC, via VPC peering, or through Direct Connect/VPN for on-premises sources. Forgetting to open the correct security group inbound rules on the source database is the single most common configuration failure in practice.

What they’re really probing: Evidence that you have debugged a broken endpoint — network troubleshooting instincts, not form-filling knowledge.

The four most common endpoint mistakes:

• Security group not allowing inbound from the replication instance’s private IP on the database port.
• SSL mode mismatch — source requires TLS but endpoint has sslMode=none.
• Insufficient DB user privileges — DMS requires SELECT on all tables for full load, plus log-read privileges for CDC.
• Missing extra connection attributes (e.g., pluginName=pglogical for PostgreSQL logical replication).

How does a homogeneous migration differ from a heterogeneous one, and where does Schema Conversion fit?

Concept: Migration classification and schema tooling | Difficulty: mid | Stage: technical

Direct answer: A homogeneous migration moves data between two instances of the same engine — Oracle on-premises to Oracle on RDS, or MySQL to Aurora MySQL. Schema, data types, and procedural syntax are identical, so no translation is required and DMS transfers data directly. A heterogeneous migration crosses engine boundaries — Oracle to PostgreSQL, SQL Server to Aurora MySQL — and the schema must be converted first because data types, functions, and procedural code differ between engines. AWS Schema Conversion Tool (AWS SCT), now available as DMS Schema Conversion in the console, automates that translation: it converts compatible objects automatically and flags those it cannot so engineers can rewrite them manually. The conversion assessment report scores migration complexity before a project starts.

What they’re really probing: Whether you distinguish the data-movement problem (DMS) from the schema-translation problem (SCT), and understand that heterogeneous migrations carry additional risk because of manual remediation effort on unconverted objects.

The automatic conversion rate varies — stored procedure–heavy Oracle schemas convert 60–80%, leaving the rest for manual effort. Details are in the AWS SCT user guide, and the same heterogeneous-migration patterns surface in Azure data engineer interview questions.

AWS DMS migration design interview questions: CDC, LOBs, and cutover

How does ongoing replication (CDC) keep the target in sync?

Concept: Change Data Capture mechanics in DMS | Difficulty: mid | Stage: technical

Direct answer: AWS DMS Change Data Capture (CDC) reads the source transaction log — binary log in MySQL, redo log in Oracle, WAL in PostgreSQL — and replays committed changes against the target in near-real time. After the full-load phase, DMS switches to CDC mode automatically, reading each INSERT, UPDATE, and DELETE from the log and applying it in the same order, preserving transactional integrity. A replication instance polls the source log continuously; lag between source commit and target apply is typically seconds under normal load, but grows if the instance is undersized or if the target’s write throughput can’t keep up. This pattern underpins every zero-downtime strategy tested in aws migration interview questions.

What they’re really probing: Whether you understand that DMS sources changes log-based (not trigger-based) and can reason about lag, ordering guarantees, and what breaks when log retention is too short.

Log retention must cover the entire migration window — if it rotates before DMS consumes it, the task errors. For MySQL, set binlog_retention_hours ≥ 24; for Oracle, enable supplemental logging at the table or database level.

How does DMS handle LOB columns, and what are the tradeoffs of full vs limited LOB mode?

Concept: Large Object column replication strategy | Difficulty: mid | Stage: technical

Direct answer: AWS DMS offers three LOB replication modes. In limited LOB mode, DMS truncates each value to a configurable maximum size (default 32 KB), inlining it in the row buffer for fast throughput. In full LOB mode, DMS fetches each LOB column with a separate SELECT after inserting the row, preserving the full value but doubling source round-trips per LOB-containing row. Inline LOB mode is a middle path available when values are small enough to fit in the DMS buffer without a separate fetch. The right choice depends on whether your LOBs exceed the inline threshold and whether fidelity or speed is the priority.

What they’re really probing: Awareness that LOBs are a known DMS performance bottleneck and that the default limited mode can silently truncate data if the max size is misconfigured.

• Run SELECT MAX(OCTET_LENGTH(col)) FROM table on the source to find the actual maximum LOB size.
• Set the DMS task’s LOB max size to that value plus a buffer.
• Switch to full LOB mode only if values vary widely in size; expect a 20–40% throughput reduction.

This is not a theoretical risk. In a 2024 production postmortem, Smily staff engineer Karol Galanciak found DMS silently dropped data from JSON, array, and text columns until he switched modes, warning: “Use either Full LOB mode or Inline LOB mode, or you will lose data for many columns, especially with JSON, array, or text types.” See the AWS DMS LOB support documentation for configuration details.

How do you validate that the migrated data is correct?

Concept: Post-migration data integrity verification | Difficulty: mid | Stage: technical

Direct answer: AWS DMS includes a built-in data validation feature that compares rows between the source and target after the full-load phase and during CDC. DMS issues hash-based row comparisons in the background without blocking replication. Mismatched rows are recorded in the awsdms_validation_failures_v1 table on the target, with the primary key, failure type (row mismatch, missing row, extra row), and timestamp. For deeper assurance, teams complement DMS validation with AWS Glue row-count reconciliation or SQL scripts comparing aggregate checksums on both sides. Validation is non-negotiable for regulatory or financial data, where a silent LOB truncation or out-of-order CDC event could cause downstream corruption.

What they’re really probing: Whether validation is treated as a first-class step, and whether you know DMS has a native mechanism rather than requiring a separate tool for basic coverage.

Enable validation during the stabilization window, not peak traffic. LOB columns in full LOB mode are not validated and require separate spot-checks. See DMS data validation docs for limitations and the failure table schema.

A CDC task fails mid-migration — how do you resume without re-copying everything?

Concept: CDC recovery and checkpoint behavior | Difficulty: senior | Stage: technical

Direct answer: AWS DMS writes a CDC checkpoint (resume token) to the replication instance at regular intervals. The checkpoint encodes the source log position — a binary log offset for MySQL, an SCN for Oracle, an LSN for PostgreSQL — that DMS last applied to the target. Restarting a failed task with “Resume processing” makes DMS read that checkpoint and resume from that position rather than re-running the full load. The critical constraint: the source transaction log must still contain data from the checkpoint forward. If log retention has expired, the task cannot resume and a new full load is required. Extend log retention before starting any long-running migration.

What they’re really probing: That “resume” is not automatic magic — it depends on log retention being long enough to cover the outage window.

CdcStopPosition and RecoveryCheckpoint in describe-replication-tasks output show the last durable position. Tables in “Table error” state may need a manual reload before resume succeeds.

Walk me through a zero-downtime cutover using DMS.

Concept: End-to-end cutover orchestration | Difficulty: senior | Stage: system-design

Direct answer: A zero-downtime cutover with AWS DMS relies on CDC keeping the target continuously in sync, so the actual application switch window shrinks to seconds rather than hours. The discipline is to drain CDCLatencyTarget to near zero before committing, quiesce writes on the source, run a final validation pass, then repoint the application and hold the old source in read-only standby for rollback. This is a system-design staple in aws migration interview questions: it forces you to coordinate the database layer, the application layer, and CloudWatch monitoring together, rather than treating cutover as a single “stop task” button in the DMS console. Sequencing and rollback planning matter more than any individual command.

What they’re really probing: Correct step sequencing and knowledge of the failure modes — lag spike at peak traffic, CDC checkpoint expiry on a delayed cutover, or application clients caching the old connection string.

1. Run full load + CDC and let CDC lag stabilize to under 5 seconds.
2. Enable DMS data validation; confirm zero rows in the failure table.
3. Schedule a low-traffic window with a hard rollback deadline.
4. Quiesce writes — put the source in read-only mode (feature flag, maintenance page, or DB user revoke).
5. Wait for CDCLatencyTarget to hit 0 in CloudWatch, then stop the DMS task.
6. Run final validation — row counts and spot-check aggregates on both sides.
7. Switch connection strings — update application config, Secrets Manager, or DNS.
8. Verify application health and keep the source in read-only standby for 24–72 hours before decommission.

For the DMS-side cutover checklist, see AWS DMS best practices; the application-switch orchestration overlaps with deployment cutover patterns in Kubernetes interview questions.

AWS DMS monitoring: the CloudWatch metrics interviewers expect you to read cold

What does FullLoadThroughputRowsTarget tell you, and what do you do when it drops?

Concept: CloudWatch metric interpretation and performance tuning | Difficulty: mid | Stage: technical

Direct answer: FullLoadThroughputRowsTarget measures rows written to the target endpoint per second during a full-load phase. The unit is rows/second. A healthy baseline for a well-tuned replication instance (r5.xlarge or larger) sits between 5,000 and 20,000 rows/second; a sustained drop below 1,000 on large tables signals a problem. When the metric drops, the standard diagnostic sequence is: check CDCLatencyTarget to rule out network backpressure, inspect CPUUtilization and FreeMemory on the replication instance, then examine target-side write latency (e.g., RDS WriteLatency). Fixes include enabling parallel load, tuning the MaxFileSize LOB parameter, or right-sizing the replication instance. This metric is among the most-tested aws dms cloudwatch metric questions in senior screens.

What they’re really probing: Whether you’ve watched a real full-load run in production and know that a sagging metric rarely has a single cause — correlating two or three CloudWatch graphs simultaneously is the expected answer.

Parallel load settings under Table settings > parallel-load can dramatically raise FullLoadThroughputRowsTarget for partitioned or index-range-segmentable tables.

What is the difference between CDCLatencySource and CDCLatencyTarget?

Concept: CDC replication lag decomposition | Difficulty: mid | Stage: technical

Direct answer: CDCLatencySource measures the lag, in seconds, between the latest change in the source transaction log and the moment DMS reads it. CDCLatencyTarget measures the lag between when DMS reads a change and when it is applied to the target, capturing write backpressure. Both report in seconds; a healthy steady state is under 5 seconds for each. A spike in CDCLatencySource alone points to a reader bottleneck — undersized replication instance, source log purge racing the reader, or a network timeout. A spike in CDCLatencyTarget alone points to target write saturation — slow RDS writes, Aurora connection pool exhaustion, or LOB overhead. When both spike together, start with instance CPU and memory before drilling into endpoints.

What they’re really probing: Most candidates conflate the two into “replication lag.” Splitting them proves you’ve triaged a live CDC pipeline rather than read a config guide.

CDCLatency metrics report at the task level. For per-table throughput, pair them with CDCChangesAppliedTarget filtered by table statistics in the DMS console.

What do CDCChangesAppliedTarget and CDCIncomingChanges indicate during replication?

Concept: Change throughput balance and backlog detection | Difficulty: mid | Stage: technical

Direct answer: CDCChangesAppliedTarget measures change events (INSERTs, UPDATEs, DELETEs) written to the target per second. CDCIncomingChanges measures change events read from the source per second. Both report in events/second. The critical relationship: when CDCIncomingChanges persistently exceeds CDCChangesAppliedTarget, DMS is accumulating a backlog — the target cannot absorb changes as fast as they arrive, and CDCLatencyTarget climbs in parallel. A healthy replication shows the two metrics roughly equal. A delta of more than 20% sustained over 5 minutes warrants investigation. Common culprits: LOB replication (each LOB triggers an extra source SELECT), target connection pool exhaustion, or a DMS instance that’s CPU-bound on change parsing.

What they’re really probing: Do you treat cdcchangesapplied and cdcincomingchanges as a ratio rather than independent gauges? DMS is a pipeline with two distinct throughput constraints, not a single speed dial.

A CloudWatch alarm on CDCLatencyTarget crossing 30 seconds is a standard production hardening step.

A full load is far slower than expected — which metrics do you check first?

Concept: Systematic performance diagnosis for full-load phase | Difficulty: senior | Stage: technical

Direct answer: The diagnostic sequence for a slow full load:

1. FullLoadThroughputRowsTarget (rows/second) — establish the actual throughput baseline. Under 1,000 rows/second on a table with sub-1 KB rows is immediately suspicious.
2. CPUUtilization on the replication instance — if above 85%, the bottleneck is the DMS process itself; upgrade the instance class before tuning anything else.
3. FreeMemory on the replication instance — LOB replication and large batch sizes consume significant memory. Under 500 MB free on an r5.large with LOBs enabled warrants an instance resize.
4. FullLoadThroughputBytesTarget (bytes/second) — compare bytes to rows. If bytes/row is far higher than expected, LOB or wide-column handling is inflating per-row cost.
5. Target-endpoint write latency (e.g., RDS WriteLatency or Aurora DMLLatency) — eliminates the target as the bottleneck before changing DMS settings.

What they’re really probing: Systematic triage order. Jumping straight to “increase parallelism” without ruling out a CPU-bound replication instance is a common mistake that wastes time and money.

If steps 1–5 show healthy replication-instance metrics but slow throughput, check table-level statistics — a single unsupported column type can serialize the entire task.

What are the most common DMS task failures, and how do you diagnose them?

Concept: Operational failure patterns and root-cause methodology | Difficulty: senior | Stage: system-design

Direct answer: The most frequent DMS task failures fall into five categories. Source connectivity loss after the initial endpoint test usually traces to changed VPC security-group or NACL rules, or to lowered binlog/WAL retention on the source. LOB truncation or rejection appears when the LOB mode is mismatched to actual column sizes. CDC log-position loss — the most damaging — happens when the source purges its transaction log before DMS reads it, signalled by CDCLatencySource climbing into the thousands of seconds. Insufficient replication-instance storage stalls the task when FreeStorageSpace reaches zero, and target constraint violations break the full load on foreign-key or unique-index conflicts. The diagnostic method stays constant: read the Table statistics and Logs tabs first, because CloudWatch confirms the symptom while DMS-native logs identify the exact row and error code.

What they’re really probing: Whether you distinguish transient failures (network blip, resolvable with a task restart) from structural failures (log purge, LOB misconfiguration) that require configuration changes before any retry.

• Source endpoint connectivity loss — check VPC security group rules, NACLs, and whether the source’s binlog retention (MySQL) or WAL level (PostgreSQL) was lowered. The task error log shows the exact socket timeout or auth error.
• LOB column truncation or rejection — check table statistics for an AppliedInserts vs. DDLs mismatch and enable FullLobMode for the offending tables.
• CDC log position lost — set MySQL binlog_expire_logs_seconds or PostgreSQL wal_keep_size conservatively before starting the task.
• Insufficient replication instance storage — FreeStorageSpace dropping to zero stalls then fails the task; alert at 20% free.
• Target constraint violations — use target preparation mode “Do nothing” with pre-disabled constraints, then re-enable post-load.

AWS DMS resilience and security questions

When do you use a Multi-AZ replication instance, and what does it protect against?

Concept: high availability architecture for DMS | Difficulty: mid | Stage: technical

Direct answer: A Multi-AZ replication instance provisions a standby replica in a second Availability Zone and fails over automatically if the primary becomes unavailable — no manual intervention or task restart required, because DMS resumes from the last CDC checkpoint on the standby. Failover typically completes within 60 seconds. Use Multi-AZ for any production migration where downtime during the replication phase is unacceptable: CDC-based cutovers, long-running full-load tasks, and migrations bound by strict SLA windows. It does not protect against logical errors — wrong table mappings, bad transformation rules — or against source-database outages; it guards only against the replication instance itself failing or its Availability Zone going down. For the replication tier it is the single highest-value resilience setting.

What they’re really probing: Multi-AZ covers the replication instance tier, not the source or target. Can you articulate which failure scenarios it addresses versus the ones it does not?

Single-AZ is fine for one-time off-hours migrations where a restart is tolerable. For CDC replication spanning days, Multi-AZ cost is justified by avoiding a full-load restart from scratch.

How do you secure data in transit and at rest in a DMS migration?

Concept: encryption posture across DMS layers | Difficulty: mid | Stage: technical

Direct answer: AWS DMS covers two encryption surfaces. Data in transit: enable SSL on both the source and target endpoints — DMS supports SSL modes (require, verify-ca, verify-full) per endpoint; certificates are uploaded to DMS and validated against the database server. Data at rest: the replication instance’s storage and replication logs are encrypted using AWS KMS — specify a KMS key (CMK or AWS-managed) at instance creation and DMS encrypts all logs and cached row changes with it. Target-database encryption (RDS, S3, Redshift) is configured on that resource independently. IAM policies restrict who can create or modify endpoints and replication instances, adding an identity-level control layer.

What they’re really probing: Whether you treat encryption as two distinct concerns — network transport vs. storage — and know which DMS control surfaces govern each layer.

A common gap: assuming DMS inherits target encryption without verifying endpoint SSL settings. For regulated workloads, use customer-managed KMS keys (CMKs) to retain key rotation and access-revocation control. The DMS security docs cover both surfaces in detail, and the broader access-control patterns recur across AWS security interview questions.

How do you connect DMS to a database in a private VPC, and what IAM is involved?

Concept: network and identity prerequisites for DMS | Difficulty: senior | Stage: system-design

Direct answer: The replication instance must run inside the same VPC as the private database, or in a peered VPC with routable connectivity. The required network prerequisites are:

• Subnet group: create a DMS replication subnet group pointing to private subnets in the target VPC so DMS places the instance there.
• Security groups: the replication instance’s security group must have outbound rules to the source and target database ports; the database security groups must allow inbound from the replication instance’s security group.
• Route tables: no internet gateway required — traffic stays within the VPC or across a VPC peering/Transit Gateway link.

On the IAM side, DMS requires the dms-vpc-role (named exactly dms-vpc-role, with the AmazonDMSVPCManagementRole managed policy) to create elastic network interfaces in your VPC — without it, DMS cannot place the replication instance into your subnets. A second role, dms-cloudwatch-logs-role, is needed for task logs in CloudWatch. S3 targets or S3-sourced full-load files require a separate role attached to the endpoint.

What they’re really probing: Whether you’ve set up DMS in a locked-down environment and know the exact role names and trust policies AWS requires — not just “configure a VPC”.

The dms-vpc-role is account-scoped — it only needs to exist once per region. The console creates it automatically; CLI and IaC paths require explicit creation. See the DMS IAM roles reference for the trust policy and managed policy ARNs.

AWS DMS Serverless, capacity, and cost questions

How do you size a replication instance, or pick DMS Serverless capacity?

Concept: right-sizing compute and memory for throughput requirements | Difficulty: senior | Stage: system-design

Direct answer: For provisioned replication instances, profile peak transaction volume and row size first. A dms.t3.medium (2 vCPU, 4 GB RAM) handles light CDC loads under ~5 MB/s; a dms.c5.2xlarge (8 vCPU, 16 GB RAM) is a common baseline for large full-load migrations. For DMS Serverless, capacity is in DCUs (DMS capacity units) — each DCU is 2 vCPU / 4 GB RAM. Set a minimum (e.g., 1–4 DCU) and a maximum ceiling (e.g., 16 DCU); DMS auto-scales within that range based on CDC lag and throughput pressure. Lower-bounds prevent cold-start lag; upper-bounds cap spend. Monitor CDCLatencyTarget and FreeableMemory in CloudWatch to confirm the ceiling is not being hit during peak bursts.

What they’re really probing: That instance class and DCU range map directly to measurable throughput and latency metrics — they want evidence you’ve tuned these in practice, not just accepted defaults.

A useful heuristic: keep FreeableMemory above 20% during the full-load phase, then re-evaluate for CDC steady state, which needs less RAM but more consistent CPU.

When would you choose DMS Serverless over a provisioned replication instance?

Concept: operational trade-offs between managed scaling and predictable fixed capacity | Difficulty: mid | Stage: system-design

Direct answer: DMS Serverless is the right choice when CDC throughput is highly variable — a SaaS database that spikes during business hours and is nearly idle overnight. It eliminates capacity planning guesswork and the idle-instance cost that accumulates on a provisioned instance left running between phases. For steady, high-throughput migrations at 50+ MB/s, a provisioned instance is typically cheaper: the DCU auto-scaler can overshoot when handling large LOB columns, and there is no warm-up lag after a pause — which matters when your cutover SLA is tight. Serverless wins on operational simplicity and bursty workloads; provisioned wins on throughput predictability and sustained-high-volume cost.

What they’re really probing: Whether you treat Serverless as a blanket upgrade or understand its cost model well enough to know when it is actually more expensive. The nuance around LOB handling and warm-up behavior is a strong differentiator.

DCU scaling is capped at 256. At near-maximum capacity sustained for hours, run a cost model against a dms.c5.4xlarge provisioned instance — provisioned often wins at high sustained utilization.

How do you keep a large DMS migration from blowing the budget?

Concept: cost controls across data transfer, compute, and duration | Difficulty: senior | Stage: system-design

Direct answer: Budget overruns in DMS migrations trace to four sources: idle replication-instance hours, cross-AZ data transfer fees, unexpectedly long full-load duration, and LOB-handling overhead. The mitigations: (1) Place the replication instance in the same AZ as the source or target — this alone cuts transfer costs 50–80% on large migrations. (2) Use DMS Serverless with a tight DCU ceiling for variable-throughput phases so compute scales down at off-peak. (3) Enable parallel full-load with limited LOB mode to reduce wall-clock time, cutting instance-hours billed. (4) Stop or delete the replication instance when not migrating — stopped instances still incur storage costs; deleted instances stop all costs. Set a CloudWatch billing alarm on DMS-specific spend as a safety net.

What they’re really probing: Whether cost is a first-class design constraint in your migration architecture. They expect specific cost levers, not general best practices.

Limited LOB mode is the top cost lever: full LOB mode forces a separate round-trip per object, extending duration and instance-hours. Cap LOB size to the 95th-percentile actual value in the source — it eliminates the long tail without data loss in most workloads.

Questions to ask your AWS DMS interviewer

Asking sharp reverse questions signals that you think in systems, not just tasks. Consider asking:

• What is the peak transaction volume and row size on the source, and has that been measured or estimated?
• Is the cutover a hard maintenance window or a rolling cutover — what’s the acceptable downtime budget?
• Are you running AWS DMS data validation or a separate reconciliation job, and what discrepancy rate is acceptable?
• Has the team evaluated DMS Serverless, or is there a preference for provisioned instances for cost predictability?
• Are there CloudWatch alarms on CDCLatencyTarget in production, and who owns the on-call response?
• Are there heavy-LOB sources (BLOBs, CLOBs, JSON columns), and how has LOB mode been configured historically?

Your AWS DMS interview prep checklist

1. Run a full-load + CDC migration end-to-end in a sandbox. Use a free-tier RDS instance as source, a second as target, and walk through endpoint creation, task configuration, and cutover simulation. Hands-on reps eliminate the vague answers that trip up candidates who have only read the docs.
2. Wire a CloudWatch alarm on CDCLatencyTarget. Set a threshold at 60 seconds and confirm the alarm fires when you artificially stall the source — proof you can operationalize DMS monitoring, not just describe it.
3. Rehearse the zero-downtime cutover sequence. Stop application writes → wait for CDCLatencyTarget to hit 0 → switch connection strings → verify row counts. Time yourself; interviewers frequently ask for this step by step.
4. Review the DMS CloudWatch metrics reference — specifically FreeableMemory, CDCLatencySource, CDCThroughputRowsTarget, and FullLoadRowsInserted. Know what each metric tells you and which phase it applies to.
5. Study at least one failure mode in depth — LOB truncation, binary log retention expiry, or a failed Oracle-to-PostgreSQL schema conversion. Describing root cause and recovery signals real operational experience.
6. Pair DMS knowledge with adjacent tooling covered in the AWS DevOps interview questions guide — migration-heavy roles routinely include CloudFormation and Systems Manager questions in the same loop.

Running a real end-to-end migration — including a deliberate failure and recovery — is the highest-leverage prep: it surfaces edge cases (binary log gaps, LOB handling errors, schema-incompatibility failures) that no documentation reading replicates, and those are precisely what experienced interviewers probe.