Design data storage solutions practice questions

Azure Blob Storage with geo-redundant storage (GRS)

Why wrong: Incorrect. GRS provides a secondary region for failover, but data cannot be read from the secondary unless a failover occurs, so it does not support low-latency global reads.

Azure Files with premium shares

Why wrong: Incorrect. Premium Azure Files provide high performance but are cost-prohibitive for large-scale unstructured data and do not natively offer geo-replication for global reads.

Azure NetApp Files

Why wrong: Incorrect. Azure NetApp Files is an enterprise-grade file share service that is expensive and not optimized for cost-effective global read access of unstructured data.

Azure Cosmos DB with SQL API

Why wrong: Incorrect. While Cosmos DB can handle high throughput and time-series data, it is more expensive and often unnecessary for the stated requirement for a startup's cost-sensitive workload; simpler alternatives exist.

Azure SQL Database with columnstore index

Why wrong: Incorrect. Although SQL Database can manage time-series data with columnstore indexes, it is not optimized for extremely high write throughput and can be costly.

Azure Data Lake Storage Gen2

Why wrong: Incorrect. Data Lake Storage Gen2 is optimized for big data analytics and batch processing, not for low-latency, high-throughput time-series writes and range queries.

Azure Data Lake Storage Gen2 for all data.

Why wrong: Data Lake Storage is a great store for historical data but does not provide real-time stream ingestion. You would still need an ingestion service. Additionally, storing every event directly to Data Lake without batching could be inefficient.

Azure Cosmos DB for both real-time and historical data.

Why wrong: Cosmos DB can support real-time queries but at high write throughput it becomes very expensive. Storing billions of raw events in Cosmos DB for long-term is not cost-effective and does not utilize its strengths as a NoSQL document database.

Azure Time Series Insights (TSI) Standard.

Why wrong: TSI is purpose-built for IoT time-series data and can handle high cardinality. However, it is not ideal for storing raw JSON events long-term at massive scale, and the warm/cold store costs may be higher than Data Lake Storage. Also, TSI does not provide the flexibility of using other analytics tools on the data.

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

Why wrong: 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.

Ultra Disk for the database and Azure Files standard tier for the file share.

Why wrong: Ultra Disk can deliver over 100,000 IOPS, but it is significantly more expensive than Premium SSD v2. The standard tier of Azure Files does not meet low-latency requirements due to higher latency and lower throughput.

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

Why wrong: 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).

Azure Table Storage

Why wrong: Azure Table Storage is a NoSQL key-value store but does not support multi-region writes or automatic failover. Latency is higher and scaling is more manual.

Azure SQL Database

Why wrong: Azure SQL Database is a relational database engine, not a NoSQL document store. It does not natively store JSON documents as primary data.

Azure Cache for Redis

Why wrong: Azure Cache for Redis is an in-memory data store primarily used for caching and session state. It is not a durable NoSQL database for global writes with automatic failover.

Azure Cosmos DB

Why wrong: Cosmos DB is a document and NoSQL database optimized for low-latency transactional workloads, not for petabyte-scale append-only time-series analytics.

Azure SQL Database

Why wrong: Azure SQL Database is a relational database that struggles with the scale and append-only nature of massive IoT data and lacks native time-series optimization.

Azure Table Storage

Why wrong: Table Storage is a key-value store for structured data but cannot efficiently handle petabytes of time-series data with real-time aggregation requirements.

Azure Blob Storage

Why wrong: Blob Storage does not have a hierarchical namespace, making it less efficient for directory-level operations and fine-grained access control.

Azure Files

Why wrong: Azure Files is an SMB file share for lifting and shifting on-premises file servers, not designed for big data analytics workloads.

Azure Cosmos DB

Why wrong: Cosmos DB is a NoSQL database for transactional workloads, not a storage layer for analytical processing of large datasets.

A

Why wrong: Azure Blob Storage with a flat namespace does not support hierarchical directory structures or ACLs at the filesystem level, making it less suitable for analytics workloads requiring organization.

C

Why wrong: Azure Files is designed for shared file access using SMB protocol, not for large-scale analytics queries.

D

Why wrong: Azure Disk Storage is block storage for VMs; it cannot be shared across multiple analytics engines and does not support hierarchical namespaces.

A

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

C

Why wrong: 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 wrong: Azure Disk Storage can be attached to a single VM and cannot be mounted by multiple VMs simultaneously for active-active sharing.

Azure Table Storage

Why wrong: Table Storage supports geo-replication but does not offer multi-region writes with automatic conflict resolution; it uses a single primary region for writes.

Azure SQL Database

Why wrong: Azure SQL Database supports active geo-replication for read-scale but not multi-region writes; failover groups require a single write region.

Azure Redis Cache

Why wrong: Redis Cache is an in-memory cache, not a durable, globally write-capable database for transaction persistence.

Hot tier

Why wrong: Hot tier has the highest storage cost and is designed for frequent access, not cost-effective for monthly access.

Cold tier

Why wrong: Cold tier has the lowest storage cost but higher access costs, best for data accessed very rarely (90+ days); for monthly access, Cool is more cost-effective.

Archive tier

Why wrong: Archive tier has the lowest storage cost but requires manual rehydration (taking hours) before data can be read, not suitable for immediate access.

SQL Server on Azure Virtual Machines

Why wrong: SQL Server on VMs requires manual configuration for HA, backups, and patching, increasing administrative overhead.

Azure Database for MySQL

Why wrong: Azure Database for MySQL is fully managed but is a different relational database engine, not SQL Server; the question does not specify engine but for a new mobile app backend, Azure SQL Database is commonly chosen.

Azure Cosmos DB

Why wrong: Cosmos DB is a NoSQL database, not relational, and does not support the relational model required by the scenario.

Use blob lifecycle management policies and legal hold (immutable blobs).

Why wrong: Legal hold prevents deletion but does not enforce a specific retention period and is not designed for automated tiering. Time-based retention is more appropriate for a 7-year fixed period.

Use Azure Storage Analytics and immutability policies.

Why wrong: Storage Analytics provides logs and metrics, not automated tiering or retention. Immutability policies (whether legal hold or time-based) are separate, but this combination does not include lifecycle management.

Use Azure File Sync and lifecycle management.

Why wrong: Azure File Sync is for syncing file shares, not for blob storage. It does not support blob tiering or immutability features.

Azure Table Storage

Why wrong: Azure Table Storage is a NoSQL key-value store but does not support multi-region writes with automatic conflict resolution or serverless capacity. It also may not achieve single-digit millisecond latency at global scale.

Azure Cache for Redis

Why wrong: Azure Cache for Redis is an in-memory cache, not a durable database. It does not provide multi-region writes with conflict resolution or serverless capacity as a primary data store.

Azure SQL Database

Why wrong: Azure SQL Database is a relational database, not a NoSQL key-value/document store. It does not natively support document models or multi-region writes with conflict resolution like Cosmos DB.

Legal hold

Why wrong: Legal hold is indefinite and must be manually removed. It does not provide a fixed time-based retention.

Soft delete

Why wrong: Soft delete helps recover deleted blobs but does not prevent initial deletion or modification.

Versioning

Why wrong: Versioning preserves previous versions but does not prevent the current version from being updated or deleted.

Azure Files

Why wrong: Azure Files provides cloud-based SMB shares but does not include local caching or hierarchical sync.

Azure Blob Storage with Azure File Sync

Why wrong: This is a repetition; Azure File Sync already works with Azure Files, not Blob Storage.

Azure NetApp Files

Why wrong: Azure NetApp Files is a high-performance file service but does not include built-in cloud tiering for branch offices.

Single Azure SQL Database per tenant

Why wrong: Single databases would require over-provisioning for peaks, leading to higher costs for many underutilized databases.

Azure SQL Managed Instance

Why wrong: Managed Instance is intended for lift-and-shift scenarios with instance-level features, not optimal for many small databases.

Azure SQL Database Hyperscale

Why wrong: Hyperscale is for large databases (over 4 TB) with high scalability, not cost-efficient for many small databases.

Enable soft delete and versioning on the storage account, and use a custom script to delete blobs after 7 years. Manually move blobs to Cool and Archive tiers using Azure PowerShell.

Why wrong: Soft delete and versioning do not prevent all modifications and can be bypassed by administrators with proper permissions. Manual tier changes are not automated and may fail sporadically.

Set each blob's access tier to Cool on upload, then manually change to Archive after 30 days. Enable Azure Backup on the storage account for retention.

Why wrong: Manual tier management is not scalable and prone to human error. Azure Backup does not enforce immutability or automatically transition tiers. It only provides recovery points.

Apply a legal hold on the container to prevent deletion, and configure a lifecycle policy to move blobs to Archive after 30 days.

Why wrong: Legal hold does not prevent modifications, only deletion. Also, it must be removed manually after 7 years. The scenario requires both deletion and modification protection for the full period.

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

Why wrong: Azure SQL Database active geo-replication only allows one writable primary; the secondaries are read-only. It does not support multi-region writes or automatic conflict resolution.

Azure Cache for Redis with geo-replication.

Why wrong: Azure Cache for Redis is a caching layer, not a durable primary database. It can be used for low-latency reads but does not provide strong consistency or multi-region writes for persistence.

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

Why wrong: Azure Table Storage does not support multi-region writes; only one region can accept writes. It also lacks automatic conflict resolution and offers only strong consistency within a region.

Set the access tier to Cool on the container

Why wrong: This would move all blobs to Cool immediately, not after 30 days, which does not meet the requirement of keeping blobs hot for the first 30 days.

Manually change the access tier every 30 days

Why wrong: Manual operations are not automated and are prone to errors. Azure provides automated lifecycle management to handle this at scale.

Use Azure Policy to enforce tier changes

Why wrong: Azure Policy is for enforcing compliance rules (e.g., tagging), not for automating data tier transitions based on age.