AZ-900 Describe Azure architecture and services Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Azure Cosmos DB for Apache Cassandra

  Why it's wrong here

  Azure Cosmos DB for Apache Cassandra is a compatibility layer over Cosmos DB's proprietary engine, not a native installation of open-source Cassandra. While it accepts Cassandra Query Language (CQL) over the wire protocol, it maps operations to Cosmos DB resources with Request Units (RUs), leading to differences in throttling, consistency, and feature support. It also lacks some advanced Cassandra features like materialized view semantics and SSTable-level internals. Therefore, it is not the correct fully managed open-source Cassandra service.

• ✓

  Azure Managed Instance for Apache Cassandra

  Why this is correct

  Azure Managed Instance for Apache Cassandra is the only Azure service that runs the real open-source Cassandra codebase as a fully managed offering. It natively supports CQL, transparent failover, auto-tuned repairs, and separate clusters for each datacenter, enabling active-active multi-region writes. With its managed node lifecycle and built-in monitoring, it removes the overhead of manual Cassandra operations while preserving compatibility for existing drivers and applications. This makes it the correct choice for a native Cassandra database with multi-region write support.

• ✗

  Azure Table Storage with Cassandra drivers

  Why it's wrong here

  Azure Table Storage is a schema-less key-value store that exposes a REST API, not Cassandra's binary CQL protocol or its distributed partition-row architecture. Cassandra drivers expect nodes that speak the Cassandra gossip and thrift/CQL protocols, so they cannot authenticate or query Table Storage endpoints without a custom middleware bridge. Table Storage also lacks Cassandra's tunable consistency levels (e.g., QUORUM) and multi-region write conflict resolution. For a true Cassandra workload, you need a service that implements CQL natively.

• ✗

  Azure HDInsight with Cassandra

  Why it's wrong here

  Azure HDInsight is a big-data analytics platform for frameworks like Hadoop and Spark, and Cassandra is not a first-class HDInsight cluster type. You can manually install and configure Cassandra on HDInsight nodes, but that approach requires you to handle any Cassandra-specific monitoring, patching, and failure recovery yourself. It also cannot natively coordinate multi-region writes across HDInsight clusters because the service is not designed for Cassandra cross-datacenter replication. This deployment pattern is fragile and unsupported, so it is not the correct managed solution.