Design data storage solutions practice questions

Premium SSD (non-v2) for the database and Azure NetApp Files for the file share.

Why it fails: Premium SSD (v1) has a maximum of 20,000 IOPS per disk (depending on size), which may not consistently achieve 50,000 IOPS unless using disk striping or larger disks. Azure NetApp Files can support high throughput but is more expensive than Azure Files Premium for simple file shares.

Standard SSD for the database and Azure Blob Storage for the file share.

Why it fails: Standard SSD provides at most 6,000 IOPS (for largest disks), far below 50,000. Azure Blob Storage is not suitable as a shared file system requiring SMB or NFS protocols without additional configuration (like Azure Files).

A

Why it fails: Azure Files (standard) provides SMB file shares but its IOPS and throughput performance may be insufficient for high-performance workloads.

C

Why it fails: Azure Blob Storage is accessed via REST API and is not designed for SMB file sharing or low-latency shared access required by the application.

D

Why it fails: Azure Disk Storage can be attached to a single VM and cannot be mounted by multiple VMs simultaneously for active-active sharing.

Azure SQL Database with active geo-replication across two regions and failover groups.

Why it fails: Azure SQL Database with active geo-replication and failover groups is incorrect because active geo-replication establishes only a single writable primary; secondary replicas in other regions are strictly read-only, and failover groups simply automate promoting a secondary to primary in a disaster scenario. This architecture does not support concurrent writes from multiple regions—let alone automatic conflict resolution—so an application cannot place orders in two regions simultaneously and have both writes succeed as peers. While failover groups improve availability with a defined RTO and RPO, any client write traffic must always be directed to the current primary, creating a global write bottleneck and failing the core requirement of multi-region write support.

Azure Cache for Redis with geo-replication.

Why it fails: Azure Cache for Redis with geo-replication is not a viable database solution for this requirement because Redis Cache is an in-memory caching layer, not a durable primary data store; it does not provide the persistence, ACID guarantees, or transaction durability expected for order placement records. Geo-replication for Azure Cache for Redis (including the Enterprise tier's active geo-replication) ultimately replicates cached data asynchronously, which yields eventual consistency and risk of data loss during regional failover, not strong consistency for individual operations. Even if multiple regions could accept writes in the Enterprise tier, the service is still optimized for low-latency reads of transient data, not as a system of record with automatic conflict resolution—so it fundamentally cannot serve as the authoritative database for a global e-commerce platform.

Azure Table Storage with geo-redundant storage (GRS) and read-access (RA-GRS).

Why it fails: Azure Table Storage with geo-redundant storage (GRS) and read-access (RA-GRS) fails the requirement because GRS/RA-GRS only maintains a single writable primary region; the secondary region is a read-only, asynchronously replicated copy. This means multi-region writes are unsupported by design—any write must be sent to the primary endpoint, and while RA-GRS lets clients read from the secondary, those reads may be stale because replication is eventual, with strong consistency guaranteed only within the primary region. Additionally, Azure Table Storage has no built-in automatic conflict resolution mechanism, so if you tried to manually route writes to the secondary (which is not possible for writes anyway), there is no way to reconcile conflicting updates. As a result, it fails both the multi-region write requirement and the strong consistency requirement for order placement.

Azure Cosmos DB with single-master and multiple read regions

Why it fails: A single-master configuration designates one regional account as the sole writable replica; all other regions are read-only replicas. IoT telemetry ingestion is a globally distributed write-heavy workload, so every device write would have to traverse the network to that one region, adding latency and creating a throughput bottleneck. Multiple read regions only improve read scalability and geo-distribution for reads, not write ingestion performance. Consequently, this fails the requirement for low-latency writes from all regions.

Azure Cosmos DB with multi-master and default strong consistency

Why it fails: Multi-master permits writes in any region, but defaulting to strong consistency forces every write to be synchronously replicated and acknowledged by a quorum of replicas across all participating regions before the commit returns. That synchronous replication sharply increases write latency and can degrade availability during regional outages, which is particularly harmful for high-volume telemetry ingestion. Strong consistency is only required for a subset of operations, such as device command reads, not for telemetry write ingestion. Using it as the default across all operations fails the latency and availability requirements.

Azure Cosmos DB with multi-master and eventual consistency only

Why it fails: Eventual consistency alone cannot satisfy the strong-consistency requirement for device command reads; the account must combine multi-region writes with a stronger default or per-request consistency level. Eventual consistency is tempting because it suits globally distributed dashboard queries, and would be correct if every read tolerated stale replicas.

Azure Files

Why it fails: Azure Files is wrong because it delivers fully managed SMB and NFS file shares intended for scenarios where applications need traditional file-share semantics (e.g., lift-and-shift, on-premises file server replacement, or shared configuration). It does not expose a primary REST API for object-style access; instead, it functions as a network file system with mount points and a maximum share size far below Blob Storage's exabyte-scale capacity. While useful for shared file access across VMs or on-premises clients, it is not optimized for storing and serving massive unstructured data directly via web APIs.

Azure Data Lake Storage Gen2

Why it fails: Azure Data Lake Storage Gen2 is built on Blob Storage and adds a hierarchical file system. It is ideal for big data analytics but may be unnecessary for the stated requirement for simple media storage without the need for POSIX permissions.

Azure Disk Storage

Why it fails: Azure Disk Storage is wrong because its block-level volumes are exclusively attached to Azure VMs via VHD, requiring a running operating system to manage the file system. It is not accessible through REST APIs and cannot be directly used by external clients or services over the internet. Disks are also performance-bound by VM SKU and incur costs even when the underlying VM is stopped, and they lack tiering/storage lifecycle policies. Hence, disk storage is meant for performance-critical I/O of a single VM, not for scalable, shared, unstructured object storage.

Azure SQL Database with active geo-replication

Why it fails: Azure SQL Database with active geo-replication is a relational database that supports a single primary writable region. Active geo-replication asynchronously replicates transactions to readable secondary replicas in other regions, but those secondaries do not accept writes. While this provides disaster recovery and read scaling, it cannot handle multi-region write workloads, and the asynchronous replication does not guarantee single-digit millisecond write latency across the globe.

Azure Table Storage

Why it fails: Azure Table Storage is a schemaless NoSQL key-value store that stores entities as rows and columns. It does not natively support JSON documents or flexible hierarchical schemas, and it does not offer multi-region write capabilities. Replication options are read-access geo-redundant storage (RA-GRS) or geo-redundant storage (GRS), which provide only an eventually consistent read-only secondary and no write conflict resolution, so it cannot achieve single-digit millisecond latencies for globally distributed write operations.

Azure Database for PostgreSQL with read replicas

Why it fails: Azure Database for PostgreSQL with read replicas supports cross-region read scaling by copying changes from a primary server to read-only replicas. All write traffic must still go to the single primary region; replicas cannot accept writes, and replication is asynchronous, meaning data loss or lag can occur. This architecture does not provide multi-region write support or the sub-10-millisecond latency guarantees required for a globally distributed e-commerce application.

Azure NetApp Files with SMB volumes.

Why it fails: Azure NetApp Files SMB volumes support AD DS identity-based access and low-latency, fully managed performance, but the stem's requirement is satisfied by Azure Files with AD DS authentication, which is the managed SMB file-share service. NetApp Files suits high-performance workloads needing extreme throughput.

Azure Blob Storage with NFS 3.0 support.

Why it fails: NFS 3.0 does not speak SMB, so the application cannot access files, and it lacks AD DS identity-based authentication. It is tempting because Blob Storage is fully managed and low latency, and NFS suits Linux workloads needing POSIX file access rather than Windows SMB shares.

Azure Managed Disk with a file server VM.

Why it fails: A file server VM is IaaS, not fully managed, so the company still patches and maintains the OS. It is tempting because Managed Disk plus a VM reproduces the existing SMB and AD DS joined file server exactly, which suits lift-and-shift migrations where full control is required.

Move to Cool tier immediately (0 days) and then to Archive after 30 days

Why it fails: This policy is invalid because Azure lifecycle management rules require a minimum age condition of 1 day; a value of 0 days for the transition is not allowed. Even if a 0-day transition were technically possible, moving blobs directly to Cool without a short Hot period would risk higher retrieval costs for any early access, and the 30-day Archive move is acceptable only after the initial rule is corrected to at least 1 day. Therefore, the policy as written cannot be deployed and would fail validation.

Move to Archive tier after 1 day

Why it fails: While the Archive tier is cheap, moving directly to Archive after 1 day is not optimal because data might still be accessed occasionally during the first 30 days, and early deletion or unnecessary retrieval costs could apply. The recommended practice is to use Cool as an intermediate tier.

Move to Cool tier after 30 days and to Archive after 90 days

Why it fails: This policy would keep data in the Hot tier for 30 days, incurring higher costs for the first month, and then move to Cool for the remaining 60 days. It does not leverage the low cost of Archive for the bulk of the retention period.

Azure Cosmos DB with multiple write regions and strong consistency

Why it fails: Azure Cosmos DB cannot combine multiple write regions with strong consistency because strong consistency requires a single write master that serializes all writes synchronously across replicas. When you enable multiple write regions, Cosmos DB only offers bounded staleness, session, consistent prefix, or eventual consistency. Selecting strong consistency would force a single write region, eliminating the multi-master benefits and global write distribution, so the scenario would not meet the multi-region write requirement.

Azure Database for MySQL with read replicas

Why it fails: Azure Database for MySQL read replicas are asynchronous copies intended exclusively to scale read traffic rather than provide automated disaster recovery. If the primary region fails, an administrator must manually promote a replica, and because replication lags, the replica may lack transactions committed just before the outage. There is no built-in automatic failover, no active geo-replication to a secondary region, and no support for ongoing writes on the secondary, so this option cannot satisfy the DR requirement for a critical global e-commerce workload.

Azure SQL Managed Instance with failover groups

Why it fails: Azure SQL Managed Instance failover groups provide disaster recovery between a paired primary and secondary instance, but this is a single-instance HA/DR mechanism, not a globally distributed database service. Failover operates at the instance level, meaning all databases on the instance switch over together, and the secondary is not actively used for writes until a failover event. Unlike Azure SQL Database's per-database active geo-replication, this option lacks the flexibility to run multiple geographically distributed databases with independent automatic failover, making it less appropriate for a global e-commerce architecture.

Azure Blob Storage

Why it fails: Azure Blob Storage is a massively scalable object store with an optional hierarchical namespace, but it exposes REST APIs and SDKs rather than native SMB semantics. Mounting a blob container on a VM requires an abstraction such as BlobFuse or a file gateway, which introduces compatibility, caching, and performance overhead. For a workload where hundreds of VMs need a simple common SMB share, Blob Storage is not a drop-in replacement and its use would complicate client access.

Azure NetApp Files

Why it fails: Azure NetApp Files offers enterprise-grade SMB and NFS volumes with advanced data-management features, but it is engineered for low-latency, IOPS-heavy HPC, database, and VDI workloads. It has a significantly higher per-gigabyte cost and requires capacity-pool provisioning with minimum throughput commitments, making it overkill for general-purpose unstructured file sharing where the primary need is just large, accessible storage. Choosing it for this scenario would incur unnecessary expense without adding functional benefit.

Azure Managed Disks

Why it fails: Azure Managed Disks are durable block-level VHDs that a single VM attaches and formats with a guest operating system file system. A managed disk is bound to one VM at a time, and even the Azure Shared Disks feature supports only a small cluster of VMs, not hundreds. Consequently, managed disks cannot provide concurrent SMB file access to the many machines that need to read the same unstructured data, so this option fails the core requirement of shared access.

Hot tier

Why it fails: The Hot tier is designed for data that is accessed or modified frequently, and it carries the highest storage cost among Azure Blob Storage tiers. Because the video files are only infrequently accessed, storing them here would incur unnecessary expenditure for performance they don't need. While Hot offers minimal latency and no retrieval charges, that benefit is wasted when requests are sporadic, making Cool a more economical fit.

Cold tier

Why it fails: The Cold tier offers an even lower storage price than Cool, but it comes with a 90-day minimum storage duration and higher per-access charges. For media streaming, where each playback may require occasional access to large files, those access penalties would accumulate and could outweigh the storage savings. Additionally, the extended retention period reduces operational flexibility, so Cold is not the optimal trade-off for this workload.

Archive tier

Why it fails: The Archive tier is intended for long-term backup and compliance data that is rarely if ever accessed, and it requires rehydration lasting up to 15 hours before files can be read. That retrieval latency makes immediate video playback impossible, and the 180-day minimum storage period plus high retrieval fees further penalize any streaming use. Since the scenario demands instant availability for media files, Archive fails the core functional requirement and is therefore unsuitable.

Azure Cosmos DB with analytical store

Why it fails: Azure Cosmos DB with analytical store is wrong for this workload because Cosmos DB is a multi-model NoSQL database optimized for general-purpose transactional applications, not for sustained high-velocity time-series ingestion. The analytical store is designed for large-scale analytic queries over transactional data using Synapse Link, but it does not offer low-latency warm queries on the ingest path or automatic cold tiering specific to time-series retention. Additionally, the request unit (RU) consumption for high-ingestion can become cost-prohibitive, and you would need to build custom partitioning and TTL policies to mimic time-series behavior.

Azure Event Hubs with Azure Data Lake Storage

Why it fails: Azure Event Hubs with Azure Data Lake Storage is wrong because this combination separates ingestion from queryable storage but does not deliver the required time-series query experience. Event Hubs is a highly scalable streaming ingestion service that can absorb massive event throughput, but it is not a queryable data store; once events are consumed, they are not retained for warm, low-latency analytical queries. While Data Lake Storage offers cheap cold storage for raw event data, it lacks a native time-series query engine, automatic warm/cold tiering, and built-in analytics, meaning you would need to build additional services to provide the functionality TSI gives out of the box.

Azure SQL Database with elastic query

Why it fails: Azure SQL Database with elastic query is wrong because a relational row-store engine is not suited for high-ingestion, append-heavy time-series workloads. Elastic query is merely a feature for querying across multiple Azure SQL databases, not a mechanism for automatically managing time-based retention or warm/cold storage tiers. Ingesting millions of time-series points per second would require extensive sharding, partitioning, and index maintenance, while SQL queries over ordered timestamps still lack the specialized interpolation, downsampling, and event correlation functions that a time-series store provides.

Azure Files

Why it fails: Azure Files is an SMB/NFS file share service intended for shared application files and lift-and-shift workloads, not as a repository for Azure VM backup data. It provides file snapshots and soft delete, but it does not offer native VM-consistent backup integration, much less the WORM/immutability controls required for backup retention. Storing backup images there would require custom copying logic and would fail to meet cost/lifecycle management needs.

Azure NetApp Files

Why it fails: Azure NetApp Files is a high-performance enterprise file storage platform with advanced data management features like multi-protocol access and volume-level snapshots. However, it is designed for production workloads such as VDI, SAP, and HPC, not for low-cost backup archiving; its snapshot capability is file-volume oriented, not Azure VM-consistent, and it cannot act as a native Backup vault. Additionally, its pricing model is far too expensive for long-term backup data retention.

Azure Disk Storage

Why it fails: Azure Disk Storage provides page blobs/block-level managed disks attached to Azure VMs and is the wrong medium for storing backup data because it lacks the versioning, immutability, and lifecycle management found in object storage. To persist backup data on disks, you would need to attach them to an active VM, incurring compute and disk costs even when the data is idle, and you would still need separate tooling to manage retention. Backups should be copied to a storage service purpose-built for high-durability, policy-driven archival, not kept as VM disks.

Zone-redundant deployment

Why it fails: Protects within region, not disaster recovery.

Auto-failover groups with active geo-replication

Why it fails: RTO is typically minutes, but the question specifies 1 hour.

Geo-restore

Why it fails: RPO is 1 hour, not 5 seconds.

Azure SQL Database

Why it fails: Azure SQL Database is a fully managed relational database service built on the SQL Server engine, which does not natively recognize Oracle's PL/SQL procedural language, proprietary data types, or syntax such as packages, synonyms, and hierarchical queries. While schema migration tools can convert objects, the application's stored procedures and triggers would require extensive rewriting to T-SQL, so it cannot serve as a drop-in replacement for an Oracle database. This lack of built-in Oracle compatibility makes Azure SQL Database an unsuitable target for a legacy application migration without significant code changes.

Azure Cosmos DB

Why it fails: Azure Cosmos DB is a globally distributed, multi-model NoSQL database that stores data as JSON documents, key-value pairs, graphs, and column families, and it does not support relational schemas, SQL joins, or stored procedures in the same manner as Oracle. Its query language is focused on NoSQL operations and offers no support for PL/SQL, synonyms, or Oracle's procedural constructs, making a direct migration impossible without fully redesigning the application and data model. As a result, Azure Cosmos DB is fundamentally incompatible with a legacy Oracle application.

Azure Database for MySQL

Why it fails: Azure Database for MySQL is a managed service running the MySQL database engine, which uses a significantly different SQL dialect than Oracle. MySQL lacks several Oracle features such as packages, materialized views, REF CURSORs, and Oracle-specific system functions like SYSDATE and CONNECT BY, and it uses a different procedural syntax for stored routines. Consequently, migrating the application would require a substantial rewrite of both schema and code, so Azure Database for MySQL is not a valid direct destination for an Oracle workload.

Azure SQL Database with active geo-replication

Why it fails: Active geo-replication provides readable secondaries with a single write region, so it cannot deliver multi-region writes or conflict resolution. It is tempting because it does offer cross-region replication and failover for structured relational workloads requiring disaster recovery rather than active-active writes.

Azure Cache for Redis

Why it fails: Incorrect: Azure Cache for Redis is a caching service, not a primary data storage solution, and does not provide multi-region write capabilities.

Azure Table Storage

Why it fails: Incorrect: Azure Table Storage (non-Cosmos) does not natively support multi-region writes with conflict resolution.

Azure Files

Why it fails: Azure Files supports customer-managed keys (CMK) only for premium file shares that use the SMB protocol; standard file shares rely on Microsoft-managed keys and cannot be encrypted with your own keys from Azure Key Vault. This limitation prevents universal use of CMK for all sensitive data stored in Azure Files, especially when standard performance tiers are involved, making it an incorrect choice if the requirement demands full customer control over encryption keys.

Azure Cache for Redis

Why it fails: Azure Cache for Redis encrypts data both in transit and at rest, but it does not support customer-managed keys (CMK). All encryption keys are Microsoft-managed, so you cannot integrate Azure Key Vault to bring your own keys or control key lifecycle. This absence of CMK support disqualifies Azure Cache for Redis for scenarios where customers must have full control over encryption keys to protect sensitive data.

Azure Cosmos DB

Why it fails: Azure Cosmos DB supports customer-managed keys (CMK) at the account level using Azure Key Vault; however, it is a NoSQL database service, not a storage service. The question specifically targets storage services, and Cosmos DB's CMK support operates differently—it encrypts all data in the account automatically but lacks per-container control, and the account-level configuration may not satisfy all storage-specific compliance needs. Therefore, Cosmos DB is not the best fit for a storage service answer.

The source address prefix is set to VirtualNetwork, which is incorrect.

Why it fails: The source address prefix setting of VirtualNetwork is actually correct for this scenario. In Azure, the VirtualNetwork service tag represents all address space within the virtual network, including connected peered networks and the subnet where the Azure SQL Database is deployed. When traffic originates from a VM or other resource inside the same VNet and attempts to reach the database, setting the source to VirtualNetwork properly matches that traffic. Therefore, this setting is not the cause of the failure.

The protocol should be UDP instead of TCP.

Why it fails: Changing the protocol from TCP to UDP would break the connection rather than fix it. Azure SQL Database uses the Tabular Data Stream (TDS) protocol, which runs exclusively over TCP, typically on port 1433 for logical servers. UDP is used by protocols like DNS (port 53) or DHCP, not by SQL Server’s client‑server communication. An NSG rule for SQL traffic must specify TCP (or Any) to permit the connection, so UDP is categorically the wrong protocol.

The rule is applied to the wrong direction (outbound instead of inbound).

Why it fails: The rule's direction is set to Inbound, which is correct for traffic arriving at the Azure SQL Database from clients or applications. Outbound rules apply only to traffic leaving the resource, such as a response from the database to a client—and even that response is allowed by the stateful nature of NSGs after the inbound flow is permitted. Since the connection attempt originates externally and targets the database, an inbound rule is required. An outbound rule would not govern this incoming traffic, so the direction setting is not the problem.

The supportsHttpsTrafficOnly property must be set to false.

Why it fails: Setting supportsHttpsTrafficOnly to false does not prevent geo-replication; it only allows HTTP traffic, which is not the cause of the error.

The storage account name is not globally unique.

Why it fails: A non-unique storage account name would cause a deployment failure, not an error when trying to enable GRS after successful deployment.

The storage account uses Standard_LRS, which does not support GRS.

Why it fails: Standard_LRS can be upgraded to GRS after deployment, so this is not the cause of the error. The error is due to the TLS version setting.

Serverless capacity mode

Why it fails: Incorrect: Serverless mode is for intermittent, low-traffic workloads and may not scale quickly enough for sudden spikes.

Manual provisioned throughput

Why it fails: Incorrect: Manual throughput cannot adapt to sudden spikes, leading to throttling.