Exercise 2: Cosmos DB's Real MongoDB API Advantage — Possible Solution
====================================================================

The team's application is already built against the MongoDB API --
meaning its own existing code, queries, and driver libraries all
speak MongoDB's real wire protocol directly. Cosmos DB's own real
multi-model support includes a genuine, wire-compatible MongoDB API
(compatible with wire protocol version 6, server version 3.6),
meaning the application's existing MongoDB queries and drivers can
largely continue working against Cosmos DB with minimal real changes
required.

DynamoDB has no real equivalent to this at all -- it exposes exactly
one, DynamoDB-specific API. Migrating the same MongoDB-based
application to DynamoDB would require genuinely rewriting its data
access layer from scratch to use DynamoDB's own different real query
model and API, a substantially larger real engineering effort than
simply pointing existing MongoDB-compatible code at a new endpoint.

ANSWER: Cosmos DB is the better real fit because its own MongoDB API
lets the team's existing MongoDB-based code continue working with
minimal real changes, while migrating to DynamoDB would require a
genuine rewrite of the application's entire data access layer to
match DynamoDB's own different, single API model.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the SPECIFIC real technical reason (wire
protocol compatibility avoiding a rewrite) rather than vaguely saying
"Cosmos DB is more flexible," and explicitly contrasts it against
DynamoDB's own real lack of any equivalent multi-API support,
directly matching the chapter's own stated point that this is a
genuine capability gap, not just a preference.