Courseiva

CCNA Describe considerations for working with non-relational data on Azure Questions

75 of 214 questions · Page 2/3 · Describe considerations for working with non-relational data on Azure · Answers revealed

Practice these questionsDomain overviewAll questions
76
MCQmedium

A social media application stores user profiles as JSON documents. Each user profile can have different attributes (e.g., some have 'education', others have 'work experience'). The application needs to query profiles by any attribute with low latency. Which Azure data store is most appropriate?

A.Azure Blob Storage
B.Azure Table Storage
C.Azure Cosmos DB (SQL API)
D.Azure SQL Database
AnswerC

Cosmos DB SQL API natively supports JSON documents with flexible schemas and provides indexing on all properties for fast queries.

Why this answer

Azure Cosmos DB with the SQL API is the correct choice because it natively supports schema-agnostic JSON documents, allowing each user profile to have varying attributes without requiring a fixed schema. Its indexing policies enable low-latency queries on any attribute, and it provides single-digit millisecond response times for point reads and queries, which is essential for a social media application.

Exam trap

The trap here is that candidates often confuse Azure Table Storage's key-value model with a document database, assuming it can query arbitrary attributes efficiently, but Table Storage requires a composite key and lacks secondary indexes for ad-hoc queries on non-key fields.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is designed for unstructured binary or text data (like images or videos) and does not support querying individual attributes within JSON documents; it would require loading entire blobs and parsing them client-side. Option B is wrong because Azure Table Storage is a key-value store that requires a predefined partition key and row key, and it does not support querying on arbitrary attributes without scanning all entities, leading to higher latency. Option D is wrong because Azure SQL Database is a relational database that requires a fixed schema, so storing user profiles with varying attributes would necessitate complex schema designs (e.g., EAV pattern) or frequent ALTER TABLE operations, which adds overhead and reduces query performance.

Practice this question →
77
MCQmedium

A social media application stores user posts as JSON documents. Each post contains fields like post_id, author, content, and timestamp. The application needs to query posts by author and date range using SQL-like queries. Additionally, the application requires the ability to traverse follower relationships as a graph to suggest new friends. The development team wants to use a single Azure Cosmos DB account to minimize management overhead. Which combination of Azure Cosmos DB APIs should they choose?

A.Use the SQL API only for both workloads.
B.Use the MongoDB API only for both workloads.
C.Use the Gremlin API only for both workloads.
D.Use the SQL API for the posts and the Gremlin API for the follower graph.
AnswerD

Correct. The SQL API handles document queries with SQL, and the Gremlin API handles graph traversals. Both can be used within the same Azure Cosmos DB account.

Why this answer

Option D is correct because Azure Cosmos DB supports multiple API models within a single account, but only one API per account. To handle both SQL-like queries on JSON documents and graph traversal queries, you need separate accounts: one using the SQL API (or MongoDB API) for the document workload and another using the Gremlin API for the graph workload. The question states 'a single Azure Cosmos DB account,' which is a constraint; however, the correct answer acknowledges that you cannot mix APIs in one account, so the only way to meet both requirements is to use two accounts—one for each API.

The answer D correctly pairs the SQL API for posts and the Gremlin API for the follower graph, implying two accounts.

Exam trap

The trap here is that candidates assume a single Azure Cosmos DB account can support multiple APIs simultaneously, but in reality each account is locked to one API at creation time, so you must use separate accounts for document and graph workloads.

How to eliminate wrong answers

Option A is wrong because the SQL API cannot perform graph traversal queries (e.g., follower relationships) natively; it lacks Gremlin's graph traversal capabilities. Option B is wrong because the MongoDB API also lacks native graph traversal support and is not designed for graph workloads. Option C is wrong because the Gremlin API is not optimized for SQL-like queries on JSON documents; it uses Gremlin graph traversal language, not SQL, and does not support document querying with filters like author and date range efficiently.

Practice this question →
78
MCQhard

Refer to the exhibit. You are storing product data in Azure Cosmos DB using the SQL API. The JSON shows a sample document. You need to query for all products in the 'Electronics' category with a price less than 200. Which query should you use?

A.SELECT * FROM c WHERE c.category = 'Electronics' OR c.price < 200
B.SELECT * FROM c WHERE c.category = "Electronics" AND c.price < 200
C.SELECT * FROM p WHERE p.category = 'Electronics' AND p.price < 200
D.SELECT * FROM c WHERE c.category = 'Electronics' AND c.price < 200
AnswerD

This is the correct SQL API syntax.

Why this answer

Option A is correct because the SQL API uses SELECT * FROM c WHERE c.category = 'Electronics' AND c.price < 200. Option B is wrong because using double quotes is invalid. Option C is wrong because the FROM clause is incorrect.

Option D is wrong because the WHERE clause uses OR instead of AND.

Practice this question →
79
MCQeasy

A company uses Azure Table Storage to store customer session data. Each session has a PartitionKey (CustomerId) and RowKey (SessionId). They need to retrieve all sessions for a specific customer quickly. Which query design will be most efficient?

A.Select all entities and filter client-side.
B.Create a secondary index on RowKey.
C.Query with RowKey equal to a specific SessionId.
D.Query with PartitionKey equal to the specific CustomerId.
AnswerD

Table Storage uses PartitionKey for fast partition-level queries.

Why this answer

Using PartitionKey filter (option A) allows Table Storage to directly access the partition, making it efficient. Option B (filter by RowKey) requires scanning all partitions. Option C (selecting all entities) scans the entire table.

Option D (using a secondary index) is not available in standard Table Storage.

Practice this question →
80
MCQmedium

A social media company stores user-generated posts as JSON documents. Each post contains fields such as postId, userId, timestamp, and content. The application needs to query posts by userId and timestamp ranges with low latency, and also perform SQL-like queries across all posts. The data volume is growing rapidly and must scale globally. Which Azure data store should the company use?

A.A) Azure Table Storage
B.B) Azure Cosmos DB SQL API
C.C) Azure Blob Storage
D.D) Azure Cache for Redis
AnswerB

Correct. The Cosmos DB SQL API natively stores JSON documents, supports indexing on any field, and allows rich SQL-like queries. It offers global distribution, low latency, and scalable throughput, making it ideal for this scenario.

Why this answer

Azure Cosmos DB SQL API is the correct choice because it provides native support for querying JSON documents with low-latency, including indexed queries on fields like userId and timestamp. Its global distribution capability ensures data can be replicated across multiple Azure regions for low-latency access worldwide, while its SQL API allows SQL-like queries across all posts, meeting both requirements.

Exam trap

The trap here is that candidates often confuse Azure Table Storage's key-value model with document storage, mistakenly thinking its OData queries can handle complex JSON queries, but Table Storage cannot query nested JSON fields or perform SQL-like operations across all posts.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a key-value store that does not support native JSON document queries or SQL-like querying; it only supports OData-based queries on partition and row keys, not flexible field-level queries on nested JSON. Option C is wrong because Azure Blob Storage is an object store for unstructured binary or text data, not designed for low-latency queries on individual JSON fields or SQL-like querying; it would require loading entire blobs and parsing them client-side. Option D is wrong because Azure Cache for Redis is an in-memory cache, not a durable data store; it lacks persistent storage and SQL-like query capabilities, and is intended for caching frequently accessed data, not for primary storage of growing datasets.

Practice this question →
81
MCQmedium

Refer to the exhibit. You are designing an Azure Table storage schema for user settings. The JSON shows a sample entity. Which query will retrieve all settings for user123 efficiently?

A.Filter by RowKey eq 'settings'
B.Filter by PartitionKey eq 'user123' and RowKey eq 'settings'
C.Filter by PartitionKey eq 'user123'
D.Filter by PartitionKey eq 'user123' or RowKey eq 'settings'
AnswerB

This is a point query, the most efficient.

Why this answer

Option B is correct because using PartitionKey and RowKey together is a point query, which is the most efficient in Table storage. Option A is wrong because filtering only by PartitionKey scans the entire partition. Option C is wrong because filtering by RowKey without PartitionKey performs a full table scan.

Option D is wrong because filtering by both properties with OR is inefficient.

Practice this question →
82
MCQmedium

A social networking application uses Azure Cosmos DB to store user posts. When a user publishes a new post, they immediately refresh their feed and expect to see their own post. However, the application can tolerate temporary staleness for posts from other users (e.g., a few seconds delay). Which Azure Cosmos DB consistency level should the application use for read operations that display the feed?

A.Strong
B.Bounded staleness
C.Session
D.Eventual
AnswerC

Session consistency uses a session token to ensure that within the same client session, reads reflect the writes made by that client. This satisfies the requirement that the user sees their own post immediately, while other reads may see slightly stale data.

Why this answer

Session consistency is the correct choice because it guarantees that the user who writes a post will read their own write within the same session, while allowing other users to see slightly stale data. This matches the requirement: the author immediately sees their new post, but the application can tolerate a few seconds of staleness for other users' posts. Session consistency uses a session token to ensure monotonic reads and writes for the same client, making it ideal for per-user feed scenarios.

Exam trap

The trap here is that candidates confuse 'session' with 'eventual' because both allow staleness, but session guarantees per-user write-read consistency, which eventual does not, and they overlook that bounded staleness applies globally, not per-user.

How to eliminate wrong answers

Option A is wrong because Strong consistency would force all replicas to agree on the latest write before any read, causing high latency and reduced availability, which is unnecessary when only the author needs immediate consistency. Option B is wrong because Bounded staleness allows a configurable lag (time or operations) but applies globally to all reads, not per-user, so it would either be too strict for other users or too loose for the author's own post. Option D is wrong because Eventual consistency provides no guarantee that the author's own post will be immediately visible after a write, which violates the requirement that the author sees their post upon refresh.

Practice this question →
83
MCQmedium

A social media company stores user posts as JSON documents in Azure Cosmos DB. Each post may have a different number of fields and nested objects. Which type of data model does this represent?

A.Key-value
B.Column-family
C.Document
D.Graph
AnswerC

Correct. Document databases like Azure Cosmos DB store each record as a self-contained document (JSON) with a flexible schema, allowing varying fields and nesting.

Why this answer

The scenario describes user posts stored as JSON documents with varying fields and nested objects. Azure Cosmos DB's Document data model (using the SQL API or MongoDB API) is designed for semi-structured, schema-agnostic data where each document can have a different structure, making it the correct choice.

Exam trap

The trap here is that candidates may confuse the document model with key-value because both handle unstructured data, but key-value stores lack the ability to query on nested fields or perform rich queries like those supported by Cosmos DB's SQL API.

How to eliminate wrong answers

Option A is wrong because a key-value data model stores data as simple key-value pairs without support for nested objects or querying on fields within the value. Option B is wrong because a column-family data model organizes data into rows and column families, requiring a predefined schema for columns, not flexible JSON documents. Option D is wrong because a graph data model is optimized for relationships between entities using nodes and edges, not for storing semi-structured documents with varying fields.

Practice this question →
84
MCQmedium

Refer to the exhibit. You are reviewing an Azure Cosmos DB account configuration. Which API is this account configured to use?

A.Table API
B.SQL (Core) API
C.Cassandra API
D.MongoDB API
AnswerC

EnableCassandra indicates Cassandra API.

Why this answer

The 'capabilities' array includes 'EnableCassandra', which indicates the Cassandra API is enabled. Option A is wrong because SQL API would have 'EnableSQL' capability. Option C is wrong because MongoDB would have 'EnableMongo'.

Option D is wrong because Table API would have 'EnableTable'.

Practice this question →
85
MCQeasy

You need to provide temporary access to a specific blob in Azure Blob Storage for a limited time. The access should be time-limited and require no authentication from the user. Which mechanism should you use?

A.Storage account keys
B.Anonymous public access
C.Azure RBAC roles
D.Shared access signatures (SAS)
AnswerD

SAS tokens can be scoped to a specific blob with a defined expiration time, providing secure delegated access.

Why this answer

Shared access signatures (SAS) provide time-limited, delegated access to storage resources without requiring the account key. Storage account keys provide full access and never expire. RBAC is for identity-based access, not anonymous.

Access keys are long-lived secrets.

Practice this question →
86
Multi-Selecteasy

Which TWO storage tiers are available in Azure Blob Storage for general-purpose v2 storage accounts? (Choose two.)

Select 2 answers
A.Cool
B.Frozen
C.Standard
D.Cold
E.Hot
AnswersA, E

Optimized for infrequent access.

Why this answer

Option A (Hot) is correct and Option D (Cool) is correct. Archive is a tier but not listed here; Premium is a separate account type. Option B is wrong because there is no 'Cold' tier.

Option C is wrong because 'Frozen' is not a tier. Option E is wrong because 'Standard' is not a tier name (it's an account type).

Practice this question →
87
MCQeasy

You are designing a solution to store JSON documents from a web application. Each document is about 10 KB and must be queried by a unique ID. Which Azure data store is most appropriate?

A.Azure SQL Database
B.Azure Table Storage
C.Azure Cosmos DB
D.Azure Blob Storage
AnswerC

Cosmos DB is a fully managed NoSQL database with native JSON support, indexing, and fast point reads by ID.

Why this answer

Azure Cosmos DB is a NoSQL database that natively supports JSON documents and provides low-latency queries by ID. Azure Blob Storage stores blobs but is not optimized for querying by document ID. Azure SQL Database is relational and requires schema.

Azure Table Storage is key-value but less feature-rich for JSON documents.

Practice this question →
88
MCQmedium

A global online gaming company needs a data store for player game session logs. Each log record has a SessionID (unique), PlayerID, GameID, StartTime, EndTime, and a JSON payload containing variable game state details. The company requires low-latency writes for millions of concurrent sessions and wants to query by PlayerID and time range. Schema flexibility is important because game state details change frequently. Which Azure data store should they choose?

A.Azure Cosmos DB with the NoSQL API
B.Azure Table Storage
C.Azure Blob Storage
D.Azure SQL Database
AnswerA

Supports flexible JSON schemas, high throughput, low-latency queries, and global distribution.

Why this answer

Azure Cosmos DB with the NoSQL API is the correct choice because it provides low-latency writes (single-digit milliseconds at the 99th percentile) for millions of concurrent sessions, supports schema-flexible JSON documents that can accommodate frequently changing game state payloads, and enables efficient queries by PlayerID and time range using a composite index or a partition key like PlayerID combined with a time-based sort order.

Exam trap

The trap here is that candidates often choose Azure Table Storage because they think it is 'NoSQL' and 'fast,' but they overlook its lack of native JSON support and schema flexibility, which are critical for the variable game state payloads described in the question.

How to eliminate wrong answers

Option B is wrong because Azure Table Storage does not natively support JSON payloads or schema flexibility for variable game state details; it stores data as entities with fixed property sets and requires flattening complex nested data. Option C is wrong because Azure Blob Storage is designed for unstructured binary or text data, not for low-latency, indexed queries by PlayerID and time range; it lacks native query capabilities and would require additional services like Azure Data Lake or external indexing. Option D is wrong because Azure SQL Database enforces a fixed relational schema, which cannot accommodate the frequently changing game state details without costly schema migrations, and its write throughput is limited compared to Cosmos DB's horizontal scaling for millions of concurrent sessions.

Practice this question →
89
MCQhard

You need to upload a 500 GB file to Azure Blob Storage. The network connection is unreliable. Which feature should you use to ensure the upload completes successfully?

A.Configure a lifecycle management policy to tier the file.
B.Use the Put Block and Put Block List operations with a block size that handles retries.
C.Use Azure File Sync to synchronize the file to the cloud.
D.Use AzCopy with the /Z parameter to resume the upload.
AnswerB

Block-level upload allows resuming.

Why this answer

Option B is correct because the Put Block and Put Block List operations allow you to upload a large file as a series of individual blocks. Each block can be retried independently if the network fails, and the final Put Block List assembles the blocks into a single blob. This block-level retry mechanism ensures the upload completes despite an unreliable connection.

Exam trap

The trap here is that candidates often confuse AzCopy's resume capability (which works at the file level) with the block-level retry mechanism of Put Block/Put Block List, assuming any resume feature is sufficient for unreliable networks, but only block-level retries provide fine-grained resilience.

How to eliminate wrong answers

Option A is wrong because lifecycle management policies are used to automatically tier or delete blobs based on age or access patterns, not to handle upload retries or reliability. Option C is wrong because Azure File Sync is designed for continuous synchronization of files between on-premises servers and Azure file shares, not for a one-time upload of a single large file with retry handling. Option D is wrong because AzCopy with the /Z parameter (or --resume in newer versions) supports resuming a failed transfer, but it does not provide the granular block-level retry mechanism that Put Block and Put Block List offer for unreliable networks.

Practice this question →
90
MCQmedium

A media company stores raw video footage as blobs in Azure Blob Storage. After processing, the raw footage is kept for compliance purposes and is accessed only a few times per year. The company wants to minimize storage costs while ensuring the data is durable and can be restored within 24 hours if needed. Which Azure Blob Storage access tier should they use?

A.Hot
B.Cool
C.Cold
D.Archive
AnswerD

The Archive tier offers the lowest storage cost for data that is rarely accessed and can tolerate a retrieval latency of up to 15 hours. This matches the company's requirements of access only a few times per year and a 24-hour recovery window.

Why this answer

The Archive tier is the correct choice because it offers the lowest storage cost for data that is rarely accessed (a few times per year) and can tolerate a retrieval latency of up to 15 hours, which is well within the 24-hour restoration requirement. Azure Blob Storage's Archive tier is designed for long-term retention, compliance, and backup scenarios where durability is maintained through geo-redundant replication options, and data can be rehydrated to an online tier (e.g., Hot or Cool) within the specified time frame.

Exam trap

The trap here is that candidates often confuse the Cold tier (which is a separate tier in Azure, not to be mistaken with Archive) and assume it is the cheapest option, but Archive is actually the lowest-cost tier for data that can tolerate a 24-hour retrieval time, while Cold is still more expensive and has a lower retrieval latency.

How to eliminate wrong answers

Option A is wrong because the Hot tier is optimized for frequent access and has the highest storage cost, making it unsuitable for data accessed only a few times per year. Option B is wrong because the Cool tier is designed for data accessed infrequently (e.g., every 30 days) but still incurs higher storage costs than Archive and has a lower retrieval latency than needed, which is unnecessary for a 24-hour restore window. Option C is wrong because the Cold tier, while cheaper than Cool, is still more expensive than Archive and is intended for data accessed roughly once every 90 days, not for data accessed only a few times per year with a 24-hour retrieval tolerance.

Practice this question →
91
MCQmedium

A startup is building a global user session store. Each session consists of a simple key (session ID) and a value (user data as a JSON string). The application requires low-latency reads and writes from any Azure region, and the data must be durable. Which Azure service is best suited for this scenario?

A.Azure Cosmos DB (Table API)
B.Azure Table Storage
C.Azure Redis Cache
D.Azure Blob Storage
AnswerA

Cosmos DB with Table API provides a globally distributed, low-latency, fully managed key-value store. It supports automatic scaling and multi-region writes, fitting the startup's requirements.

Why this answer

Azure Cosmos DB (Table API) is the best fit because it provides global, multi-region writes with tunable consistency, guaranteed single-digit-millisecond latency for reads and writes at the 99th percentile, and full durability with automatic replication across any number of Azure regions. The Table API offers a key-value store interface (session ID as partition key, JSON value) while also supporting schema flexibility and SLA-backed performance, which is critical for a global user session store.

Exam trap

The trap here is that candidates often confuse Azure Table Storage (a simple, regional key-value store) with Azure Cosmos DB Table API (a globally distributed, low-latency, SLA-backed service), assuming both offer the same global performance and durability, when in fact only Cosmos DB provides multi-region writes and guaranteed latency.

How to eliminate wrong answers

Option B (Azure Table Storage) is wrong because it is a regional service that does not natively support multi-region writes or global distribution with low-latency reads from any region; it also lacks the SLA-guaranteed single-digit-millisecond latency that Cosmos DB provides. Option C (Azure Redis Cache) is wrong because it is an in-memory cache that is not durable by default (data can be lost on node failure unless Redis persistence is enabled, which still sacrifices performance) and does not offer the same durability guarantees as a fully managed database service. Option D (Azure Blob Storage) is wrong because it is designed for large, unstructured binary objects (blobs) and does not provide a low-latency key-value API for simple session lookups; its read/write latency is significantly higher than Cosmos DB or Redis, making it unsuitable for real-time session access.

Practice this question →
92
MCQmedium

A global e-commerce platform uses Azure Cosmos DB to store product inventory data. Customers add items to their cart, which reduces the available inventory count. The application requires that after a customer adds an item, any subsequent read of that product's inventory from any region in the world must reflect the reduced count immediately. Which Cosmos DB consistency level should be used?

A.Eventual consistency
B.Consistent prefix consistency
C.Session consistency
D.Strong consistency
AnswerD

Correct. Strong consistency provides linearizability, ensuring every read sees the most recent write globally.

Why this answer

Strong consistency ensures that any read operation returns the most recent write, regardless of the region. Since the application requires that after a customer adds an item, any subsequent read of that product's inventory from any region must reflect the reduced count immediately, Strong consistency is the only level that guarantees linearizability and zero staleness across all replicas.

Exam trap

The trap here is that candidates often assume Session consistency is sufficient because it provides 'read your writes' within a session, but the question explicitly requires immediate global visibility for any subsequent read from any region, which only Strong consistency can guarantee.

How to eliminate wrong answers

Option A is wrong because Eventual consistency allows reads to return stale data for an unbounded period, which would not guarantee immediate visibility of the reduced inventory count. Option B is wrong because Consistent prefix consistency only guarantees that reads never see out-of-order writes, but it does not guarantee that the read returns the latest write; stale data can still be returned. Option C is wrong because Session consistency guarantees monotonic reads and writes only within the context of a single client session; other clients or regions outside the session could still see stale data.

Practice this question →
93
MCQeasy

A company stores massive amounts of unstructured log data as text files in Azure Blob Storage. The logs are written once and accessed only a few times per month for compliance audits. When accessed, the data must be available within 15 minutes. The company's priority is minimizing storage costs. Which Azure Blob Storage access tier should they use?

A.Hot
B.Cool
C.Archive
D.Premium
AnswerB

Cool tier provides low storage cost for infrequently accessed data with immediate retrieval, meeting the cost and availability requirements.

Why this answer

The Cool access tier is optimal because the logs are accessed infrequently (a few times per month) but require retrieval within 15 minutes. Cool tier offers lower storage costs than Hot while still supporting near-instant access, making it the best balance for minimizing storage costs with occasional compliance audits.

Exam trap

The trap here is that candidates often choose Archive for cost minimization without considering the rehydration latency requirement, mistakenly assuming all infrequently accessed data qualifies for Archive regardless of retrieval time constraints.

How to eliminate wrong answers

Option A is wrong because the Hot tier has higher storage costs, which contradicts the company's priority of minimizing storage costs for data that is rarely accessed. Option C is wrong because the Archive tier has the lowest storage cost but requires rehydration times of up to 15 hours, exceeding the 15-minute availability requirement. Option D is wrong because the Premium tier is designed for high-performance, low-latency access with sub-millisecond latency and higher costs, which is unnecessary and cost-prohibitive for infrequently accessed log data.

Practice this question →
94
MCQeasy

A media company stores large video files in Azure Blob Storage. The videos are accessed frequently for the first 30 days after upload, then rarely for the next 180 days. After that, they are only needed for compliance and are never accessed. Which access tier should be used for the first 30 days to minimize costs while maintaining low latency?

A.Hot tier
B.Cool tier
C.Archive tier
D.Premium tier
AnswerA

Correct. The Hot tier is optimized for frequent read/write access and offers the lowest latency, which is needed for daily active video editing and streaming.

Why this answer

The Hot tier is the correct choice for the first 30 days because it provides the lowest latency access and highest throughput for frequently accessed data, which matches the requirement of frequent access during this period. While the Hot tier has the highest storage cost per GB, it has no retrieval costs, making it cost-effective for high-access patterns. The other tiers introduce either retrieval fees (Cool), high latency (Archive), or unnecessary cost (Premium) for this use case.

Exam trap

The trap here is that candidates often choose the Cool tier thinking it saves money on storage for the first 30 days, but they overlook the retrieval costs and the fact that Hot tier is actually cheaper for frequently accessed data due to zero retrieval fees.

How to eliminate wrong answers

Option B (Cool tier) is wrong because although it has lower storage cost, it incurs a retrieval cost per GB and has slightly higher latency than Hot, making it suboptimal for frequent access during the first 30 days. Option C (Archive tier) is wrong because it has the lowest storage cost but retrieval times can take hours (up to 15 hours for standard priority), which violates the low-latency requirement for frequent access. Option D (Premium tier) is wrong because it is designed for high-performance block blob workloads with consistent low latency and higher cost, but it is overkill and more expensive than Hot for standard video file access.

Practice this question →
95
MCQeasy

A company stores IoT sensor data as JSON files in Azure Blob Storage. A data analyst needs to run ad-hoc SQL queries on these files without moving the data and without provisioning any compute clusters. The analyst wants to pay only for the amount of data processed by each query. Which Azure service should they use?

A.Azure SQL Database
B.Azure Synapse Serverless SQL pool
C.Azure Cosmos DB
D.Azure Data Factory
AnswerB

Correct. Azure Synapse Serverless SQL pool can query JSON files in Blob Storage using T-SQL and charges per data processed.

Why this answer

Azure Synapse Serverless SQL pool allows you to query data directly from Azure Blob Storage using T-SQL without provisioning any compute clusters. It uses a pay-per-query model where you are billed only for the amount of data processed, making it ideal for ad-hoc SQL queries on JSON files stored in Blob Storage without data movement.

Exam trap

The trap here is that candidates often confuse Azure Synapse Serverless SQL pool with Azure SQL Database, assuming any SQL-capable service can query files in Blob Storage, but only the serverless pool provides pay-per-query billing and direct file access without provisioning compute.

How to eliminate wrong answers

Option A is wrong because Azure SQL Database is a provisioned relational database service that requires you to import data into it and pay for reserved compute, not for data processed per query. Option C is wrong because Azure Cosmos DB is a NoSQL database that requires data to be ingested into its containers and does not support ad-hoc SQL queries directly on files in Blob Storage without provisioning throughput. Option D is wrong because Azure Data Factory is an ETL and data integration service, not a SQL query engine; it cannot run ad-hoc SQL queries directly on files without moving or transforming data.

Practice this question →
96
MCQeasy

A healthcare organization stores medical imaging files (DICOM) that are actively used by radiologists for the first 30 days. After 30 days, the files are accessed infrequently for up to 5 years. After 5 years, they must be retained for legal compliance but are accessed very rarely. The organization wants to minimize storage costs. Which strategy should they use to manage the data lifecycle in Azure Blob Storage?

A.Store all files in the Hot tier and use lifecycle management to move to the Archive tier after 5 years.
B.Store files in the Hot tier, move to Cool tier after 30 days, then to Archive tier after 5 years.
C.Store all files in the Archive tier from the beginning to minimize cost.
D.Store all files in the Cool tier to balance cost and access.
AnswerB

This lifecycle management strategy aligns with access patterns: Hot for active use, Cool for infrequent access, Archive for long-term retention, minimizing overall storage cost.

Why this answer

Option B is correct because it aligns the data lifecycle with the access patterns: Hot tier for frequent initial access, Cool tier for infrequent access after 30 days, and Archive tier for long-term compliance after 5 years. Azure Blob Storage lifecycle management policies can automate these transitions, minimizing costs by using the most cost-effective tier for each phase.

Exam trap

The trap here is that candidates often assume the Archive tier is always the cheapest option from day one, ignoring the high retrieval costs and latency for actively used data, or they overlook the need for a graduated tier strategy to match changing access patterns.

How to eliminate wrong answers

Option A is wrong because moving directly to Archive after 5 years leaves files in the Hot tier for the entire 5 years, incurring high storage costs for infrequently accessed data. Option C is wrong because storing all files in the Archive tier from the beginning would cause high retrieval costs and latency for the first 30 days when radiologists need active access, and the Archive tier has a 15-minute to several-hour rehydration time. Option D is wrong because the Cool tier is not cost-optimal for the first 30 days of active use (Hot tier is cheaper for frequent access) and does not provide the lowest cost for the 5+ year retention period (Archive tier is cheaper).

Practice this question →
97
MCQmedium

A social media application stores user profiles in Azure Cosmos DB using the NoSQL API. Each profile includes UserID, Name, Email, and an array of Posts. The most common query retrieves a user's profile by UserID. The application requires strong consistency for writes so that once a profile is updated, all subsequent reads see the latest data. To minimize Request Unit (RU) consumption, which partition key should be chosen?

A.UserID
B.Email
C.Name
D.A synthetic partition key combining UserID and Region
AnswerA

UserID is unique and high cardinality, distributing data evenly. Retrieving by UserID becomes a point read, consuming the fewest RUs.

Why this answer

UserID is the correct partition key because it is the primary filter in the most common query (retrieving a profile by UserID), ensuring each query targets a single logical partition. This minimizes cross-partition queries and RU consumption. Additionally, UserID provides high cardinality and even distribution, which prevents hot partitions and supports the required strong consistency for writes.

Exam trap

The trap here is that candidates often choose a synthetic key or a secondary attribute like Email, thinking they need to avoid hot partitions, but they overlook that the most common query pattern and the need for minimal RU consumption dictate using the primary query filter as the partition key.

How to eliminate wrong answers

Option B (Email) is wrong because while Email is unique, it is not the primary query filter; using it would require an additional index lookup or cross-partition query for the most common operation, increasing RU cost. Option C (Name) is wrong because Name is not unique and has low cardinality, leading to large partitions and potential hot spots, which degrades performance and RU efficiency. Option D (A synthetic partition key combining UserID and Region) is wrong because it adds unnecessary complexity and could cause cross-partition queries if Region is not consistently used in the query filter; it also risks uneven data distribution if Region is skewed.

Practice this question →
98
Multi-Selectmedium

Which TWO of the following are benefits of using Azure Table Storage over Azure Blob Storage for storing semi-structured data?

Select 2 answers
A.Supports querying by partition key and row key
B.Designed for key-value storage and retrieval
C.Provides automatic indexing of all attributes
D.Supports REST API access
E.Offers higher throughput for large files
AnswersA, B

Table Storage is optimized for key-based queries, unlike Blob Storage.

Why this answer

Table Storage supports key-value access and automatic indexing of partition and row keys, making queries by key efficient. Blob Storage is for unstructured data and does not provide built-in key-based querying. Both have REST APIs.

Blob Storage has higher throughput for large files.

Practice this question →
99
MCQhard

A company stores sensitive customer data in Azure Blob Storage. They need to ensure that data at rest is encrypted using a customer-managed key that is stored in Azure Key Vault. Additionally, they want to prevent data from being accessed by unauthorized users even if the storage account key is compromised. Which combination should they use?

A.Enable customer-managed keys and use Azure Defender for Storage
B.Enable customer-managed keys and use Azure Monitor
C.Enable infrastructure encryption and use Azure Backup
D.Enable storage account encryption and use Azure Sentinel
AnswerA

Customer-managed keys encrypt data at rest; Defender for Storage provides threat detection, but to prevent unauthorized access, you should also use Azure AD authentication and RBAC.

Why this answer

Option D is correct because enabling customer-managed keys (CMK) in Azure Key Vault provides encryption at rest with a key the customer controls, and enabling Azure Defender for Storage (now part of Microsoft Defender for Cloud) provides advanced threat protection, but it does not prevent access if the key is compromised. The best practice to prevent unauthorized access is to use Azure AD authentication and RBAC, not just CMK. However, among the options, D is the closest to a valid combination.

Option A is wrong because infrastructure encryption is about double encryption, not access control. Option B is wrong because Azure Backup is irrelevant. Option C is wrong because Azure Sentinel is for security monitoring, not access control.

Practice this question →
100
MCQmedium

A logistics company stores shipment tracking data as JSON documents in Azure Cosmos DB. Each document contains fields like trackingId, origin, destination, status, weight, and optional fields (estimatedDelivery, carrierNotes). The application needs to perform low-latency lookups by trackingId and also run queries to find all shipments that have a specific origin and status. Which Azure Cosmos DB API should they choose?

A.Table API
B.SQL (Core) API
C.MongoDB API
D.Gremlin API
AnswerB

The SQL API supports querying JSON documents with standard SQL syntax, indexes all properties automatically, and allows both point reads and filter queries efficiently.

Why this answer

The SQL (Core) API is the best choice because it provides native support for querying JSON documents with a SQL-like syntax, enabling efficient low-latency lookups by trackingId (using a partition key) and flexible queries on fields like origin and status. It also supports indexing on any JSON property, making queries on optional fields like estimatedDelivery or carrierNotes performant without schema management.

Exam trap

Microsoft often tests the misconception that any JSON document store is equivalent, but the trap here is that the MongoDB API is a wire-protocol-compatible option that candidates might choose because they associate it with JSON, while the SQL API is actually the native, most performant choice for document queries on Azure Cosmos DB.

How to eliminate wrong answers

Option A is wrong because the Table API is designed for key-value storage with a fixed schema and limited query capabilities (only on partition key and row key), not for complex JSON queries on multiple fields like origin and status. Option C is wrong because the MongoDB API, while supporting JSON documents, introduces unnecessary overhead and complexity for a workload that can be handled natively by the SQL API, and it does not offer the same optimized SQL-like querying for the described patterns. Option D is wrong because the Gremlin API is a graph traversal API intended for highly connected data (e.g., social networks, recommendation engines), not for simple document lookups and property-based queries on shipment data.

Practice this question →
101
MCQmedium

A mobile game company stores player profiles and game state in Azure Cosmos DB. Each document contains playerId, level, score, inventory (an array of items), and lastLogin. The application requires fast point reads by playerId, queries to find all players within a specific score range, and global distribution with multi-region writes for low latency worldwide. They also want to use a familiar SQL-like query language. Which Azure Cosmos DB API should they choose?

A.Core (SQL) API
B.MongoDB API
C.Cassandra API
D.Gremlin API
AnswerA

Correct. The Core (SQL) API provides a SQL-like query language, supports point reads and range queries, and enables multi-region writes for global distribution.

Why this answer

The Core (SQL) API is the correct choice because it provides native support for SQL-like queries, enabling the required point reads by playerId and range queries on score. It also offers multi-region writes for global distribution with low latency, which aligns with the application's need for worldwide player access. The document model with arrays (inventory) is directly supported, making it ideal for storing player profiles and game state.

Exam trap

The trap here is that candidates often confuse the MongoDB API's use of a familiar query language (MongoDB's own) with SQL-like syntax, or assume that any NoSQL API can handle range queries equally, but the Core (SQL) API is the only one that provides native SQL-like querying with automatic indexing for such patterns.

How to eliminate wrong answers

Option B (MongoDB API) is wrong because while it supports document storage and queries, it uses MongoDB's query language (based on BSON and MongoDB wire protocol) rather than a familiar SQL-like query language, and the requirement explicitly asks for SQL-like syntax. Option C (Cassandra API) is wrong because it uses CQL (Cassandra Query Language) which is not SQL-like in the traditional sense, and it is optimized for high-throughput writes with partition key-based queries, not for range queries on non-key attributes like score without careful modeling. Option D (Gremlin API) is wrong because it is designed for graph data models and traversals using the Gremlin query language, not for document storage or SQL-like queries, and it does not natively support the required point reads or range queries on player profiles.

Practice this question →
102
MCQmedium

A logistics company tracks shipment locations using GPS devices that send JSON data with fields: shipmentId, latitude, longitude, timestamp, speed. The data is stored in Azure Cosmos DB using the Core (SQL) API. The application needs to query all shipments that are currently within a specific geographic bounding box and have a speed greater than 0. Which query approach should they use to efficiently retrieve the data?

A.Use a BETWEEN clause on latitude and longitude and a WHERE clause for speed.
B.Use ST_WITHIN to specify the bounding box polygon and add a WHERE clause for speed.
C.Use ST_DISTANCE to measure distance from a center point and also filter on speed.
D.Use the IN operator to list all acceptable coordinate pairs and a speed filter.
AnswerB

ST_WITHIN efficiently uses the geospatial index to find points within the specified area, and combining it with a speed filter is the recommended pattern.

Why this answer

Option B is correct because Azure Cosmos DB's Core (SQL) API supports geospatial queries using the ST_WITHIN function, which efficiently checks if a point (latitude/longitude) lies inside a polygon (bounding box). Adding a WHERE clause for speed > 0 further filters the results, and Cosmos DB can leverage a composite index on the geospatial field and speed to optimize query performance.

Exam trap

The trap here is that candidates often assume simple range filters (BETWEEN) are sufficient for geospatial queries, overlooking that Cosmos DB requires dedicated spatial functions (ST_WITHIN, ST_DISTANCE) to utilize its spatial index and achieve efficient bounding box queries.

How to eliminate wrong answers

Option A is wrong because BETWEEN on latitude and longitude does not perform true geospatial bounding box filtering; it would require separate range checks and cannot use Cosmos DB's spatial index, leading to inefficient full scans. Option C is wrong because ST_DISTANCE calculates distance from a center point, which is not suitable for a bounding box query and would require additional logic to define the box, plus it cannot directly filter for points within a rectangular region. Option D is wrong because the IN operator is designed for exact matches on discrete values, not for range or geospatial queries, and listing all acceptable coordinate pairs is impractical and would not use spatial indexing.

Practice this question →
103
MCQmedium

A social media company stores user posts in Azure Cosmos DB. Posts are frequently queried by user ID and creation timestamp. To minimize Request Units (RU) per query, which property should be chosen as the partition key?

A.User ID
B.Timestamp
C.Post content
D.A composite key of user ID and timestamp
AnswerA

User ID is frequently used in queries and can distribute data evenly, making it an ideal partition key.

Why this answer

User ID is the correct partition key because it evenly distributes writes and reads across physical partitions, ensuring that queries filtering by user ID and timestamp are scoped to a single partition. This minimizes cross-partition queries, which consume more Request Units (RU) than single-partition queries. Azure Cosmos DB routes each query to the partition containing the matching partition key value, so choosing User ID keeps most queries efficient.

Exam trap

The trap here is that candidates often choose a composite key (Option D) thinking it improves query efficiency, but they overlook that Azure Cosmos DB requires the partition key to be a single property in the filter for single-partition queries, and a composite key would not be used as a single partition key unless explicitly defined as such in the container.

How to eliminate wrong answers

Option B (Timestamp) is wrong because using timestamp as the partition key would cause hot partitions—all posts created at the same time would land on the same physical partition, leading to throttling and uneven RU consumption. Option C (Post content) is wrong because post content is not a query filter and would result in unpredictable, non-uniform data distribution, causing cross-partition scans for every query. Option D (A composite key of user ID and timestamp) is wrong because while it might seem logical, it would force every query to include both values in the filter to target a single partition; queries filtering only by user ID would become cross-partition, increasing RU cost.

Practice this question →
104
Multi-Selecthard

Which THREE of the following are valid considerations when choosing between Azure Cosmos DB and Azure Table Storage?

Select 3 answers
A.Table Storage supports multi-region writes
B.Cosmos DB provides multiple consistency levels
C.Cosmos DB supports multi-region writes
D.Cosmos DB does not support JSON documents
E.Cosmos DB automatically indexes all properties
AnswersB, C, E

Cosmos DB offers five consistency models.

Why this answer

Options A, B, and C are correct. Cosmos DB offers multi-region writes (A), multiple consistency models (B), and automatic indexing (C). Option D is wrong because both support serverless.

Option E is wrong because both support JSON.

Practice this question →
105
MCQeasy

A retail company wants to store product catalog data in a non-relational format. The data includes product ID, name, description, price, and an array of tags. The data is frequently updated and must support low-latency reads and writes at global scale. Which Azure service should they use?

A.Azure Cosmos DB
B.Azure Table Storage
C.Azure Blob Storage
D.Azure Cache for Redis
AnswerA

Globally distributed NoSQL database with low-latency and JSON support.

Why this answer

Option B is correct because Azure Cosmos DB is a globally distributed NoSQL database that supports low-latency reads/writes and can store JSON documents with arrays. Option A is wrong because Azure Blob Storage is for unstructured blob data, not transactional updates. Option C is wrong because Azure Table Storage is a key-value store but does not support complex queries or global distribution as well as Cosmos DB.

Option D is wrong because Azure Cache for Redis is an in-memory cache, not a durable data store.

Practice this question →
106
MCQmedium

A smart building company stores IoT sensor data in Azure Cosmos DB using the NoSQL API. Each document contains fields: deviceId (partition key), timestamp, temperature, and humidity. The most common query is to retrieve all readings for a specific device within a time range, which runs efficiently. However, the analytics team occasionally runs a query to find all devices that reported a temperature above 50 degrees Celsius in the last hour, without specifying deviceId. This query is very slow and consumes a high number of request units (RUs). What is the most likely reason for the slow performance and high RU consumption?

A.The query does not use the partition key, causing a cross-partition scan.
B.The query is not using an index on the temperature field.
C.The time range filter is too large, causing a full table scan.
D.The document size is too large, increasing RU per read.
AnswerA

When a query does not include the partition key, Cosmos DB must execute the query across all partitions, which increases latency and RU consumption. This is the most likely cause.

Why this answer

The query does not include the partition key (deviceId) in the filter, so Azure Cosmos DB cannot route it to a single physical partition. Instead, it must fan out the query to every partition, scanning all documents across the container. This cross-partition query consumes significantly more RUs and takes longer because each partition must be queried sequentially or in parallel, and the results are merged server-side.

Exam trap

The trap here is that candidates may assume indexing is the culprit (Option B) because they think a missing index causes slow queries, but Azure Cosmos DB indexes all fields automatically, so the real issue is the missing partition key forcing a cross-partition scan.

How to eliminate wrong answers

Option B is wrong because Azure Cosmos DB automatically indexes all fields by default (unless the indexing policy is explicitly overridden), so the temperature field is already indexed; the slowness is not due to a missing index. Option C is wrong because the time range filter is only one hour, which is a narrow window; the performance issue is caused by the lack of partition key, not the size of the time range. Option D is wrong because document size affects RU cost per read, but the primary reason for the high RU consumption and slowness is the cross-partition scan, not the size of individual documents.

Practice this question →
107
MCQeasy

Your team needs to store JSON documents that require schema flexibility and global distribution. Which Azure data store should you choose?

A.Azure Table Storage
B.Azure SQL Database
C.Azure Blob Storage
D.Azure Cosmos DB
AnswerD

Azure Cosmos DB supports flexible schema and global distribution.

Why this answer

Option B is correct because Azure Cosmos DB is a globally distributed NoSQL database that natively supports JSON documents with flexible schema. Option A is wrong because Azure SQL Database is relational and enforces schema. Option C is wrong because Blob Storage stores unstructured data but does not provide a query interface for JSON documents.

Option D is wrong because Table Storage is for key-value data, not document storage.

Practice this question →
108
MCQeasy

A company stores user profile images in Azure Blob Storage. Each image is accessed via a URL that includes a Shared Access Signature (SAS) token generated using the storage account key. The company needs to immediately revoke access to all images for a specific user. Which action should they take?

A.Delete the individual SAS tokens associated with that user's images.
B.Change the storage account access keys.
C.Delete the container containing the user's images.
D.Regenerate the SAS token for each image.
AnswerB

All SAS tokens that were generated using the account key are invalidated when the key is changed or regenerated, instantly revoking access.

Why this answer

Option B is correct because changing the storage account access keys invalidates all SAS tokens that were generated using those keys, including any existing tokens. This immediately revokes access to all images for all users, including the specific user, without needing to manage individual tokens. SAS tokens are signed with the account key, so rotating the key renders all tokens generated with the old key invalid.

Exam trap

The trap here is that candidates think SAS tokens can be individually deleted or regenerated, but Azure does not maintain a token registry; the only way to invalidate all tokens derived from an account key is to rotate the key itself.

How to eliminate wrong answers

Option A is wrong because SAS tokens are not stored or managed individually by Azure; they are generated on-the-fly and embedded in URLs, so there is no central list of tokens to delete. Option C is wrong because deleting the entire container would remove all images for all users, which is excessive and not targeted to a specific user. Option D is wrong because regenerating the SAS token for each image would require knowing each token and would not revoke access to existing tokens that are already distributed; it also does not scale for immediate revocation.

Practice this question →
109
MCQmedium

Your application uses Azure Table storage to store user preferences. You need to retrieve all preferences for a specific user quickly. Which key should you use as the partition key?

A.Region
B.Random GUID
C.UserID
D.Timestamp
AnswerC

UserID groups all preferences for a user in one partition.

Why this answer

Option A is correct because using UserID as partition key ensures all data for a user is stored in one partition, enabling fast point queries. Option B is wrong because Timestamp as partition key would scatter user data. Option C is wrong because Region may not group user data.

Option D is wrong because random GUID would scatter data.

Practice this question →
110
MCQeasy

A manufacturing company stores IoT sensor data as blobs in Azure Blob Storage. Each blob is named with a device ID and a timestamp, and they need to quickly find all blobs for a specific device within a date range. Which Azure Blob Storage feature should they use to query blobs based on custom metadata?

A.Blob snapshots
B.Blob soft delete
C.Blob index tags
D.Blob lifecycle management
AnswerC

Blob index tags let you apply custom key-value pairs as metadata and then filter and query blobs based on those tags, enabling efficient retrieval of blobs by device ID and timestamp.

Why this answer

Blob index tags allow you to apply custom key-value metadata to blobs and then query them using a filtered query across containers or storage accounts. This enables efficient retrieval of blobs by device ID and timestamp without scanning all blob names or maintaining a separate index.

Exam trap

The trap here is that candidates confuse blob index tags with blob naming conventions or metadata stored in a separate database, thinking that blob name patterns alone are sufficient for efficient querying, but Azure Blob Storage does not natively support server-side filtering by name patterns.

How to eliminate wrong answers

Option A is wrong because blob snapshots are point-in-time read-only copies of a blob used for versioning or backup, not for querying blobs by metadata. Option B is wrong because blob soft delete protects against accidental deletion by retaining deleted blobs for a retention period, but it does not provide a query mechanism for custom metadata. Option D is wrong because blob lifecycle management automates tier transitions or deletion based on age or last modification time, not for querying blobs by custom metadata.

Practice this question →
111
MCQmedium

A gaming company stores player profiles as JSON documents. Each profile can have different attributes; for example, some profiles include an 'achievements' field while others include a 'purchaseHistory' field. The application must retrieve profiles by player ID with single-digit-millisecond latency and also support SQL-like queries on any attribute. Which Azure data store should the company use?

A.A. Azure Table Storage
B.B. Azure Cosmos DB Core (SQL) API
C.C. Azure Blob Storage
D.D. Azure Database for PostgreSQL
AnswerB

Azure Cosmos DB with the Core (SQL) API natively stores JSON documents with varying schemas, provides low-latency point reads, and supports advanced SQL-like queries on any attribute.

Why this answer

Azure Cosmos DB Core (SQL) API is the correct choice because it natively stores JSON documents with flexible schemas, supports indexing on any attribute for SQL-like queries, and guarantees single-digit-millisecond latency for point reads by player ID. This meets the requirement for both fast key-based lookups and ad-hoc querying across varying profile attributes.

Exam trap

The trap here is that candidates may confuse Azure Table Storage's key-value capabilities with the need for flexible schema and SQL-like queries, overlooking that Table Storage does not support querying arbitrary attributes or guarantee single-digit-millisecond latency for such queries.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a key-value store that does not support SQL-like queries on arbitrary attributes; it only supports queries on partition key and row key, and its latency is not guaranteed to be single-digit-milliseconds for all operations. Option C is wrong because Azure Blob Storage is designed for unstructured binary or text data, not for querying individual JSON attributes with SQL-like syntax, and it lacks native indexing for ad-hoc queries. Option D is wrong because Azure Database for PostgreSQL is a relational database that requires a fixed schema, making it unsuitable for storing JSON documents with varying attributes without complex schema management and potential performance overhead.

Practice this question →
112
MCQmedium

A gaming company stores player scores in Azure Cosmos DB using the NoSQL API. Each document contains: PlayerID (unique to player), GameID, Score, Timestamp. The most common query is: 'Retrieve all scores for a specific GameID, ordered by Score descending.' Which property should be chosen as the partition key to minimize Request Unit (RU) consumption?

A.PlayerID
B.GameID
C.Score
D.Timestamp
AnswerB

Correct. GameID groups all scores for a game together, so the query targets a single partition, minimizing RU.

Why this answer

GameID is the correct partition key because the most common query filters on GameID, and Cosmos DB routes each query to the physical partition(s) containing that GameID's data. Using GameID ensures the query touches only the relevant partition(s), minimizing RU consumption by avoiding cross-partition fan-out. A partition key that matches the filter predicate is essential for efficient, single-partition queries.

Exam trap

The trap here is that candidates often pick PlayerID because it's unique and seems like a natural key, but they fail to realize that a partition key must align with the most common query filter to avoid costly cross-partition queries, not just be unique.

How to eliminate wrong answers

Option A is wrong because PlayerID is unique per player, causing each query for a GameID to scatter across all partitions (since scores for the same GameID would be distributed across many PlayerID partitions), resulting in a cross-partition query that consumes more RUs. Option C is wrong because Score is a high-cardinality, frequently updated value that would cause hot partitions and inefficient queries, as filtering on GameID would still require scanning all partitions. Option D is wrong because Timestamp is monotonically increasing, leading to hot partitions on the latest timestamp and requiring cross-partition queries when filtering by GameID, which increases RU cost.

Practice this question →
113
MCQhard

Refer to the exhibit. You are reviewing an ARM template snippet for an Azure storage account. You need to ensure that the storage account supports POSIX-like permissions for data lake workloads. Which property must be enabled?

A."allowBlobPublicAccess": false
B."hierarchicalNamespace": {"enabled": true}
C."kind": "DataLakeStorageGen2"
D."keySource": "Microsoft.Storage"
AnswerB

Enabling hierarchical namespace is required for Data Lake Storage Gen2 and POSIX ACLs.

Why this answer

The exhibit shows that hierarchicalNamespace is enabled. This is required for Data Lake Storage Gen2, which supports POSIX ACLs. The question asks which property must be enabled; the answer is the hierarchical namespace.

Option A is wrong because encryption key source is separate. Option C is wrong because data lake storage gen2 is not a property but the result. Option D is wrong because blob public access is unrelated.

Practice this question →
114
MCQhard

A company uses Azure Data Lake Storage Gen2 to store analytics data. The security team requires that all data access be audited, including read, write, and delete operations. Which feature should you enable?

A.Enable Microsoft Purview.
B.Enable Azure Monitor for the storage account.
C.Enable Storage Analytics logging.
D.Enable Microsoft Defender for Cloud.
AnswerC

Storage Analytics logs track all operations.

Why this answer

Storage Analytics logging captures detailed information about successful and failed requests to a storage account, including read, write, and delete operations. This log data can be used for auditing and analysis, meeting the security team's requirement to audit all data access. The logs are stored in a $logs container within the same storage account.

Exam trap

The trap here is that candidates may confuse Azure Monitor (which provides metrics and alerts) with Storage Analytics logging (which provides detailed request-level logs), or think that Microsoft Purview or Defender for Cloud can fulfill the auditing requirement when they serve different purposes.

How to eliminate wrong answers

Option A is wrong because Microsoft Purview is a data governance and catalog service, not an auditing tool for storage access logs. Option B is wrong because Azure Monitor provides metrics and alerts for storage accounts but does not log individual read, write, and delete operations at the request level. Option D is wrong because Microsoft Defender for Cloud is a security posture management and threat protection service, not a feature for auditing granular data access operations.

Practice this question →
115
MCQeasy

A social media application stores user posts as JSON documents in Azure Cosmos DB. Each post includes fields such as postId, userId, content, timestamp, and an array of tags. The development team wants to query posts by userId and timestamp range using a SQL-like syntax. Which Azure Cosmos DB API should they choose?

A.A. Azure Cosmos DB for MongoDB API
B.B. Azure Cosmos DB for NoSQL API (Core SQL API)
C.C. Azure Cosmos DB for Table API
D.D. Azure Cosmos DB for Apache Cassandra API
AnswerB

The NoSQL API natively supports JSON documents and provides a SQL-like query language (SELECT ... WHERE ...). It can efficiently query on userId and timestamp fields, making it the optimal choice.

Why this answer

The Azure Cosmos DB for NoSQL API (Core SQL API) is the correct choice because it natively supports SQL-like querying (SELECT, WHERE, ORDER BY) over JSON documents. The team's requirement to query posts by userId and timestamp range using SQL-like syntax is directly supported by this API, which treats each JSON document as an item and allows filtering on nested fields like userId and timestamp. Other APIs either lack native SQL-like syntax or are optimized for different data models (e.g., MongoDB uses a JSON-like query language, Table API uses OData, Cassandra uses CQL).

Exam trap

The trap here is that candidates confuse 'SQL-like syntax' with any API that supports querying, but only the Core SQL API provides native SQL SELECT statements over JSON documents, while other APIs use different query languages (e.g., MongoDB's query operators, Cassandra's CQL) that are not SQL-like in the standard sense.

How to eliminate wrong answers

Option A is wrong because the Azure Cosmos DB for MongoDB API uses MongoDB's query language (e.g., db.posts.find({userId: ..., timestamp: ...})) rather than SQL-like syntax; it does not support SQL SELECT statements. Option C is wrong because the Azure Cosmos DB for Table API is designed for key-value and wide-column data with OData-based queries, not for querying nested JSON fields like userId and timestamp with SQL syntax. Option D is wrong because the Azure Cosmos DB for Apache Cassandra API uses CQL (Cassandra Query Language), which is similar to SQL but has limitations (e.g., no range queries on non-primary key columns without an index) and is not standard SQL; it is optimized for wide-column stores, not JSON documents.

Practice this question →
116
MCQmedium

A global social media app uses Azure Cosmos DB (NoSQL API) to store user profile data. The app is read-heavy and requires the fastest possible read performance worldwide. The data is updated by users and eventual consistency is acceptable because immediate consistency is not critical for profile views. Which consistency level should they choose to minimize read latency?

A.Strong
B.Bounded staleness
C.Session
D.Eventual
AnswerD

Eventual consistency provides the weakest guarantee but the lowest read latency. Reads are served from any replica without waiting for write propagation, making it ideal for read-heavy workloads where immediate consistency is not required.

Why this answer

Eventual consistency offers the lowest read latency because it allows reads from any replica without waiting for confirmation that the data is the most recent version. Since the app is read-heavy and eventual consistency is acceptable, this consistency level minimizes latency by not requiring any synchronization or staleness bounds.

Exam trap

The trap here is that candidates often assume Strong or Bounded staleness are required for any data that is updated, but the question explicitly states eventual consistency is acceptable, making Eventual the optimal choice for minimizing read latency.

How to eliminate wrong answers

Option A is wrong because Strong consistency requires reads to return the most recent write, which forces synchronization across replicas and increases latency, especially globally. Option B is wrong because Bounded staleness, while more relaxed than Strong, still imposes a maximum staleness bound (time or operations) that requires coordination, adding latency compared to Eventual. Option C is wrong because Session consistency guarantees monotonic reads and writes within a single client session, which introduces overhead to maintain session context and does not provide the lowest possible read latency.

Practice this question →
117
MCQmedium

A global e-commerce company needs to store user session data (key-value pairs) for a web application hosted in multiple Azure regions. The data must support low-latency reads and writes (under 10 ms) and be automatically replicated across regions for high availability. The development team also requires the ability to query sessions by user ID using a simple key lookup and occasionally filter by secondary attributes such as timestamp. Which Azure data store should they choose?

A.Azure Cosmos DB
B.Azure Table Storage
C.Azure SQL Database
D.Azure Cache for Redis
AnswerA

Cosmos DB provides global distribution, low latency, automatic indexing, and multiple consistency models, making it ideal for globally distributed key-value workloads that need secondary query support.

Why this answer

Azure Cosmos DB is correct because it provides globally distributed, multi-region writes with automatic replication, guaranteeing low-latency reads and writes under 10 ms at the 99th percentile. Its key-value API (Table API or SQL API) supports simple key lookups by user ID and secondary indexing on attributes like timestamp, meeting all stated requirements.

Exam trap

The trap here is that candidates often confuse Azure Cache for Redis as a durable data store for session data, overlooking that it is primarily a caching layer and lacks the built-in multi-region replication and durability guarantees required for high availability in a global e-commerce scenario.

How to eliminate wrong answers

Option B (Azure Table Storage) is wrong because it does not support automatic multi-region replication for high availability; it is a single-region service with optional read-access geo-redundant storage (RA-GRS) that only provides read replicas, not active multi-region writes. Option C (Azure SQL Database) is wrong because it is a relational database that introduces overhead for simple key-value lookups and does not natively support multi-region writes with sub-10 ms latency without complex configuration. Option D (Azure Cache for Redis) is wrong because it is an in-memory cache, not a durable data store; data is lost on failure unless persistence is configured, and it lacks native multi-region replication for active-active writes.

Practice this question →
118
MCQmedium

A company stores backup files in Azure Blob Storage. The backup files are accessed frequently for the first 30 days, then only rarely for the next six months. After one year, the files must be retained for compliance but are never accessed. The company wants to minimize storage costs. Which solution should they use?

A.Manually move files between storage accounts
B.Use Azure Blob Storage lifecycle management policies
C.Use Azure File Sync
D.Use Azure NetApp Files
AnswerB

Lifecycle management policies can automatically move blobs to cooler tiers (Cool, Archive) based on age, optimizing cost.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automatically transition blobs to cooler tiers (e.g., from Hot to Cool after 30 days, then to Archive after one year) and delete blobs after a specified period, all without manual intervention. This directly matches the access pattern: frequent access for 30 days, rare access for six months, and never accessed after one year, minimizing storage costs by using the most cost-effective tier for each phase.

Exam trap

The trap here is that candidates may confuse Azure File Sync or Azure NetApp Files as viable storage options for backups, but these services are designed for active file sharing and high-performance workloads, not for cost-optimized, tiered archival of rarely accessed blob data.

How to eliminate wrong answers

Option A is wrong because manually moving files between storage accounts is labor-intensive, error-prone, and does not leverage Azure's built-in tiering or automation, leading to higher operational costs and potential compliance gaps. Option C is wrong because Azure File Sync is designed for synchronizing on-premises file servers with Azure file shares, not for managing blob lifecycle or tier transitions; it does not support blob storage tiers or automated deletion based on age. Option D is wrong because Azure NetApp Files is a high-performance, enterprise-grade NFS/SMB file share service for demanding workloads, not a cost-optimized solution for infrequently accessed backup blobs; it is significantly more expensive than blob storage tiers and lacks lifecycle management for archival.

Practice this question →
119
MCQmedium

You are designing a data storage solution for a social media application that stores user profile pictures and uploaded photos. The solution must support high throughput and be optimized for reading and writing large binary objects. Which Azure data service should you recommend?

A.Azure Files
B.Azure Blob Storage
C.Azure SQL Database
D.Azure Cosmos DB
AnswerB

Azure Blob Storage is designed for storing large amounts of unstructured data, such as images, and offers high throughput.

Why this answer

Azure Blob Storage is optimized for storing large amounts of unstructured data, such as images and videos, and provides high throughput for read/write operations. Option A is wrong because Azure Cosmos DB is a NoSQL database for structured data, not optimized for large binary objects. Option B is wrong because Azure Files is a fully managed file share for SMB/NFS, not ideal for high-throughput binary object storage.

Option D is wrong because Azure SQL Database is a relational database for structured data.

Practice this question →
120
MCQmedium

A company stores sensor data in Azure Blob Storage. The data is appended every minute and rarely modified. The compliance team requires that blobs older than 90 days be moved to a more cost-effective storage tier, and blobs older than 365 days be deleted. Which solution should you recommend?

A.Use Azure Backup to set a retention policy for the storage account.
B.Configure a Blob Storage lifecycle management policy.
C.Enable Blob Soft Delete and set retention days to 365.
D.Move the blobs to Azure Files and set a file retention policy.
AnswerB

Lifecycle policies automate tiering and deletion.

Why this answer

A lifecycle management policy can automatically transition blobs to cooler tiers (e.g., Cool after 90 days) and delete them after 365 days. Option B is wrong because Azure Files is for file shares. Option C is wrong because Blob Storage does not have a built-in backup retention policy for this scenario.

Option D is wrong because Soft Delete is for recovery, not automated tiering or deletion.

Practice this question →
121
MCQeasy

A company stores terabytes of customer support chat transcripts in JSON format. The data is rarely modified and needs to be accessed by analysts using SQL queries. The analysts do not want to manage servers or provision throughput. Which Azure service should be used to store and query this data?

A.Azure Blob Storage (with Azure Data Lake Storage Gen2) and query using Azure Synapse Serverless SQL
B.Azure Cosmos DB
C.Azure Table Storage
D.Azure SQL Database
AnswerA

Correct. This combination provides cost-effective storage and serverless SQL querying without infrastructure management.

Why this answer

Azure Blob Storage with Azure Data Lake Storage Gen2 provides a cost-effective, scalable solution for storing large volumes of JSON data in its native format. By using Azure Synapse Serverless SQL, analysts can query this data directly with standard T-SQL without provisioning any infrastructure or managing throughput, meeting the requirement for serverless, on-demand querying of rarely modified data.

Exam trap

The trap here is that candidates often confuse Azure Cosmos DB's SQL API with traditional SQL querying, overlooking the requirement to avoid provisioning throughput, or they assume Azure Table Storage supports SQL queries when it only supports key-value lookups via REST or OData.

How to eliminate wrong answers

Option B is wrong because Azure Cosmos DB is a NoSQL database designed for globally distributed, low-latency access and requires provisioning throughput (RU/s), which contradicts the requirement to avoid managing throughput. Option C is wrong because Azure Table Storage is a key-value store that does not support SQL queries natively; it uses OData or REST APIs, not SQL. Option D is wrong because Azure SQL Database is a relational database that requires provisioning a server and managing throughput (DTUs or vCores), which violates the requirement to not manage servers or provision throughput.

Practice this question →
122
MCQmedium

A gaming application stores player profiles as JSON documents. Each profile has standard fields like playerId, username, and email, but also optional fields such as achievements and gamePreferences. The application needs to query profiles by playerId with low latency and also run SQL-like queries to find players with specific achievements. Which Azure Cosmos DB API should they choose?

A.A: Table API
B.B: MongoDB API
C.C: SQL (Core) API
D.D: Cassandra API
AnswerC

The SQL API provides native support for JSON documents, low-latency point reads by partition key (playerId), and the ability to run SQL-like queries on document fields such as achievements.

Why this answer

The SQL (Core) API is the best choice because it natively supports JSON documents with flexible schemas (including optional fields like achievements and gamePreferences), provides low-latency point reads by playerId using the id field as the partition key, and enables SQL-like queries (e.g., SELECT * FROM c WHERE ARRAY_CONTAINS(c.achievements, 'specific_achievement')) without requiring a separate indexing or translation layer.

Exam trap

The trap here is that candidates often confuse the MongoDB API's JSON document support with SQL-like query capability, but the question specifically requires SQL-like queries, which only the SQL (Core) API provides natively.

How to eliminate wrong answers

Option A is wrong because the Table API is designed for key-value storage with a fixed schema (entities with properties), not for querying nested JSON arrays like achievements, and it lacks native SQL-like query support for complex JSON structures. Option B is wrong because the MongoDB API uses MongoDB's query language (e.g., db.collection.find({achievements: 'specific_achievement'})) rather than SQL-like syntax, and the question explicitly requires SQL-like queries. Option D is wrong because the Cassandra API uses CQL (Cassandra Query Language) which is not SQL-like in the relational sense, and it is optimized for wide-column storage with a flat schema, not for querying nested JSON documents or optional fields.

Practice this question →
123
MCQmedium

You are designing a solution to store IoT device telemetry data. Each message is a small JSON payload (1-2 KB). The data is written once and read frequently for real-time dashboards. Which Azure data store should you use?

A.Azure SQL Database
B.Azure Cosmos DB
C.Azure Blob Storage
D.Azure Table Storage
AnswerB

Cosmos DB offers low-latency reads for JSON.

Why this answer

Azure Cosmos DB is the correct choice because it is a globally distributed, multi-model database service that offers single-digit millisecond read and write latencies at any scale, making it ideal for real-time dashboards consuming IoT telemetry. Its support for JSON documents natively aligns with the small JSON payloads, and its ability to handle high-throughput writes (once) and low-latency reads (frequently) without schema management fits the workload perfectly.

Exam trap

The trap here is that candidates often choose Azure Blob Storage because they associate 'JSON payloads' with 'files,' overlooking that Blob Storage lacks the low-latency query and indexing capabilities required for real-time dashboards, while Cosmos DB is purpose-built for such operational workloads.

How to eliminate wrong answers

Option A is wrong because Azure SQL Database is a relational database that requires a fixed schema and is optimized for complex queries and transactions, not for the high-velocity, schema-less JSON ingestion typical of IoT telemetry. Option C is wrong because Azure Blob Storage is designed for storing large, unstructured binary objects (e.g., images, videos, backups) and does not provide the sub-second query latency or indexing needed for real-time dashboards; it is better suited for archival or batch processing of telemetry data. Option D is wrong because Azure Table Storage is a key-value store that lacks native JSON support, advanced indexing, and the low-latency read capabilities required for real-time dashboards; it is more appropriate for simple, high-volume structured data with limited query patterns.

Practice this question →
124
MCQmedium

Your organization stores IoT sensor data as JSON blobs in Azure Blob Storage. You need to query this data using SQL statements without moving the data. Which Azure service should you use?

A.Azure SQL Database
B.Azure Cosmos DB
C.Azure Data Lake Storage Gen2
D.Azure Synapse Serverless SQL
AnswerD

Azure Synapse Serverless SQL can query JSON files in Blob Storage using T-SQL.

Why this answer

Option A is correct because Azure Synapse Serverless SQL can query JSON data directly from Blob Storage using OPENROWSET with SQL. Option B is wrong because Azure Cosmos DB is a NoSQL database, not a query service over Blob Storage. Option C is wrong because Azure Data Lake Storage is a storage service, not a query engine.

Option D is wrong because SQL Database is a relational database, not for querying files in Blob Storage.

Practice this question →
125
MCQmedium

A smart building company stores sensor data from thousands of IoT devices as JSON documents in Azure Cosmos DB using the NoSQL API. Each document contains fields: deviceId (string), timestamp (datetime), temperature (float), humidity (float), and additional device-specific fields (e.g., motionDetected, CO2level). The most common query is: SELECT * FROM c WHERE c.deviceId = 'sensor-123' AND c.timestamp >= '2025-01-01' AND c.timestamp < '2025-02-01' ORDER BY c.timestamp DESC. Which indexing strategy will provide the best performance for this query?

A.Use the default indexing policy that automatically indexes all properties
B.Create a composite index on (deviceId ASC, timestamp DESC)
C.Disable indexing for all properties to speed up writes
D.Create a spatial index on the deviceId field
AnswerB

This composite index matches the query predicates: first seeks on deviceId equality, then efficiently performs a range scan on timestamp in descending order, avoiding an in-memory sort.

Why this answer

Option B is correct because the query filters on `deviceId` (equality) and `timestamp` (range with ORDER BY DESC). A composite index on `(deviceId ASC, timestamp DESC)` allows Cosmos DB to efficiently locate the partition for the device and then scan the timestamp range in descending order without an in-memory sort, minimizing RU consumption and latency.

Exam trap

The trap here is that candidates assume the default indexing policy is sufficient for all queries, but they miss that composite indexes are required to efficiently support queries that combine equality filters on one property with range filters and ORDER BY on another property.

How to eliminate wrong answers

Option A is wrong because the default indexing policy indexes all properties individually, which does not optimize the combined filter on `deviceId` and `timestamp` with an ORDER BY clause, leading to higher RU usage and potential full scans. Option C is wrong because disabling indexing entirely would force every query to perform a full sequential scan of all documents, dramatically increasing RU cost and latency, especially for range queries. Option D is wrong because a spatial index is designed for geospatial queries (e.g., ST_DISTANCE, ST_WITHIN) and has no relevance to filtering on `deviceId` and `timestamp`.

Practice this question →
126
MCQmedium

A smart home company stores sensor readings from thousands of devices in Azure Cosmos DB. Each reading includes a deviceID, timestamp (ISO format), sensor type, and value. The most common query retrieves all readings for a specific device within a time range. To minimize Request Units (RU) consumption and ensure even data distribution, which property should be chosen as the partition key?

A.A) deviceID
B.B) timestamp
C.C) sensor type
D.D) value
AnswerA

deviceID has high cardinality (many unique values) and is always used in the query filter, leading to efficient partition routing and even distribution.

Why this answer

DeviceID is the correct partition key because it is the primary filter in the most common query (all readings for a specific device within a time range). Partitioning by deviceID ensures that all readings for a single device are stored in the same logical partition, making queries highly efficient by targeting a single partition. It also provides even data distribution across physical partitions, as thousands of devices will have roughly equal numbers of readings, minimizing RU consumption.

Exam trap

The trap here is that candidates often choose timestamp because they think it naturally orders data by time, but they overlook that the most common query filters by deviceID first, and using timestamp as the partition key would cause cross-partition queries for every device-specific time range, dramatically increasing RU costs.

How to eliminate wrong answers

Option B (timestamp) is wrong because using timestamp as the partition key would cause all readings with the same timestamp (e.g., same second) to land in the same partition, creating hot spots and uneven distribution, and queries for a specific device would need to fan out across many partitions. Option C (sensor type) is wrong because sensor types are typically few (e.g., temperature, humidity), leading to a small number of large partitions (hot partitions) and poor query performance for device-specific queries. Option D (value) is wrong because values are highly varied and not used as a filter in the common query, making it a poor choice for partition key—it would scatter each device's data across many partitions, increasing RU consumption for range queries.

Practice this question →
127
MCQmedium

A social media company stores user posts in Azure Cosmos DB. Each post document contains fields like postId, userId, content, timestamp, and an array of comments. The comments array can grow large (hundreds per post), and the application frequently retrieves a post without its comments to display in a feed. To optimize read performance and minimize request units (RU) consumption, which data modeling approach should the company adopt?

A.A. Store comments in a separate container to isolate the data.
B.B. Store comments as separate documents and reference them from the post document via a comments array of IDs.
C.C. Use a vertical partition within the same document to separate the comments array.
D.D. Migrate the data to Azure SQL Database to use normalized tables and indexes.
AnswerB

This approach decouples comments from the post document. When retrieving a post for the feed, the application reads only the post document, avoiding the large comments array. This reduces RU consumption and improves latency. Comments can be loaded on demand when needed.

Why this answer

Option B is correct because storing comments as separate documents and referencing them via an array of IDs in the post document allows the application to retrieve the post without comments in a single point read, consuming minimal request units (RUs). This avoids loading the large comments array when only the post metadata is needed for the feed, significantly reducing RU consumption and improving read performance in Azure Cosmos DB.

Exam trap

The trap here is that candidates may think embedding the comments array is always optimal for performance, but they overlook that reading the entire document with a large array wastes RUs when only the post metadata is needed, making reference-based modeling more efficient for this access pattern.

How to eliminate wrong answers

Option A is wrong because storing comments in a separate container would require cross-container queries or application-level joins, increasing RU cost and latency, and losing the benefit of document co-location. Option C is wrong because Azure Cosmos DB does not support vertical partitions within a document; the comments array is already part of the document, and separating it logically does not reduce RU consumption when reading the entire document. Option D is wrong because migrating to Azure SQL Database is unnecessary and contradicts the requirement to optimize non-relational data; it would introduce schema rigidity and higher latency for the social media use case.

Practice this question →
128
Multi-Selecthard

Which THREE of the following are valid considerations when choosing between Azure Blob Storage and Azure Data Lake Storage Gen2 for a big data analytics workload?

Select 3 answers
A.ADLS Gen2 can be optimized for high-throughput analytics workloads
B.ADLS Gen2 supports a hierarchical namespace for folder-level organization
C.Blob Storage provides POSIX-compliant access control lists (ACLs)
D.ADLS Gen2 cannot use Blob Storage APIs
E.Blob Storage supports lifecycle management policies
AnswersA, B, E

ADLS Gen2 is designed for big data analytics with high throughput.

Why this answer

ADLS Gen2 supports a hierarchical namespace, POSIX-like permissions, and is cost-effective for both hot and cool tiers. Blob Storage lacks hierarchical namespace by default. Both support lifecycle management.

ADLS Gen2 can be used with Blob APIs but also has additional features.

Practice this question →
129
MCQmedium

A mobile game stores player achievements in Azure Cosmos DB. Each player has a PlayerID, and achievements are stored as JSON documents with varying fields. The most common query retrieves all achievements for a specific player. To ensure low latency and efficient throughput, which property should be chosen as the partition key?

A.PlayerID
B.Timestamp
C.AchievementType
D.Region
AnswerA

PlayerID is the most common query filter, has high cardinality, and evenly distributes data across partitions, resulting in efficient queries and throughput.

Why this answer

PlayerID is the correct partition key because the most common query retrieves all achievements for a specific player, and partitioning on PlayerID ensures that all documents for a given player are stored in the same physical partition. This allows the query to target a single partition, minimizing cross-partition queries and providing low latency and efficient throughput.

Exam trap

The trap here is that candidates often choose a high-cardinality key like Timestamp without considering the query pattern, mistakenly thinking any unique value is good, but the partition key must align with the most frequent query filter to avoid cross-partition overhead.

How to eliminate wrong answers

Option B (Timestamp) is wrong because using Timestamp as the partition key would scatter each player's achievements across multiple partitions, forcing cross-partition queries for the common 'all achievements for a player' query, increasing latency and RU consumption. Option C (AchievementType) is wrong because it would group achievements of the same type together, but a player's achievements span multiple types, again requiring cross-partition queries to retrieve all achievements for a player. Option D (Region) is wrong because it is unrelated to the player-centric query pattern; it would distribute a single player's data across partitions based on region, causing the same cross-partition query issue.

Practice this question →
130
MCQmedium

A social media application stores user profile data as JSON documents. Each user's document has a different structure, with fields that vary based on user activity. The application needs to query these documents efficiently using SQL-like syntax and support high write throughput. Which Azure data store is most appropriate for this workload?

A.Azure SQL Database
B.Azure Blob Storage
C.Azure Cosmos DB
D.Azure Table Storage
AnswerC

Azure Cosmos DB is a globally distributed, multi-model NoSQL database that supports JSON documents natively. It allows flexible schemas, SQL-like querying, and high throughput, making it ideal for this scenario.

Why this answer

Azure Cosmos DB is the most appropriate choice because it natively supports storing and querying JSON documents with varying schemas, offers SQL-like query syntax via its core (SQL) API, and provides guaranteed low-latency reads/writes at any scale with automatic indexing of all fields. Its multi-model nature and configurable consistency levels make it ideal for high-throughput workloads like a social media application.

Exam trap

The trap here is that candidates often confuse Azure Table Storage's key-value capabilities with document database features, overlooking that Table Storage does not support JSON documents, nested fields, or SQL-like queries, whereas Cosmos DB is explicitly designed for such workloads.

How to eliminate wrong answers

Option A is wrong because Azure SQL Database requires a fixed relational schema, making it inefficient for storing JSON documents with varying structures; while it supports JSON functions, it is not optimized for high write throughput on schema-less data. Option B is wrong because Azure Blob Storage is designed for unstructured binary or text data (like images or logs) and does not support SQL-like querying of individual JSON documents or efficient point queries on document fields. Option D is wrong because Azure Table Storage is a key-value store that does not support JSON documents natively, lacks SQL-like query syntax, and requires a flat schema with predefined partition and row keys, making it unsuitable for querying nested JSON fields.

Practice this question →
131
MCQeasy

You have an Azure Blob Storage container configured with the JSON snippet shown in the exhibit. What does the 'publicAccess' setting of 'Blob' allow?

A.Anonymous users can write blobs
B.No anonymous access is allowed
C.Anonymous users can list blobs in the container
D.Anonymous users can read blobs if they know the blob URL
AnswerD

'Blob' level allows anonymous read access to individual blobs, but not listing.

Why this answer

The 'Blob' level of public access allows anonymous read access to blobs only; container metadata is not accessible. 'Container' level would allow anonymous listing of blobs. 'None' disables public access. 'Storage' is not a valid value.

Practice this question →
132
MCQhard

You are designing a solution to store large binary files (up to 100 GB each) that are frequently read but rarely updated. The data must be accessible via HTTPS and support concurrent reads. Which Azure data store should you use?

A.Azure Files
B.Azure Cosmos DB
C.Azure NetApp Files
D.Azure Blob Storage
AnswerD

Supports large blobs, HTTPS access, and concurrent reads.

Why this answer

Option B is correct because Azure Blob Storage supports large blobs (up to 190.7 TiB) and is optimized for read-heavy workloads with HTTPS access and concurrent reads. Option A is wrong because Azure Files has a maximum file size of 4 TiB and is designed for file shares, not large binary blobs. Option C is wrong because Cosmos DB is for NoSQL transactional data, not large binary files.

Option D is wrong because Azure NetApp Files is for high-performance file workloads, but more complex and expensive for simple blob storage.

Practice this question →
133
MCQhard

A company uses Azure Table storage to store session state for a web application. They notice that read latency increases during peak hours. Which design change should they implement to reduce latency?

A.Change to Azure Blob storage
B.Store large attributes in a separate table
C.Switch to Azure Queue storage
D.Use a partition key that distributes load evenly, such as UserID
AnswerD

Even distribution avoids hot partitions and reduces latency.

Why this answer

Option D is correct because Azure Table storage partitions data based on the partition key. Using a partition key that distributes load evenly, such as UserID, ensures that read requests are spread across multiple partition servers, preventing hot partitions and reducing latency during peak hours.

Exam trap

The trap here is that candidates may confuse Azure Table storage with other Azure storage services (Blob, Queue) or focus on data size optimization (Option B) instead of understanding how partition key design directly impacts read performance in a partitioned NoSQL store.

How to eliminate wrong answers

Option A is wrong because Azure Blob storage is designed for unstructured data (e.g., images, videos) and does not provide the low-latency, key-value access pattern needed for session state. Option B is wrong because storing large attributes in a separate table does not address the root cause of read latency—it may even increase complexity and latency due to additional table lookups. Option C is wrong because Azure Queue storage is a messaging service for asynchronous communication, not a low-latency storage solution for session state reads.

Practice this question →
134
MCQmedium

A ride-sharing application uses Azure Cosmos DB for trip data. Each trip record contains TripID (unique), DriverID, RiderID, TripDate, and other details. The most common query retrieves all trips for a specific driver within a given date range. Which partition key should be chosen to minimize Request Unit (RU) consumption and ensure even data distribution?

A.TripID
B.DriverID
C.TripDate
D.RiderID
AnswerB

DriverID aligns with the most common query pattern. All trips for a given driver are stored together, allowing single-partition queries. This minimizes RU consumption if the number of trips per driver is within the 20 GB logical partition limit.

Why this answer

DriverID is the optimal partition key because the most common query filters on DriverID and a date range. Partitioning by DriverID ensures that all trips for a specific driver are stored in the same physical partition, making the query a single-partition operation that consumes minimal Request Units (RUs). It also provides even data distribution across partitions because each driver generates a roughly similar number of trips, avoiding hot spots.

Exam trap

The trap here is that candidates often pick TripDate because it seems logical for date-range queries, but they overlook that the primary filter is DriverID, and partitioning by TripDate would cause cross-partition queries and potential hot spots on high-traffic dates.

How to eliminate wrong answers

Option A is wrong because TripID is unique per trip, which would cause each query to fan out across all partitions (cross-partition query), increasing RU consumption and latency. Option C is wrong because TripDate can lead to hot partitions (e.g., all trips on a single day hitting one partition) and does not directly support the primary filter on DriverID, forcing cross-partition queries. Option D is wrong because RiderID is not used in the most common query filter, so partitioning by RiderID would still require a cross-partition query to find trips by DriverID, wasting RUs.

Practice this question →
135
MCQeasy

A media company stores user profile images in Azure Blob Storage. Regulators require that the images cannot be deleted or overwritten for a period of 90 days after upload. Which Azure Blob Storage feature should the company enable to meet this requirement?

A.A: Soft delete
B.B: Immutable storage with a time-based retention policy
C.C: Access tiers (Hot, Cool, Archive)
D.D: Lifecycle management rules
AnswerB

Immutable storage enforces a write-once-read-many (WORM) state, preventing any modification or deletion during the retention period, exactly as required.

Why this answer

Immutable storage with a time-based retention policy (also known as WORM – Write Once, Read Many) prevents blobs from being deleted or overwritten for a specified retention interval. By setting a 90-day policy, the company ensures that user profile images remain unmodifiable and undeletable during that period, directly satisfying the regulatory requirement.

Exam trap

The trap here is that candidates often confuse soft delete (which only recovers deleted blobs) with immutable storage (which prevents both deletion and overwrite during the retention period), leading them to choose soft delete when the requirement explicitly prohibits overwrites as well.

How to eliminate wrong answers

Option A is wrong because soft delete only protects blobs from accidental deletion by retaining them for a configurable period after deletion, but it does not prevent overwrites or guarantee immutability for a fixed duration. Option C is wrong because access tiers (Hot, Cool, Archive) control storage cost and retrieval latency based on data access patterns, but they offer no protection against deletion or overwrite. Option D is wrong because lifecycle management rules automate transitions between access tiers or deletion based on age or conditions, but they do not enforce a write-once, read-many (WORM) state that blocks modifications or deletions.

Practice this question →
136
MCQeasy

Refer to the exhibit. You have a CSV file stored in Azure Blob Storage. You want to query this file using Azure Synapse Serverless SQL. Which OPENROWSET option should you use?

A.FORMAT = 'JSON'
B.FORMAT = 'PARQUET'
C.FORMAT = 'CSV'
D.FORMAT = 'DELTA'
AnswerC

CSV format is correct for CSV files.

Why this answer

Option D is correct because FORMAT = 'CSV' specifies the file format for CSV files. Option A is wrong because FORMAT = 'JSON' is for JSON files. Option B is wrong because FORMAT = 'PARQUET' is for Parquet files.

Option C is wrong because FORMAT = 'DELTA' is for Delta Lake.

Practice this question →
137
MCQhard

A data lake stores Parquet files in Azure Data Lake Storage Gen2, organized by date (e.g., /data/2023/01/15/). Analysts frequently run queries that filter on a specific date range. Which feature of Azure Data Lake Storage Gen2 directly enables efficient directory-level operations like renaming or moving entire date partitions without rewriting files?

A.Hierarchical namespace
B.Blob soft delete
C.Change feed
D.Immutable storage
AnswerA

Correct. The hierarchical namespace enables directory-level atomic operations, allowing efficient reorganization of partitions (e.g., moving a month's worth of data) without scanning or copying individual files.

Why this answer

The hierarchical namespace feature in Azure Data Lake Storage Gen2 enables true directory-level operations, such as renaming or moving entire partitions (e.g., /data/2023/01/15/), by treating directories as first-class objects. This allows atomic metadata operations without rewriting or copying the underlying Parquet files, which is essential for efficient partition management in data lake scenarios.

Exam trap

The trap here is that candidates often confuse the hierarchical namespace with general blob storage features like soft delete or change feed, mistakenly thinking those features provide directory-level management, when in fact only the hierarchical namespace enables atomic partition operations.

How to eliminate wrong answers

Option B is wrong because blob soft delete is a data protection feature that preserves deleted blobs for a retention period, not a mechanism for directory-level rename or move operations. Option C is wrong because the change feed provides a log of blob creation, modification, and deletion events for auditing or incremental processing, but it does not enable efficient directory-level operations. Option D is wrong because immutable storage (WORM policy) prevents blobs from being modified or deleted for a specified period, which would actually block the ability to rename or move partitions, not enable it.

Practice this question →
138
MCQeasy

A company needs to store large amounts of unstructured data (videos and images) for a media streaming application. The data must be accessible via HTTP/HTTPS and support tiered storage for cost optimization. Which Azure storage solution should they choose?

A.Azure Disk Storage
B.Azure Blob Storage
C.Azure Table Storage
D.Azure Files
AnswerB

Azure Blob Storage supports unstructured data, HTTP/HTTPS access, and tiered storage.

Why this answer

Azure Blob Storage is designed for unstructured data, supports HTTP access, and offers hot, cool, and archive tiers. Option A (Azure Files) is for file shares; Option B (Azure Disk Storage) is for VM disks; Option D (Azure Table Storage) is for NoSQL key-value data.

Practice this question →
139
MCQmedium

A travel booking application stores booking data in Azure Cosmos DB using the NoSQL API. Each booking document contains: BookingID (unique), UserID, Destination, TravelDate, Price. The most common query is: 'Retrieve all bookings for a specific UserID, sorted by TravelDate descending.' To minimize Request Unit (RU) consumption, which property should be chosen as the partition key?

A.BookingID
B.UserID
C.Destination
D.TravelDate
AnswerB

UserID is the filter in the common query. With UserID as partition key, all bookings for a user reside in one partition, making queries efficient and reducing RU consumption.

Why this answer

UserID is the correct partition key because the most common query filters on UserID, and Cosmos DB routes queries to the exact physical partition(s) containing that UserID's data. This minimizes cross-partition fan-out, reducing RU consumption. A partition key should align with the primary query filter to enable efficient point-read or single-partition query execution.

Exam trap

The trap here is that candidates often pick a high-cardinality key like BookingID or a date-based key like TravelDate, thinking uniqueness or time-ordering helps, but they ignore that the partition key must match the most frequent query filter to avoid cross-partition queries and high RU costs.

How to eliminate wrong answers

Option A (BookingID) is wrong because it would scatter each booking across partitions, forcing every query to fan out to all partitions to find bookings for a specific UserID, increasing RU cost. Option C (Destination) is wrong because queries filter by UserID, not Destination; using Destination would still require a cross-partition query unless the filter also included Destination, and it would not collocate all bookings for a single user. Option D (TravelDate) is wrong because it would spread a single user's bookings across many partitions (one per date), again causing cross-partition queries and high RU consumption for the common query pattern.

Practice this question →
140
MCQeasy

A company stores customer reviews for an e-commerce site. Each review contains a product ID, user ID, rating, and optional comments and images. The reviews are written once and rarely updated. The company needs to query reviews by product ID with low latency and also perform simple key-value lookups. They want a cost-effective, serverless solution that requires no scaling management. Which Azure data store should they choose?

A.Azure Cosmos DB SQL API
B.Azure Table Storage
C.Azure Blob Storage
D.Azure SQL Database
AnswerB

Azure Table Storage is a serverless, cost-effective key-value store ideal for storing and querying semi-structured data by a key (product ID). It meets the latency and budget requirements.

Why this answer

Azure Table Storage is a cost-effective, serverless NoSQL key-value store that supports simple key-value lookups and querying by partition key (e.g., ProductID) with low latency. It requires no scaling management, as it automatically scales based on demand, and is ideal for immutable, rarely-updated data like customer reviews. The pay-per-request pricing model makes it highly cost-effective for this workload.

Exam trap

The trap here is that candidates often choose Azure Cosmos DB for any NoSQL scenario, overlooking that Azure Table Storage is the simpler, more cost-effective serverless option for basic key-value workloads without global distribution or complex querying needs.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB SQL API is a globally distributed, multi-model database that is overkill and more expensive for simple key-value lookups on rarely-updated data, and it requires throughput provisioning (RU/s) rather than being truly serverless with no scaling management. Option C is wrong because Azure Blob Storage is designed for unstructured binary data (images, videos) and does not support efficient key-value lookups or querying by product ID with low latency; it lacks native indexing for such queries. Option D is wrong because Azure SQL Database is a relational database that requires schema management, scaling configuration, and is not serverless by default (unless using the serverless tier, which still incurs compute costs and is not optimized for simple key-value lookups).

Practice this question →
141
MCQmedium

You have applied the lifecycle management policy shown in the exhibit to an Azure Storage account. A blob named 'logs/error.log' was last modified 200 days ago. In which tier is the blob currently stored?

A.Hot tier
B.The blob has been deleted
C.Cool tier
D.Archive tier
AnswerD

The policy archives blobs after 90 days; at 200 days, the blob is in Archive.

Why this answer

The policy moves blobs to Cool after 30 days and to Archive after 90 days. Since the blob was modified 200 days ago, it has already been moved to Archive after 90 days. The delete action occurs after 365 days, so it has not been deleted yet.

Therefore, the blob is in the Archive tier.

Practice this question →
142
Drag & Dropmedium

Drag and drop the steps to configure a firewall rule for Azure SQL Database in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Firewall rules are set at the server level to allow client IP addresses to access the database.

Practice this question →
143
MCQmedium

A manufacturing company collects sensor readings from thousands of IoT devices. Each reading consists of a device ID, a timestamp, and a numeric value. The data is stored as key-value pairs and must support low-latency reads and writes at a global scale. The company also needs to query the data by device ID and time range. Which Azure Cosmos DB API should they choose?

A.Core (SQL) API
B.MongoDB API
C.Table API
D.Gremlin API
AnswerC

The Table API is built for key-value workloads and stores data as items with a partition key and row key. It allows efficient point reads and range queries, making it ideal for IoT sensor data.

Why this answer

The Table API is the correct choice because it is designed for key-value workloads with a schema-less design, supporting low-latency reads and writes at global scale. It allows querying by partition key (device ID) and row key (timestamp) to efficiently retrieve data by device ID and time range, matching the IoT sensor data requirements.

Exam trap

The trap here is that candidates often choose the Core (SQL) API because they associate SQL with querying, but the Table API is specifically built for key-value and time-series workloads with composite key queries, which is the exact pattern described.

How to eliminate wrong answers

Option A is wrong because the Core (SQL) API is optimized for document-based queries with SQL-like syntax, not for simple key-value lookups with partition and row keys, and it adds unnecessary complexity for this use case. Option B is wrong because the MongoDB API is designed for document databases with BSON format and is not optimized for key-value pair storage with composite key queries by device ID and timestamp. Option D is wrong because the Gremlin API is for graph databases used to model relationships between entities, not for key-value or time-series data from IoT devices.

Practice this question →
144
MCQmedium

A company stores customer support chat transcripts as plain text files in Azure Blob Storage. The files are accessed frequently for the first 30 days, then infrequently for the next 2 years, and after that must be retained for 7 years for compliance but are rarely accessed. The company wants to minimize storage costs by automatically moving data through appropriate access tiers. Which Azure Blob Storage lifecycle management policy should they implement?

A.Move blobs from Hot to Cool after 30 days, then to Archive after 2 years
B.Store all data in Hot tier for the full retention period
C.Move blobs from Hot to Archive after 30 days and delete after 2 years
D.Store all data in Cool tier for the first 30 days, then move to Archive
AnswerA

This policy correctly matches the access pattern: Hot tier for frequent initial access, Cool for infrequent intermediate access (still retained for 2 years but accessed rarely), and Archive for long-term compliance retention where data is rarely accessed and retrieval latency is acceptable.

Why this answer

Option A is correct because the lifecycle management policy matches the access pattern: move blobs from Hot (frequent access for first 30 days) to Cool (infrequent access for next 2 years) after 30 days, then to Archive (rare access for 7-year compliance) after 2 years. This minimizes storage costs by using the cheapest tier for each phase while retaining data for the required 7-year compliance period.

Exam trap

The trap here is that candidates may overlook the rehydration latency of the Archive tier and incorrectly move data to Archive during a period of frequent access, or fail to account for the full compliance retention period when choosing deletion actions.

How to eliminate wrong answers

Option B is wrong because storing all data in the Hot tier for the full retention period incurs the highest storage cost, ignoring the infrequent and rare access phases. Option C is wrong because moving blobs directly to Archive after 30 days makes them inaccessible for frequent access (Archive has a 15-minute to 15-hour rehydration latency) and deleting after 2 years violates the 7-year compliance retention requirement. Option D is wrong because storing data in the Cool tier for the first 30 days does not match the frequent access pattern (Cool tier has higher access costs and lower availability than Hot) and fails to use the Hot tier for the initial high-access period.

Practice this question →
145
MCQmedium

A company stores terabytes of historical log data in Azure Blob Storage. The data is rarely accessed but must be retained for 10 years for compliance. The company wants to minimize storage costs. Which storage tier should you use?

A.Cool tier
B.Archive tier
C.Hot tier
D.Premium tier
AnswerB

Archive tier is the lowest cost for long-term retention.

Why this answer

The Archive tier is the correct choice because it is designed for data that is rarely accessed and has a flexible retrieval latency (hours), making it ideal for long-term retention of historical logs. It offers the lowest storage cost among Azure Blob Storage tiers, which directly minimizes costs for data that must be kept for 10 years but is seldom read.

Exam trap

The trap here is that candidates often confuse the Archive tier's low storage cost with immediate accessibility, forgetting that retrieval latency and rehydration costs apply, but the question explicitly states 'rarely accessed' and 'minimize storage costs,' making Archive the clear choice.

How to eliminate wrong answers

Option A is wrong because the Cool tier is optimized for data accessed infrequently (e.g., every 30 days) but still incurs higher storage costs than Archive and has a minimum storage duration of 30 days, making it less cost-effective for 10-year retention. Option C is wrong because the Hot tier is designed for frequently accessed data with the highest storage cost, which would unnecessarily increase expenses for rarely accessed logs. Option D is wrong because the Premium tier uses SSD-backed storage for low-latency, high-transaction workloads and is the most expensive option, completely unsuitable for archival data.

Practice this question →
146
Matchingmedium

Match each Azure SQL Database tier to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Low-cost for small workloads

Balanced performance and cost

High performance and low latency

Highly scalable for large databases

Auto-scaling compute based on demand

Why these pairings

Azure SQL Database offers various service tiers.

Practice this question →
147
MCQhard

A logistics company tracks shipments. For each shipment, metadata (ID, weight, destination) is stored in a relational table. The route history is a sequence of events (timestamp, location, status) that is frequently appended but never updated or deleted. The application needs to quickly retrieve the latest status of a shipment and occasionally run analytical queries over the full route history. The company wants to minimize storage cost and use Azure services. Which Azure data store should they choose for the route history?

A.Azure Cosmos DB Core (SQL) API
B.Azure Table Storage
C.Azure Blob Storage with append blobs
D.Azure SQL Database with a JSON column
AnswerC

Correct. Append blobs are designed for log data, offer low cost, and can be queried using serverless SQL or Azure Data Lake Storage analytics tools for full historical analysis.

Why this answer

Azure Blob Storage with append blobs is the correct choice because route history is write-once, read-many (WORM) data that is frequently appended but never modified or deleted. Append blobs are optimized for sequential append operations, offering low-cost storage for large volumes of event data, and they support fast retrieval of the latest status by reading the last block. This minimizes storage cost while allowing occasional analytical queries over the full history via Azure Synapse or other analytics services.

Exam trap

The trap here is that candidates often choose Azure Cosmos DB or Azure SQL Database because they associate 'fast retrieval' with transactional databases, overlooking that append blobs provide both low-cost storage and efficient last-block retrieval for append-only event sequences.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB Core (SQL) API is a globally distributed, multi-model NoSQL database optimized for low-latency reads and writes with flexible schemas, but it is significantly more expensive than blob storage for append-only event data and does not provide the cost efficiency of append blobs for this workload. Option B is wrong because Azure Table Storage is a key-value store designed for structured, schema-less data with point queries, but it is not optimized for append-only sequences and incurs higher costs per operation for frequent appends compared to blob storage. Option D is wrong because Azure SQL Database with a JSON column is a relational database that supports JSON data, but it introduces unnecessary relational overhead, higher storage costs, and transactional constraints for append-only event data that never requires updates or deletes.

Practice this question →
148
MCQmedium

A company stores backup files in Azure Blob Storage. The backups are taken daily and must be retained for 7 years. The backup files are rarely accessed after the first month. The company wants to minimize storage costs while ensuring that backups are available for retrieval within 5 hours when needed. Which storage tier should they use after the first month?

A.Archive tier
B.Cool tier
C.Hot tier
D.Premium tier
AnswerB

Cost-effective and retrieval time is within minutes to hours.

Why this answer

Option C is correct because the Cool tier has a retrieval time of minutes to hours (typically), and is cheaper than Hot. Archive tier is the cheapest but retrieval time can be up to 15 hours, which exceeds the 5-hour requirement. Option A is wrong because Hot is more expensive.

Option B is wrong because Archive retrieval time is too long. Option D is wrong because Premium is expensive and designed for low-latency access.

Practice this question →
149
MCQmedium

A mobile app stores user preferences as JSON documents in Azure Cosmos DB. The document includes userId, theme, language, and notification settings. The most common query retrieves the document for a specific userId. To minimize cost and ensure even distribution, which property should be chosen as the partition key?

A.userId
B.theme
C.language
D.a concatenation of userId and language
AnswerA

userId has high cardinality and evenly distributes data across partitions, minimizing Request Unit (RU) consumption for point reads.

Why this answer

The userId property is the ideal partition key because it provides high cardinality (each user has a unique ID) and ensures even request distribution across physical partitions. Since the most common query retrieves a document by userId, using it as the partition key makes those queries point reads (single-partition queries), which are the most cost-efficient and fastest in Azure Cosmos DB.

Exam trap

The trap here is that candidates often choose a concatenated key (option D) thinking it adds uniqueness or query flexibility, but Azure Cosmos DB's partition key design favors a single high-cardinality attribute for even distribution and simple point reads.

How to eliminate wrong answers

Option B (theme) is wrong because theme has low cardinality (only a few possible values like 'light' or 'dark'), leading to hot partitions and uneven data distribution. Option C (language) is wrong because language also has low cardinality (e.g., 'en', 'fr', 'es'), causing similar skew and throttling under load. Option D (a concatenation of userId and language) is wrong because it adds unnecessary complexity without benefit—userId alone already provides unique document identification and even distribution, and concatenation would increase storage overhead and partition key size (up to 2 KB limit) without improving query performance.

Practice this question →
150
MCQmedium

A gaming company stores player game scores in Azure Cosmos DB. Each document contains PlayerID, GameID, Score, Timestamp. The most common query is: 'Get all scores for a specific game ordered by score descending'. Which partition key should be chosen to minimize Request Unit (RU) consumption?

A.PlayerID
B.GameID
C.Score
D.Timestamp
AnswerB

Partitioning by GameID collocates all scores for a game in one partition, so the query targeting a specific GameID is a single-partition query, consuming fewer RUs.

Why this answer

GameID is the correct partition key because the most common query filters on GameID, and Cosmos DB routes queries to the exact physical partition(s) containing that GameID. This avoids cross-partition fan-out, minimizing RU consumption. A partition key that matches the query filter ensures efficient index lookup and data retrieval.

Exam trap

The trap here is that candidates often pick PlayerID thinking it uniquely identifies each player, but they overlook that the query filters on GameID, making GameID the only partition key that avoids cross-partition queries and minimizes RU consumption.

How to eliminate wrong answers

Option A (PlayerID) is wrong because it would scatter scores for the same game across multiple partitions, forcing a cross-partition query that scans all partitions and increases RU cost. Option C (Score) is wrong because it is a high-cardinality, frequently updated value that can cause hot partitions and does not align with the query filter on GameID. Option D (Timestamp) is wrong because it would distribute data by time, not by game, so querying for a specific game would still require scanning all partitions.

Practice this question →
← PreviousPage 2 of 3 · 214 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Describe considerations for working with non-relational data on Azure questions.

Start 20-question session