Jeff Barr says in this article exactly how it works: when you make a write in one region, it streams the updates to the other regions. Presumably this is built on top of the DynamoDB Streams system. It tags the item update with a timestamp, and in the event of a conflict the most recent wins.

So in the case of a partition where the update stream is delayed, other regions can read and write to their local copy of the tables. They'll be replicated when the partition is healed. You should design around the possibility of conflicts, so that the 'last writer wins' resolution does what you want and leaves the system in a consistent state.

It would be nice if it emitted an event when write-write conflicts occur, so you can monitor that and possibly add your own conflict resolution logic to patch things up afterward. It doesn't appear like this exists.

Yes, you sacrifice freshness. When healthy, regions are behind by ~1s. If you need consistent writes then you can use one as the 'primary' region and do all your writes there and use the others as read replicas. But it's better to design your system to not require full consistency and do reads and writes in the local region.

(Disclaimer: I work for Amazon, but not in AWS and have nothing to do with this project.)

No need to be uncertain, the article outlines this pretty clearly:

"Behind the scenes, DynamoDB implements multi-master writes and ensures that the last write to a particular item prevails. When you use Global Tables, each item will include a timestamp attribute representing the time of the most recent write. Updates are propagated to other Regions asynchronously via DynamoDB Streams and are typically complete within one second"

In terms of access you're still touching a regional table, and while you can make use of things like conditional expressions they are limited to the regional table's view of the data.