Design data storage solutions practice questions

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.

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 Cosmos DB

Why wrong: Azure Cosmos DB is a multi-model NoSQL database engineered for globally distributed, low-millisecond transactional access to documents, graphs, and key-value pairs, not for run-of-the-mill analytical workloads. Although it accepts semi-structured documents, its per-request consumption model and throughput provisioning make petabyte-scale append-only IoT analytics expensive and slow, because every record insert consumes RU/s and cross-partition aggregation queries are costly. It also lacks native time-window partitioning and real-time aggregation capabilities, so it would need external pipelines to approximate ADX's behavior.

Azure SQL Database

Why wrong: Azure SQL Database is a relational engine that mandates a fixed schema upfront, which conflicts with the highly variable, semi-structured telemetry produced by diverse IoT devices. It is optimized for OLTP transactions and requires careful index tuning to avoid write amplification; at petabytes of append-only data, this becomes unmanageable and violates the fast ingest pattern of most IoT workloads. Time-series analysis in T-SQL relies on traditional window functions and requires periodic table maintenance, but does not offer the native columnar time-partitioned storage or distributed query engine needed for real-time analysis.

Azure Table Storage

Why wrong: Azure Table Storage is a simple, NoSQL key-value store where every row is a (partition key, row key) pair that supports fast point lookups, but not scanning, complex filters, or aggregation queries. It can scale to store petabytes of structured data, but because it has no secondary indexes or time-series-specific partitioning, running real-time analytic expressions like count, average, or percentile over a feeding IoT dataset would require client-side paging and full scans. Its narrow data model also treats every property as opaque strings/bytes, making it poor for semi-structured telemetry that changes frequently.

Azure Blob Storage

Why wrong: Azure Blob Storage offers a flat namespace in which all files are stored as blobs within containers, lacking a true directory hierarchy. This absence of a hierarchical namespace makes directory-level operations like rename, delete, or move inefficient because they require enumerating and updating individual blobs, and access control is limited to container-level or blob-level ACLs rather than fine-grained directory-scoped permissions. Consequently, while Blob Storage can store data, it does not meet the metadata and security requirements essential for a big data analytics platform.

Azure Files

Why wrong: Azure Files delivers SMB and NFS file shares primarily for lifting and shifting on-premises file servers or sharing files among virtual machines, with a design centered around latency-sensitive, interactive workloads. It does not provide a hierarchical namespace with analytical semantics (like directory rename as a single operation) nor the high-throughput parallel data access patterns required by analytics engines. Using Azure Files for big data pipelines would incur capacity and performance limits, and its protocol overhead makes it ill-suited for petabyte-scale analytical processing.

Azure Cosmos DB

Why wrong: Azure Cosmos DB is a globally distributed, multi-model NoSQL database optimized for transactional, low-latency workloads with predictable performance, not for storing and analyzing huge volumes of raw or semi-structured data for batch analytics. It lacks a hierarchical storage namespace and its access model is read-based via CRUD operations or SQL queries, whereas big data analytics requires in-place, columnar or data lake–style scanning across datasets. Additionally, its cost model charges per request unit, making scanning massive datasets prohibitively expensive compared to a data lake storage purpose-built for analytical queries.

Azure Table Storage

Why wrong: Wrong. Azure Table Storage is a scalable NoSQL key-value store that supports geo-redundant storage (GRS) for read-access geo-redundant storage (RA-GRS), but this only provides read access to a secondary region after a failover; writes are always directed to a single primary region. The service does not support multi-region writes or automatic conflict resolution—there is no active-active capability, so a globally distributed e-commerce application requiring writes from multiple regions would experience a single point of failure for write availability and would need application-level conflict handling, which is not provided.

Azure SQL Database

Why wrong: Wrong. Azure SQL Database offers active geo-replication and failover groups, but these are designed for a single primary write region; readable secondaries in other regions are read-only, and writes must go to the primary. While failover groups allow the secondary to become the new primary during a regional outage, this is a failover operation, not simultaneous multi-region writes, and there is no built-in conflict resolution for concurrent writes to different regions. Thus, it does not meet the requirement for automatic multi-writer support.

Azure Redis Cache

Why wrong: Wrong. Azure Redis Cache is an in-memory data store, not a durable database designed for transactional persistence and multi-region write consistency. It does support geo-replication for cache instances, but the replication is asynchronous and unidirectional from the primary to the read replica(s); writes are not accepted on the replica, and there is no conflict resolution because there are no independent multi-writer regions. It is intended for caching and low-latency data access, not as the authoritative database for a global e-commerce transaction system where durable, conflict-free writes are essential.

Legal hold

Why wrong: Legal hold is an immutable configuration on a container or blob, but it is indefinite — it remains in effect until the service principal explicitly removes the legal hold tag, with no automatic expiration. Because the hold has no fixed end date, it cannot meet a concrete 7-year compliance window and requires ongoing manual oversight to release. For this scenario, the lack of an enforceable time boundary and deterministic expiry makes it unsuitable as the retention mechanism.

Soft delete

Why wrong: Soft delete provides a short recovery window for blobs that were already deleted, allowing restoration during a configurable retention period, but it does not protect against initial deletion or modification in the first place. It also does not create a tamper-proof copy of the data; instead it merely marks the blob as logically deleted while leaving it readable only through special restore APIs. This is a data-availability feature, not a WORM-based regulatory control.

Versioning

Why wrong: Versioning in Azure Storage maintains a complete history of an object's modifications, but it does not lock any version or prevent the current version from being updated or deleted — it only preserves prior states. A malicious or accidental overwrite will create a new version, and versions themselves can be permanently deleted unless an immutable policy or a lifecycle rule is applied. Versioning alone offers recoverability, not immutability, so it fails the requirement to restrict changes.

Azure Files

Why wrong: Azure Files is a managed cloud SMB share, but it lacks the synchronization engine that Azure File Sync provides. Without Azure File Sync, each branch office would either access the cloud share directly over the internet or VPN, which introduces latency and no automatic local cache, or you would have to manually replicate files to each server—there is no built-in multi-site sync or tiering. As a standalone service, Azure Files does not offer the local cache and distributed sync required for the branch office scenario described.

Azure Blob Storage with Azure File Sync

Why wrong: Azure Blob Storage with Azure File Sync is technically invalid because Azure File Sync is designed to work only with Azure Files, not with blob storage. Blob Storage is a REST-based object store and does not expose SMB file semantics, so on-premises Windows file servers cannot sync to it through Azure File Sync. Attempting to use Blob Storage would require a custom gateway or third-party tool, and you would be duplicating the native Azure Files integration rather than simplifying it; thus, this combination is redundant and non-functional as proposed.

Azure NetApp Files

Why wrong: Azure NetApp Files is a high-performance, enterprise-grade file service that supports SMB and NFS protocols, but it is not a sync and caching solution for branch offices. It has no built-in cloud tiering that can push data down to local branch server caches, nor does it provide replication between distributed on-premises Windows file servers. While suitable for HPC, databases, and other latency-sensitive workloads in Azure, it does not address the multi-site file server consolidation and local caching needs outlined in the scenario.

Single Azure SQL Database per tenant

Why wrong: With a single Azure SQL Database per tenant, each tenant's database must be provisioned at its own DTU/vCore tier to handle that tenant's peak demand. Because most tenants rarely sit at peak, you pay for idle reserved capacity across the fleet, leading to substantial waste as tenant count grows and making cost management linear and inefficient compared to pooling.

Azure SQL Managed Instance

Why wrong: Azure SQL Managed Instance provides near-total SQL Server compatibility and instance-scoped features such as SQL Agent, linked servers, and CLR, making it a great choice for lift-and-shift migrations, but not for hosting hundreds of small tenant databases. Each instance has a minimum compute and storage footprint, and you cannot share resources across tenant databases as you would in an elastic pool, so costs remain high for a many-small-database SaaS.

Azure SQL Database Hyperscale

Why wrong: Hyperscale is an architecture designed for single databases that need to grow beyond 4 TB, require rapid scale-out, or expect extremely high transaction log throughput. For a typical multi-tenant SaaS with many small databases, Hyperscale's per-database storage and compute costs are far higher than pooled provisioning, and it does not provide any mechanism to share resources across tenants, making it economically unsuitable for this scenario.

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

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

Set the access tier to Cool on the container

Why wrong: Blob access tier is a property of an individual blob, not the container level; setting a container-wide tier would immediately force every blob to Cool regardless of its age, breaking the requirement that blobs under 30 days stay Hot. It also cannot be configured with a delay or condition based on last-modified time, so it must be applied per blob and does not scale to age-based transitions.

Manually change the access tier every 30 days

Why wrong: Manually changing tiers every 30 days is a non-deterministic, ops-heavy process that requires custom scripts or portal clicks to scan all blobs, compute each blob's last-modified date, and update its tier one by one; any miss or timing mistake leaves blobs in the wrong tier or incurs write operation costs. Because the requirement is continuous and behavior-based, it cannot be reliably satisfied by periodic manual activity, while lifecycle rules provide a fully automated, policy-driven alternative.

Use Azure Policy to enforce tier changes

Why wrong: Azure Policy is a governance layer that enforces compliance by denying, auditing, or modifying resource properties at deployment time (e.g., requiring tags, restricting SKUs), but it cannot asynchronously evaluate the age of data or execute storage service actions like changing a blob's access tier after it has been written. Policies act on the ARM/Azure resource provider control plane, not on blob data plane objects, so they are irrelevant for automatic tier transitions based on last-modified timestamp.

Azure Redis Cache Basic tier

Why wrong: Azure Redis Cache Basic tier runs on a single virtual node and provides no SLA or built-in replication. Because there is no secondary replica, any node failure or patching event makes the cache completely unavailable and causes all session state and cached data to be lost, so it cannot satisfy a high availability requirement. The Basic tier is intended only for development and testing scenarios, not production workloads where downtime or data loss is unacceptable.

Azure Redis Cache Premium tier

Why wrong: Azure Redis Cache Premium tier includes advanced capabilities such as Redis clustering, data persistence to storage, virtual network injection, and zone redundancy, but these features are not necessary for the stated requirement of caching session state and product data with high availability. While Premium also provides a 99.9% SLA, Standard tier already delivers the same replication and SLA at a significantly lower cost. Choosing Premium here would introduce unnecessary operational complexity and expense, so it is not the best answer for the requirement as written.

Azure Content Delivery Network

Why wrong: Azure Content Delivery Network is an edge caching service that replicates static files—such as images, CSS, JavaScript, videos—to globally distributed points of presence, not an application state store. It cannot dynamically read or write session state because it has no execution context for application code, and it does not support Redis commands or arbitrary object caching. Additionally, CDN caching is optimized for long-lived content with explicit cache control, not for frequently changing product data or user sessions that require consistency and immediate invalidation, so it is wrong for this scenario.

Azure SQL Managed Instance

Why wrong: Azure SQL Managed Instance lacks the native resource pooling and multi-tenant scaling model required to optimise cost across varying workloads in separate databases; it provisions a fixed set of resources per instance rather than sharing a pool of resources that each database can draw from elastically. This option is tempting because it offers automated backups with point-in-time restore and geo-replication for disaster recovery, and it would be the correct choice if the company needed near‑full SQL Server compatibility with instance‑level features rather than a pooled, multi‑database architecture.

Azure Database for MySQL

Why wrong: Azure Database for MySQL is fully managed and offers automated backups, point-in-time restore, and geo-redundant backup options, but it lacks the elastic pool abstraction that Azure SQL Database provides. Each MySQL server is provisioned with a fixed compute and storage tier, and all databases on that server contend for the same static resources; scaling requires resizing the entire server or moving to a higher tier, rather than dynamically sharing a pool of capacity. MySQL's own engine does not expose a native multi-database resource pool, so this option cannot meet the stated cost-sharing requirement.

Azure Database for PostgreSQL

Why wrong: Azure Database for PostgreSQL (Flexible Server) is fully managed and includes automatic backups, point-in-time restore, and zone-redundant high availability, but it does not support elastic pools for sharing resources among multiple databases. Compute and storage are allocated at the server level, so you can only scale the whole server or add read replicas; you cannot carve a shared pool and let individual databases draw more capacity on demand. PostgreSQL also uses per-backend memory structures like shared_buffers and work_mem, which cannot be partitioned into a multi-tenant elastic pool at the PaaS layer, making this option unsuitable for the pooling requirement.

Azure Cosmos DB with single-master and multiple read regions

Why wrong: 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 wrong: 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 wrong: Multi-master with eventual consistency alone offers the best write latency and availability, but it cannot guarantee that a device command read will return the most recently written value. In an IoT control scenario, a stale read could cause a device to miss an updated command or act on outdated instructions, so the requirement explicitly demands strong consistency for device command reads. Eventual consistency lacks any bound on replication lag and does not offer read-your-writes guarantees for those critical reads. Therefore, eventual-only fails the stated consistency requirement.

Active geo-replication

Why wrong: Active geo-replication creates a readable secondary replica in a different Azure region, using asynchronous replication. Because the replication is asynchronous, the secondary can lag behind the primary and may lose data during a disaster, so it is not appropriate for synchronous, in-region read-only offload. It also requires manual failover to promote the secondary, unlike Read Scale-Out's automatic promotion.

Auto-failover groups

Why wrong: Auto-failover groups replicate a group of databases to a secondary server in another Azure region and provide both a read-write and a read-only listener endpoint. However, the replication is asynchronous, and the secondary resides in a different region, which introduces network latency and potential data loss. The read-only endpoint is not a synchronous in-region replica and cannot serve as a real-time offload for reporting within the same region. Additionally, failover is at the group level, which can be disruptive for all databases.

Database copy

Why wrong: Database copy is a manual, point-in-time operation that creates a transactionally consistent snapshot of the database as a new, separate database. This copy does not receive subsequent changes from the source, so it cannot provide continuous read-only offload or act as a real-time replica. There is no automatic failover mechanism, and refreshing the copy requires re-copying the entire database, which is inefficient for ongoing reporting workloads.

Azure Files

Why wrong: 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 wrong: 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 wrong: 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 Files with snapshot schedules

Why wrong: Azure Files does support share snapshots for point-in-time recovery, but snapshots capture a read-only copy for backup, not a data-movement mechanism. Although Azure Files has its own hot and cool share tiers, you cannot define Blob Storage-style lifecycle management policies to transition data between those tiers automatically or send it to archive storage. Tiering would require manual changes or separate Azure File Sync rules, so it fails the automated cost-optimization requirement.

Azure Disk Storage with incremental snapshots

Why wrong: Azure Disk Storage is designed for VM operating-system and data disks, where snapshots (including incremental snapshots) capture disk state for backup and disaster recovery, not for file tiering. Incremental snapshots are stored as page blobs and can be used to restore a VM disk, but they do not offer access tiers like archive or lifecycle rules that move data based on policy. They also preserve only the changes since the last snapshot, making them a backup mechanism, not a media-file archival solution.

Azure NetApp Files with snapshot policies

Why wrong: Azure NetApp Files provides high-performance file storage for specialized workloads; its snapshot policies create lightweight, point-in-time read-only copies for rapid recovery. Those snapshots are stored within the same NetApp volume and consume capacity, and NetApp does not offer a built-in automated lifecycle policy to tier snapshots or volume data into Azure Archive. While you can resize capacity pools or set service levels, that only optimizes performance, not the long-term storage cost of raw and processed video files.

Single databases with DTU-based tiers

Why wrong: Deploying each database as a standalone database under the DTU-based purchasing model means every database is billed separately for a fixed service tier, and you must choose a tier large enough to handle its peak usage. Because you cannot share spare capacity across databases, most databases remain under-utilised while you pay for the capacity that rare spikes require, leading to substantial over-provisioning across 100 databases. The DTU model also offers only single-database resource guarantees, so it lacks the statistical multiplexing that would make the overall workload cost-effective. This approach is uneconomical for many small databases with intermittent bursts.

Managed Instance

Why wrong: A managed instance is an isolated SQL Server engine hosted in Azure, and while it can host hundreds of databases, all of them share one fixed allocation of vCores and storage within that instance. There is no elastic pool for the contained databases—each database cannot dynamically borrow from a shared budget, and you must manually manage resource distribution. The instance is designed for lift-and-shift migrations needing near‑100% SQL Server compatibility, not for multi-tenant consolidation with variable loads. Because the entire instance's capacity is provisioned as a unit, you still pay for the whole instance even when many databases are idle, failing to deliver the per‑database elasticity required here.

Hyperscale single database

Why wrong: Hyperscale is a service tier for a single database that separates compute and storage, allowing storage to automatically scale to many terabytes and adding read replicas for extreme throughput. While it excels at very large, high‑IO databases, it is vastly over‑provisioned for 100 small databases, and the per‑database cost is far higher than a pooled model. Hyperscale also uses the vCore purchasing model and does not support sharing resources across multiple databases, so it cannot handle variable loads in a cost‑effective, pooled way. This option addresses a completely different scale of problem and would dramatically inflate costs for this workload.

Azure SQL Database with active geo-replication

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

Use Azure Premium SSD v2 managed disks in a storage pool with mirroring across multiple disks.

Why wrong: While Azure Premium SSD v2 disks offer high performance, attaching them to a single VM (even with a storage pool) does not provide the required 99.99% SLA because a single VM failure would cause downtime. No multiple VMs or availability set is mentioned.

Use Azure Ultra Disk storage attached to the VM.

Why wrong: Azure Ultra Disk provides high performance but is attached to a single VM, so it does not address high availability. Also, it cannot be pooled for capacity aggregation as effectively as Premium SSD v2 with storage pools.

Enable Azure SQL Managed Instance with auto-failover groups.

Why wrong: Azure SQL Managed Instance with auto-failover groups is a PaaS solution that provides high availability across regions, not within a single datacenter. The question specifically requires within the same datacenter, and the workload is on IaaS, so this option is not appropriate.

Azure NetApp Files with SMB volumes.

Why wrong: Azure NetApp Files is a fully managed high-performance file storage service that supports SMB, but it is more expensive and complex than Azure Files for a simple file server migration.

Azure Blob Storage with NFS 3.0 support.

Why wrong: Azure Blob Storage with NFS does not support SMB protocol. The application requires SMB access.

Azure Managed Disk with a file server VM.

Why wrong: This creates an IaaS file server, which is not fully managed. The company wants a fully managed solution to reduce administrative overhead.

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

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