A team has an existing app that uses the Azure Table Storage SDK to store settings as key-value entities. They want to move the data to a globally distributed database with low-latency reads while changing as little application code as possible. Which option fits?
Show answer and explanation
Answer: A
Azure Cosmos DB for Table keeps the Table storage data model and works with the existing Table SDK calls, so the application needs minimal code changes. It adds global distribution and low-latency reads and writes backed by Cosmos DB's service levels. The other APIs would require new query languages or drivers, which is exactly what this migration goal avoids. Choosing the Table API is the simplest path for an existing Table-based app.
Why the other options are wrong
- B. The Core SQL API uses SQL query syntax and its own SDK. Moving table entities there means rewriting the data access code, which goes against the requirement to change as little as possible.
- C. The MongoDB API expects documents and the MongoDB wire protocol. Existing Table SDK calls would not work against it, so the application would need a new driver and a code rewrite.
- D. The Cassandra API is built for wide-column workloads and CQL. It does not accept calls from the Table SDK, so it would also require rewriting the data access layer.
Exam tip. For existing Table storage code moving to Cosmos DB, choose the Table API to keep the SDK calls.