Describe considerations for working with non-relational data on Azure →mediumMultiple ChoiceObjective-mapped

DP-900 Practice Question: Describe considerations for working with non-relational data on Azure

Exhibit

{
  "databaseAccountOfferType": "Standard",
  "capabilities": [
    {
      "name": "EnableCassandra"
    }
  ],
  "locations": [
    {
      "locationName": "West US",
      "failoverPriority": 0
    },
    {
      "locationName": "East US",
      "failoverPriority": 1
    }
  ],
  "consistencyPolicy": {
    "defaultConsistencyLevel": "Session"
  }
}

Refer to the exhibit. You are reviewing an Azure Cosmos DB account configuration. Which API is this account configured to use?

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

✓

Cassandra API

The 'capabilities' array includes 'EnableCassandra', which indicates the Cassandra API is enabled. Option C is correct. Option A (Table API) would have 'EnableTable', Option B (SQL/Core API) would have 'EnableSQL' or no capability, and Option D (MongoDB API) would have 'EnableMongo'.

Answer analysis

Option-by-option breakdown

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

✗
Table API
Why it's wrong here
The Table API is enabled by setting the 'EnableTable' capability on an Azure Cosmos DB account, not 'EnableCassandra.' This exhibit shows 'EnableCassandra' as the only API-enabling property, which means the account is configured for Cassandra API's CQL-based wide-column model, not the key-value/wide-column Table API. If it were Table API, you would see an EnableTable flag and have Azure Table Storage-compatible endpoints. Therefore, the Table API cannot be the correct answer.
✗
SQL (Core) API
Why it's wrong here
The SQL (Core) API is the default API for Azure Cosmos DB and is always enabled without any explicit capability flag; you don't add 'EnableSql' to the account properties. In the exhibit, the account includes the 'EnableCassandra' property, which would be absent in a pure SQL API account. A SQL API account would instead showcase document-level indexing policies and a SQL query endpoint, not Cassandra-specific flags. Because the account explicitly opts in to Cassandra compatibility, the SQL (Core) API is not the API represented.
✓
Cassandra API
Why this is correct
The Cassandra API for Azure Cosmos DB is specifically activated by the 'EnableCassandra' capability flag in the account configuration, and the exhibit clearly shows this property set to true. This flag tells Azure to expose Cassandra-compatible endpoints that accept CQL and work with existing Cassandra drivers. When this flag is enabled, Cosmos DB manages Cassandra tables, partitions, and replication under the hood, giving you Cassandra's query language with Cosmos DB's global distribution. Therefore, the presence of EnableCassandra definitively identifies this as a Cassandra API account.
✗
MongoDB API
Why it's wrong here
The MongoDB API is turned on by setting the 'EnableMongo' capability, whereas the exhibit shows 'EnableCassandra' instead—there is no Mongo marker anywhere in the properties. While both MongoDB and Cassandra APIs are NoSQL, MongoDB uses the BSON document format and its own aggregation pipeline, while Cassandra uses CQL tables with partition keys and materialized views. A MongoDB API account would expose a MongoDB-compatible wire protocol on port 10255, not Cassandra's native protocol. Since the flag present is EnableCassandra, the MongoDB API is definitively wrong.

Go deeper

DP-900 Practice Question: Describe considerations for working with non-relational data on Azure

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question