DP-900 Describe core data concepts 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 Database for MySQL with read replicas

  Why it's wrong here

  Read replicas in Azure Database for MySQL rely on asynchronous replication from the primary server to the replica, so data changes on the primary are not guaranteed to be immediately visible on the replica. For an e-commerce system tracking inventory and orders, this means queries against a replica may return stale data, and the read-only replica cannot accept writes or be promoted automatically for writes. This makes it unsuitable as the primary transactional store and insufficient for meeting strong consistency or high-availability write requirements.

• ✗

  Azure Synapse Analytics

  Why it's wrong here

  Azure Synapse Analytics is a large-scale, distributed analytics platform built for online analytical processing (OLAP) workloads, using columnar storage and massively parallel execution. It is not optimized for high-frequency, low-latency insert, update, or delete operations that characterize e-commerce transaction processing, and its pricing and architecture assume large scans rather than point operations. Consequently, it cannot serve as the operational data store for an e-commerce system, which needs ACID-compliant, real-time transactional writes.

• ✓

  Azure SQL Database with active geo-replication

  Why this is correct

  Azure SQL Database with active geo-replication maintains asynchronous, readable secondary replicas in paired or other Azure regions, preserving a mature relational database engine with full ACID transactions on the primary. This design provides a geographically distributed read scale and enables a controlled failover to a secondary region if an outage occurs, delivering a strong high-availability and disaster-recovery posture for a business-critical e-commerce application. The secondaries can also serve read-only traffic, offloading workload from the primary, while writes remain on the primary to maintain consistency.

• ✗

  Azure Cosmos DB with multiple write regions

  Why it's wrong here

  Azure Cosmos DB when configured with multiple write regions does not support the 'strong' consistency level, so replicas across regions may diverge and require conflict-resolution policies for concurrent updates. For e-commerce, which relies on consistent reads and writes for inventory counts and order records, eventual or bounded-staleness consistency can lead to lost updates, overselling, or stale cart information visible to users. The operational complexity of conflict resolution and the impossibility of strong consistency make multi-region writes a poor fit for a transactional e-commerce data store.

Go deeper

Related to this question