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

SQL API for both profiles and logs

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: The Gremlin API is excellent for graph traversal but cannot perform SQL-like queries on JSON documents. It fails the document query requirement.

A. Table API

Why it fails: The Table API stores key-value entities with partition and row keys, so it cannot run SQL-like queries filtering on nested achievement fields within JSON documents. It is tempting because Table API suits high-throughput lookups by key, which would be correct if only playerId retrieval were required.

B. Cassandra API

Why it fails: The Cassandra API uses the Cassandra Query Language (CQL) and a wide-column store, which cannot natively query nested JSON fields like achievements without flattening the schema. This fails the requirement to run SQL-like queries directly against optional JSON properties. It is tempting because Cassandra offers low-latency lookups by partition key, which would satisfy the playerId requirement, and it would be correct for a high-write, horizontally scalable key-value or wide-column workload without JSON document queries.

C. MongoDB API

Why it fails: The MongoDB API supports JSON documents and queries, but it uses MongoDB's query syntax, not standard SQL. While it can meet the requirement, the SQL API is a more natural fit when the team wants SQL-like queries.

Table API

Why it fails: 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 it fails: 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 it fails: 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.

Use multi-region writes with strong consistency

Why it fails: Incorrect. Strong consistency is not supported when multiple write regions are enabled. Multi-region writes only support eventual consistency.

Use multi-region writes with bounded staleness consistency

Why it fails: Incorrect. Bounded staleness is not available with multi-region writes. Only eventual consistency is supported in that configuration.

Use single-region writes with eventual consistency and implement application-level conflict resolution

Why it fails: Incorrect. Eventual consistency cannot guarantee that all reads see the latest write immediately, which violates the requirement for strong global consistency.

Strong

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Hot

Why it fails: Hot tier is for frequently accessed data and has higher storage cost, which is not needed here.

Archive

Why it fails: Archive tier offers the lowest storage cost but retrieval can take hours, violating the 'within seconds' requirement.

Premium

Why it fails: Premium tier provides low-latency for high transaction volumes but is very expensive and not intended for archival.

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

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

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

Why it fails: Consistency does not prevent writes.

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

Why it fails: 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.

Configure a lifecycle management policy to tier the file.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: Incorrect. Azure Blob Storage stores blobs (binary large objects) and does not support partition/row key queries.

Azure Files

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

Azure Cosmos DB

Why it fails: 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 it fails: Cosmos DB is not SQL Server.

Requires a fixed schema for all documents.

Why it fails: Cosmos DB is schema-agnostic.

Premium

Why it fails: Premium is a performance tier, not an access tier, for Azure Blob Storage. It uses SSD-backed storage to deliver lower-latency and higher-throughput performance for enterprise workloads, and it is billed based on provisioned capacity rather than data access frequency. Because access tiers specifically classify data by how often it is read or written, Premium does not belong to the access-tier set.

Cold

Why it fails: Cold is not a standard access tier for general-purpose Blob Storage accounts in the scope of this exam. The classic set of Blob Storage access tiers consists of Hot, Cool, and Archive, with Cool being the entry point for infrequent access and Archive for long-term offline retention. Choosing Cold is incorrect because it is not one of the valid access-tier options recognized for Blob Storage.

Frozen

Why it fails: Frozen is not an access tier in Azure Blob Storage and does not appear in Microsoft's documented tier list. The name may sound similar to a very low-temperature archive state, but Azure's Archive tier already supplies the lowest-cost offline storage option. Since Frozen does not exist as a defined tier, it cannot be a valid selection.