Describe considerations for working with non-relational data on Azure practice questions

SQL API for both profiles and logs

Why wrong: While the SQL API can store both, it is not optimized for simple key-value lookups with the same performance as the Table API. Using the SQL API for profiles would still work but would be less efficient and more costly for simple reads.

MongoDB API for profiles and Cassandra API for logs

Why wrong: The MongoDB API is document-based and can handle JSON, but it is not as simple as the Table API for key-value. The Cassandra API is column-family and does not natively support SQL-like querying on JSON documents; it is designed for wide-column workloads.

Table API for both profiles and logs

Why wrong: Using the Table API for both profiles and logs would simplify infrastructure but sacrifices query capability. The Table API is optimized for fast point lookups and simple range scans on a fixed partition key/row key schema, not for ad hoc SQL-style queries over nested JSON properties. Session logs typically need filtering by player ID, timestamp ranges, and possibly aggregation of event attributes; the Table API lacks the indexing and query engine to support these operations efficiently. While player profiles are a perfect fit, forcing logs into the Table API would require service-side denormalization and still fail to meet the analytics requirements.

SQL API for profiles and Gremlin API for graph

Why wrong: Azure Cosmos DB's SQL API stores schema-agnostic JSON documents exactly like the user profiles, offering rich querying with SQL syntax and automatic indexing on every property. The Gremlin API models vertices and edges, making it the native choice for traversing friend relationships. These API types can coexist in one account via separate containers, giving you optimized performance for both document lookups and graph walks.

MongoDB API for profiles and SQL API for graph

Why wrong: The MongoDB API can technically persist JSON documents, so the profile half is workable, but it does not take full advantage of Cosmos DB's native SQL JSON query model in this scenario. More critically, the SQL API is a document query engine, not a graph traversal engine; without Gremlin you cannot efficiently execute friend-of-friend traversals. Thus, swapping the graph API for SQL breaks the core relationship querying requirement, making this combination wrong.

Table API for profiles and Gremlin API for graph

Why wrong: The Table API is a key-value/schema-less store intended for simple tabular data, not for complex JSON documents with nested fields and variable attributes. While the Gremlin API half is appropriate for friend connections, the Table API lacks the document querying capabilities and indexing flexibility that SQL API offers for profile JSON, making the combined design mismatched and ultimately incorrect.

SQL API and Gremlin API

Why wrong: Incorrect because an Azure Cosmos DB account cannot be configured with both SQL API and Gremlin API; it is limited to one API per account.

MongoDB API and Table API

Why wrong: Incorrect because it combines MongoDB API and Table API in one account, which is not possible, and Table API is not suitable for graph queries.

Cassandra API and SQL API

Why wrong: Incorrect because Cassandra API and SQL API cannot coexist in one account, and Cassandra API is not optimized for graph traversals.

Use the SQL API only for both workloads.

Why wrong: The SQL API can query JSON documents with SQL-like syntax, but it cannot efficiently traverse graph structures. Therefore, using only the SQL API fails the graph traversal requirement.

Use the MongoDB API only for both workloads.

Why wrong: The MongoDB API can store JSON documents but does not natively support graph traversal. It cannot meet the graph requirement.

Use the Gremlin API only for both workloads.

Why wrong: The Gremlin API is excellent for graph traversal but cannot perform SQL-like queries on JSON documents. It fails the document query requirement.

Table API

Why wrong: The Table API is optimized for simple key-value lookups and does not provide rich query capabilities for filtering on multiple properties.

MongoDB API

Why wrong: While the MongoDB API can handle similar scenarios, it may not offer the same ease for multi-field queries and typically requires explicit index creation for best performance.

Gremlin API

Why wrong: The Gremlin API is designed for graph-based data with vertices and edges, not for general JSON documents or queries on properties like origin and status.

Strong

Why wrong: Strong consistency in Azure Cosmos DB guarantees that a read returns the most recently committed write, but this comes at a cost: it requires a single write region with synchronous replication to all read regions. When multi-region writes are enabled, the database must accept writes in many locations simultaneously, making it impossible to enforce a global total order of writes without sacrificing availability. Therefore, Strong consistency is not available in this configuration, and selecting it would be incorrect.

Bounded staleness

Why wrong: Bounded staleness allows reads to lag behind writes by a defined time interval or number of operations (e.g., 5 seconds or 100 operations), offering a middle ground between strong and eventual consistency. However, this consistency level is only available when using a single write region, because Cosmos DB must maintain a strict, global ordering of writes to enforce a bound on how stale a read can be. With multi-region writes, multiple regions accept writes concurrently, so there is no global causal history to define staleness bounds, making Bounded staleness unsupported in this scenario.

Session

Why wrong: Session consistency is a client-scoped consistency guarantee that uses a session token to ensure that a client can read its own writes, but it is only supported when the account is configured with a single write region. With multi-region writes, session tokens lose their relevance because writes can occur in any region and there is no single ordering authority for a particular client session. Thus, Session is not a valid choice when multi-region writes are enabled; it is a per-client consistency model that simply cannot function in that distributed write scenario.

Hot tier

Why wrong: Hot tier is incorrect because it is designed for frequent read and write operations, providing zero retrieval latency but at the highest storage cost among all Azure Blob access tiers. For data held for a decade with infrequent access, Hot's premium pricing and lack of cost optimization for long-term retention make it impractical. The goal of archiving legal documents is to minimize cost, not to maximize access speed, so Hot is not suitable.

Cool tier

Why wrong: Cool tier is incorrect for 10-year legal archives because it is optimized for data accessed infrequently but still multiple times per month, with retrieval latency in milliseconds. Although cheaper than Hot, Cool incurs higher storage costs than Cold or Archive and carries an early deletion penalty if data is removed before 30 days. Legal documents that will rarely be accessed need a lower-cost tier, so Cool is not the most economical choice.

Cold tier

Why wrong: Cold tier is incorrect for this scenario because it is built for data accessed less than a few times per year, with storage costs cheaper than Cool but still more expensive than Archive. Cold offers retrieval latency in milliseconds, which is overkill for legal documents that may be accessed only once or twice over a 10-year retention period. Archive provides even lower storage cost, making Cold a suboptimal middle-ground choice for true archiving.

Cool tier

Why wrong: The Cool tier is intended for data that is infrequently accessed but not archived, with a lower storage cost but a per-GB retrieval fee charged whenever data is read. Since profile photos are viewed often in the initial month, those retrieval charges would accumulate rapidly, making Cool more expensive than Hot. Additionally, Cool imposes a minimum storage duration of 30 days, so even if access later drops, early deletion would trigger an early-deletion penalty, further undermining cost efficiency.

Archive tier

Why wrong: The Archive tier is built for long-term retention of rarely accessed data, requiring a rehydration process (changing the tier to Hot or Cool) before the data can be read. That rehydration can take up to 15 hours, making profile photos unavailable for immediate viewing, which is unacceptable for user-submitted content expected to be accessible on demand. Although Archive has the lowest storage cost, its latency and operational overhead disqualify it for any dataset with frequent access needs.

Premium tier

Why wrong: The Premium tier, found in Azure Premium Blob Storage, provides extremely low latency and high throughput by leveraging SSD-backed hardware, but at a significantly higher per-GB price than the Hot tier. It is engineered for high-transaction workloads like IoT telemetry or interactive analytics, not for serving static profile photos with a modest access pattern. For this use case, Hot tier already delivers the necessary performance (single-digit millisecond latency) without the unnecessary cost premium.

Timestamp (e.g., per minute)

Why wrong: Using a raw timestamp (e.g., per minute) as the partition key provides excellent write distribution because each minute's data lands on a different partition, preventing any single partition from being a write hotspot. However, the primary query pattern is retrieving all readings for a specific DeviceID over a time range, and because timestamp is the partition key, the query cannot use a single partition key. Instead, it must fan out to every partition that contains a minute in the range, resulting in a cross-partition query that scales with the number of minutes and incurs significantly higher request unit (RU) consumption and latency. Moreover, a single device's data is scattered across many partitions, so even a point read by DeviceID and one minute would require knowing the exact minute and still be limited to that one instant, not the desired 'last hour' aggregate.

Location

Why wrong: Location as a partition key suffers from low cardinality—many IoT devices will share the same location value, so each location partition can grow disproportionately and exceed the 10 GB logical partition size limit, creating a hot partition and causing throttling. Even within a single location, queries for a specific DeviceID would require a partition-level scan of all items in that location, since DeviceID is not part of the partition key. Worse, the common query 'get readings for DeviceID' would not even use location as a filter, forcing a cross-partition query across all location partitions. Combining low cardinality, a poor match to the DeviceID-centric access pattern, and the risk of size-based hot spots makes Location an inferior choice compared to a synthetic key.

A synthetic key combining DeviceID and Timestamp (e.g., DeviceID_yyyy-MM-dd-HH)

Why wrong: This distributes writes across partitions because the suffix changes each hour, preventing a single device from overloading one partition. For the query 'get readings for DeviceID in the last hour', the application can compute the exact partition key(s) for the relevant hour(s) and perform efficient point or limited cross-partition queries.

Hot tier

Why wrong: The Hot tier is optimized for data that is accessed or modified frequently, and it carries the highest storage cost of all online tiers. For historical sales data that is only needed on a monthly basis, paying premium storage rates for every object is wasteful, especially when the data does not require the sub-second latency that Hot provides in practice.

Cold tier

Why wrong: The Cold tier targets data accessed very rarely, on the order of a few times a year, and it enforces a 90-day minimum storage duration with higher per-GB read and data retrieval charges. Using Cold tier for monthly access would incur those higher access costs far more often than intended, making Cool tier a more cost-effective choice for this workload.

Archive tier

Why wrong: The Archive tier is an offline tier with the lowest storage cost, but it requires a rehydration process that can take hours before data is readable. Since the company needs to analyze historical sales data every month, Archive tier's multi-hour retrieval latency is unacceptable, and it is meant for long-term backup and compliance data that is rarely or never accessed.

The application is using the wrong connection string for the region.

Why wrong: Connection strings are region-agnostic for multi-region accounts.

The consistency level is set to eventual, causing write conflicts.

Why wrong: Consistency does not prevent writes.

The account is using read-only replicas in the affected region.

Why wrong: Even though Azure Cosmos DB supports read-only replicas (read regions) when configured with multiple regions, they cannot accept write operations. The issue is that the account has only one write region, and during its outage, writes fail regardless of read replicas.

Azure Blob Storage

Why wrong: Blob Storage is not optimized for frequent small document operations.

Azure SQL Database

Why wrong: Azure SQL Database is relational.

Azure Table Storage

Why wrong: Table Storage is for key-value, not JSON documents.

Configure a lifecycle management policy to tier the file.

Why wrong: Lifecycle management policies in Azure Blob Storage are designed to automate tiering (e.g., Hot to Cool) and deletion based on age or modification time; they operate only on blobs already stored in the account. They cannot assist with transferring or uploading a 500 GB file, because the policy engine never sees the data during the upload process. This option is therefore irrelevant to the upload scenario.

Use Azure File Sync to synchronize the file to the cloud.

Why wrong: Azure File Sync is a service that continuously synchronizes a Windows Server file share with an Azure file share (Azure Files), not with Blob Storage. It is intended for uninterrupted file access across servers, not for uploading a single 500 GB artifact to blob containers. Using File Sync here would require setting up a server-side sync relationship, which adds unnecessary infrastructure and does not address the direct blob upload requirement.

Use AzCopy with the /Z parameter to resume the upload.

Why wrong: AzCopy is a command-line tool that simplifies data transfer and indeed uses block-level logic internally, but the /Z parameter only enables journal-based resume in the AzCopy process, which persists temporarily across commands. The question asks for a feature of Blob Storage itself, not a client utility's convenience flag; the underlying mechanism is still the Put Block/Put Block List API. Additionally, /Z is not available in all AzCopy versions (v10 uses '--resume-prompt'), so it is not the standard 'feature' being assessed here.

Enable Microsoft Purview.

Why wrong: Microsoft Purview is a unified data governance service that catalogs, classifies, and tracks lineage of data assets across on-premises and multi-cloud environments. It does not capture operation-level audit logs for Azure Data Lake Storage, nor does it record individual read, write, or delete requests with user identity and timestamps. While Purview is valuable for compliance discovery and policy management, it cannot provide the historical, per-request audit trail needed to answer who accessed what and when.

Enable Storage Analytics logging.

Why wrong: Storage Analytics logging is the built-in feature of Azure Storage that records detailed information about every successful and failed request, including the authenticated caller, the operation performed (e.g., PutBlob, DeleteFile), the resource path, and the HTTP response code. For Azure Data Lake Storage Gen2, which is built on Blob Storage, this provides the per-request audit log necessary to trace user activity for security, audit, and compliance purposes. Enabling this logging makes the storage account generate a historical record of all operations, fulfilling the company's requirement for tracking data access.

Enable Microsoft Defender for Cloud.

Why wrong: Microsoft Defender for Cloud is a cloud workload protection platform that delivers security posture management, vulnerability assessments, and threat detection alerts. It can flag anomalous activities or potential breaches, but it does not generate a continuous, granular audit log of every request made to the storage account, nor does it retain individual access details such as which user performed a specific read or delete. Its security alerts are synthesized from telemetry and are not a substitute for the comprehensive, request-level record that Storage Analytics logging provides.

Azure Blob Storage

Why wrong: Incorrect. Azure Blob Storage stores blobs (binary large objects) and does not support partition/row key queries.

Azure Files

Why wrong: Incorrect. Azure Files provides SMB file shares, not key-value storage.

Azure Cosmos DB

Why wrong: Incorrect. While Azure Cosmos DB can act as a key-value store, the question's specification of partition and row keys points directly to Azure Table Storage as the simplest fit.

Supports SQL Server integration.

Why wrong: Cosmos DB is not SQL Server.

Requires a fixed schema for all documents.

Why wrong: Cosmos DB is schema-agnostic.

Filter by RowKey eq 'settings'

Why wrong: This requires a full table scan.

Filter by PartitionKey eq 'user123'

Why wrong: This returns all entities in the partition, not just the settings row.

Filter by PartitionKey eq 'user123' or RowKey eq 'settings'

Why wrong: OR conditions are inefficient and may scan multiple partitions.

Increase the provisioned throughput (RU/s)

Why wrong: Increasing the provisioned throughput merely raises the number of request units (RUs) the container can process per second; it does not reduce the cost of an inefficient query. If a query is slow because it is performing a cross-partition scan due to a missing or poorly designed index, raising RU/s will let more expensive operations run concurrently but will not make the query itself faster or cheaper. Over-provisioning also increases cost and can hit per-physical-partition throughput caps, so it is a tuning band-aid rather than a root-cause fix.

Enable analytical store

Why wrong: Enabling the analytical store provisions a columnar, fully managed store for large-scale analytical workloads via Azure Synapse Link, and that store is independent of the transactional row store used by the Core SQL API. Queries issued through the SDK or SQL API read from the transactional store, not the analytical store, so enabling it will have no effect on point-read or filter-query performance. The analytical store is meant for expensive, scan-heavy aggregate queries, not for online transaction processing (OLTP) reads, and it does not alter the indexing behavior of the container's transactional tier.

Change the partition key to the filtered property

Why wrong: Changing the partition key to the filtered property would require you to create a new container with that partition key and migrate all existing data because partition keys are immutable in Cosmos DB. Even ignoring the downtime and complexity, the filtered property may not have good cardinality or even distribution, which could cause hot partitions and worse overall performance. A composite index is the correct, non-disruptive way to accelerate queries that filter on a property that is not the partition key, because you cannot simply repartition an existing container in place.

BlobStorage

Why wrong: BlobStorage does not support hierarchical namespace by default; you need a general-purpose v2 account with hierarchical namespace.

QueueStorage

Why wrong: QueueStorage is for messaging, not for data lake.

FileStorage

Why wrong: FileStorage is for Azure Files, not for data lake.