DynamoDB Global Tables: SAA-C03 resilience scenarios

A Global Table keeps a fully readable and writable replica in every configured Region and replicates changes between them, so each Region serves local writes and either can carry the load if the other degrades — no promotion step, no custom pipeline. Why not the others: DynamoDB has no 'read replica' construct — that is RDS vocabulary dropped in as a trap. CloudFront caches reads and cannot make a single-Region table accept writes elsewhere. A nightly copy job is custom, lossy and one-directional, so the second Region is never active. Multi-Region, active-active, managed: Global Tables.

Global Tables use last-writer-wins conflict resolution: DynamoDB compares timestamps and converges every replica on the most recent update, so the system stays available and eventually consistent without human intervention. Why not the others: writes are not rejected on conflict — that would break the active-active promise. There is no manual-merge queue. And there is no single primary Region; every replica accepts writes, which is exactly what makes the design active-active. Knowing that conflicts resolve automatically by timestamp is the point the exam tests.

Every Global Table replica is independently readable and writable, so surviving a Region loss is simply a matter of directing traffic (via Route 53 or the application's Regional endpoints) to a healthy replica — there is nothing to promote and no data to restore. Why not the others: there is no primary to promote, because no replica is subordinate. Restoring from backup is slow and unnecessary when a live, current copy already exists. And writes never depend on the failed Region — the whole reason to run a Global Table is that the other Regions keep working. Live replicas everywhere is what makes the RTO near-zero.

DynamoDB Streams emits an ordered record of every create, update and delete, which Lambda can consume for event-driven processing — and the same stream mechanism is what propagates changes between Global Table replicas. Why not the others: CloudTrail logs control-plane and data-plane API activity for audit, not a per-item change feed for application logic. DynamoDB does not natively publish item changes to SNS. A scheduled scan is expensive, misses ordering and adds latency. One ordered change feed underpins both event-driven apps and cross-Region replication: Streams.

Point-in-time recovery keeps continuous, automatic backups and lets you restore to any single second within the last 35 days, which is exactly what recovering from an accidental delete or a bad deploy requires. Why not the others: a Global Table replicates the erroneous write too — it protects against Region loss, not logical corruption. On-demand backups are discrete snapshots, so you can only return to the moments you happened to capture, not to an arbitrary second. Streams retain records for just 24 hours and are a change feed, not a restore mechanism. Continuous, any-second restore is PITR.

On-demand capacity mode requires no capacity planning: DynamoDB scales instantly with traffic and charges per request, so unpredictable, spiky, multi-Region workloads neither throttle nor pay for idle headroom. Why not the others: provisioning for peak wastes money during the long quiet stretches. A low fixed ceiling throttles the very spikes the requirement says to survive. Reserved capacity discounts a steady, predictable baseline — the opposite of unforecastable traffic. When the workload is unknown and bursty and the requirement is 'no tuning', on-demand is the answer; provisioned auto scaling only wins when a predictable baseline justifies its lower cost.

A global secondary index gives the table an alternate partition/sort key for a new query pattern, has its own capacity, and is carried into every Region of a Global Table — so the email lookup works everywhere without touching write availability. Why not the others: a local secondary index must be defined at table creation and shares the base table's partition key, so it cannot be added later or query a wholly different attribute. A Scan with a filter reads the entire table and is slow and costly at scale. Changing the partition key would break every existing access pattern. Alternate query paths that scale and replicate are global secondary indexes.