DOP-C02 Resilient Cloud Solutions Practice Question

A company uses Amazon DynamoDB with global tables for a multi-region active-active application. They notice that occasionally, concurrent updates to the same item in different regions cause data inconsistency. How can they resolve this?

⚠ Common exam trap

Candidates often assume DynamoDB global tables automatically resolve all write conflicts, but the exam tests the understanding that without conditional writes or custom conflict resolution, concurrent updates can cause data inconsistency due to eventual consistency.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use conditional writes and design the application to handle conflicts

DynamoDB global tables use an eventually consistent model for multi-region replication, meaning concurrent updates to the same item in different regions can lead to conflicts. Conditional writes allow the application to enforce a last-writer-wins (LWW) strategy or custom conflict resolution logic, ensuring data consistency by only applying updates that meet specified conditions (e.g., a version number or timestamp check). This approach aligns with the recommended practice for handling concurrent writes in an active-active global table setup.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Disable global tables and use a single region
Why it's wrong here
Single-region deployment eliminates the distributed nature of the application, making it vulnerable to region-wide outages and increasing latency for users far from that region. Global tables exist precisely to provide multi-region writes and reads with conflict resolution, so disabling them abandons the required resilience and availability benefits rather than solving the write conflict problem.
✗
Use DynamoDB read replicas instead of global tables
Why it's wrong here
Read replicas in DynamoDB scale read throughput but do not accept writes, so they cannot address concurrent write conflicts across regions. The issue involves multiple regions writing to the same item, which requires a multi-writer solution with conflict resolution, not read scaling. Global tables are the feature that supports multi-region writes; read replicas only help with read-heavy workloads.
✓
Use conditional writes and design the application to handle conflicts
Why this is correct
Conditional writes use attribute-based conditions (e.g., version numbers or timestamps) to ensure a write only succeeds if the item hasn't changed since the last read, preventing blind overwrites. Since DynamoDB global tables use last-writer-wins by default, application-level conflict resolution—such as storing version metadata and retrying with reconciliation logic—gives you control over which update wins. This approach aligns with DynamoDB's recommended pattern for multi-region applications that require strong consistency for business-critical updates.
✗
Use DynamoDB Accelerator (DAX) to cache writes
Why it's wrong here
DAX is an in-memory cache that reduces read latency by offloading read-heavy workloads, and it writes through to DynamoDB asynchronously, providing no conflict detection or resolution semantics. It operates in a single region, so it cannot coordinate writes across global table replicas or handle concurrent updates to the same item. Therefore, DAX offers zero benefit for resolving write conflicts in a multi-region setup.

Visual reference

Go deeper

DOP-C02 Resilient Cloud Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question