AZ-305 Design data storage solutions 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

  Why it's wrong here

  Azure SQL Database is a relational database that only permits a single read-write replica per database. Its active geo-replication and configurable failover groups can provide readable secondaries and automatic failover across regions, but these replicas are not writable simultaneously. There is no multi-master write support, meaning active-active configurations where multiple regions accept writes cannot be achieved. Additionally, its availability SLA is up to 99.99%, not the required 99.999%.

• ✓

  Azure Cosmos DB

  Why this is correct

  Cosmos DB is the correct choice because it natively supports multiple write regions for a single database account, enabling active-active writes from any Azure region. This multi-master capability, combined with service-managed replication and configurable consistency levels (Strong, Bounded Staleness, Session, etc.), allows you to meet the 99.999% availability SLA when you enable multi-region writes. It is a fully durable, globally distributed NoSQL database, making it perfect for globally distributed applications that need write access in multiple regions and continuous availability.

• ✗

  Azure Cache for Redis

  Why it's wrong here

  Azure Cache for Redis is an in-memory data store, not a fully durable transactional database. It is intended for high-throughput caching scenarios, and although it offers optional persistence (RDB snapshots or AOF), data loss is still possible and it is not designed as a consistent source of truth. Its geo-replication links caches in different regions but only allows reads from the secondary; you cannot perform multi-master writes across regions. Moreover, its availability SLA is lower than 99.999% and does not meet the durability expectations of the application.

• ✗

  Azure Table Storage

  Why it's wrong here

  Azure Table Storage is a NoSQL key-value store that provides high availability and massive scale, but it only supports a single writable region per storage account. It uses geo-redundant storage (GRS) to copy data to a secondary region, but that secondary is strictly read-only until a failover is manually or automatically triggered; you cannot have concurrent writes to both regions. Therefore, it cannot provide multi-master write capabilities or the 99.999% SLA that the solution requires, making it unsuitable for this global active-active architecture.

Go deeper

Related to this question