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 SQL Database with geo-replication

  Why it's wrong here

  Azure SQL Database with geo-replication establishes readable secondary replicas in other regions to support failover and disaster recovery, not multi-region write operations. These secondary replicas are read-only, meaning the database cannot accept writes in secondary regions; writes are always directed to the primary, and failover is a manual or automatic promotion process rather than an active-active multi-master design. Additionally, the latency benefit of geo-replication is primarily for mitigating regional outages, not for guaranteeing single-digit millisecond write latency on a global scale.

• ✓

  Azure Cosmos DB

  Why this is correct

  Azure Cosmos DB is a fully managed NoSQL database that provides turnkey global distribution across multiple Azure regions. Its multi-region writes capability (often called multi-master) allows every region to accept both reads and writes, while guaranteeing single-digit millisecond latencies at the 99th percentile globally. This makes it the only option that natively supports the required multi-master write model with low-latency access worldwide.

• ✗

  Azure Cache for Redis

  Why it's wrong here

  Azure Cache for Redis is an in-memory caching layer, not a persistent globally distributed database. It can deliver extremely low latency because it holds data in memory, but it is typically used to store frequently accessed data temporarily rather than as the source of truth. Although Redis supports replication and persistence, it does not provide the multi-master, multi-region write semantics of Cosmos DB—writes are ultimately made to a primary node, and data can be lost if the cache is not configured with durable persistence or if a multi-region configuration is not properly set up.

• ✗

  Azure Database for PostgreSQL with read replicas

  Why it's wrong here

  Azure Database for PostgreSQL with read replicas is designed to scale read workloads by copying data asynchronously to read-only replicas in the same or different regions. While this can place data closer to users for reads, the replicas do not accept write operations—all writes must go to the single primary server. This architecture lacks the multi-master write capability required to support concurrent writes from multiple geographic regions, so it cannot provide the global write distribution or sub-10ms latency guarantee needed.

Go deeper

Related to this question