Courseiva

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

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

Practice these questionsDomain overviewAll questions
1
MCQeasy

A company must archive customer correspondence PDFs that are rarely accessed but must be retained for seven years. The documents must be available for read within seconds if requested. Which Azure Blob Storage access tier should be used to minimize storage cost while meeting the availability requirement?

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

Cool tier is for infrequent access with immediate availability and lower storage cost than Hot.

Why this answer

The Cool tier is optimal because it balances low storage cost with high availability for data that is infrequently accessed but must be retrievable within seconds. It offers the same low-latency retrieval as the Hot tier (milliseconds) but at a lower storage price, making it ideal for archived correspondence that still requires immediate read access.

Exam trap

The trap here is that candidates see 'archived' and immediately choose the Archive tier, forgetting the 'within seconds' availability requirement that disqualifies it.

How to eliminate wrong answers

Option A is wrong because the Hot tier has the highest storage cost and is designed for frequently accessed data, not for rarely accessed archives. Option C is wrong because the Archive tier has the lowest storage cost but retrieval times can range from minutes to hours, failing the 'within seconds' requirement. Option D is wrong because the Premium tier is optimized for high transaction volumes and low latency on block blobs, not for cost-effective archiving of rarely accessed data.

Practice this question →
2
Multi-Selectmedium

A company is designing a solution to store time-series data from millions of IoT devices. Which TWO Azure services are most suitable for this scenario?

Select 2 answers
A.Azure Data Explorer
B.Azure Blob Storage
C.Azure Cosmos DB
D.Azure Redis Cache
E.Azure SQL Database
AnswersA, C

Built for time-series analytics and high-throughput ingestion.

Why this answer

Azure Cosmos DB (option B) is suitable for time-series data with its flexible schema and low latency. Azure Data Explorer (option D) is optimized for time-series analytics. Option A (Azure SQL Database) is relational and less efficient for high-volume time-series.

Option C (Azure Blob Storage) is for unstructured data. Option E (Azure Redis Cache) is a cache, not primary storage.

Practice this question →
3
MCQmedium

A company has a legacy application that requires SMB (Server Message Block) file shares to store and access configuration files. They want to migrate this data to Azure without modifying the application. Which Azure storage solution should they use?

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

Azure Files offers fully managed cloud file shares that support the SMB protocol. It can be mounted directly by on-premises or cloud applications, allowing the legacy application to access files without modification.

Why this answer

Azure Files provides fully managed SMB (Server Message Block) file shares in the cloud, supporting the SMB 3.0 protocol. This allows the legacy application to access configuration files over the network using standard file share paths without any code changes, making it the ideal migration target for lift-and-shift scenarios.

Exam trap

The trap here is that candidates often confuse Azure Blob Storage (object storage) with file shares, assuming it can serve SMB traffic, but Blob Storage does not natively support the SMB protocol and requires application modifications or third-party tools to emulate file shares.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is an object store that uses REST APIs or SDKs, not SMB protocol, so the legacy application would require modification to use blob-based access. Option C is wrong because Azure Queue Storage is a messaging service for asynchronous communication between application components, not a file share for storing and accessing configuration files. Option D is wrong because Azure Disk Storage provides block-level storage volumes attached to virtual machines, but it does not expose an SMB file share endpoint; it requires mounting as a disk within a VM, which does not match the requirement of accessing configuration files via SMB shares.

Practice this question →
4
MCQmedium

Refer to the exhibit. An administrator deploys this Azure Policy assignment. What is the most likely effect on storage account 'storage1'?

A.Public network access will be denied.
B.The storage account will be deleted.
C.Firewall rules will be added.
D.Soft Delete will be enabled.
AnswerA

The 'deny' effect denies non-compliant requests.

Why this answer

The Azure Policy assignment shown in the exhibit denies the creation or update of storage accounts that do not have public network access disabled. Since 'storage1' is subject to this policy, the policy will enforce the 'Deny' effect, preventing any configuration that allows public network access. If 'storage1' already exists and is compliant, it remains; if it is non-compliant, the policy will block changes that would enable public access, effectively denying public network access.

Exam trap

The trap here is that candidates confuse 'Deny' with 'DeployIfNotExists' or 'Modify' effects, assuming the policy will automatically change settings or delete resources, when in fact 'Deny' only blocks non-compliant requests.

How to eliminate wrong answers

Option B is wrong because Azure Policy with a 'Deny' effect does not delete resources; it only prevents non-compliant creation or updates. Option C is wrong because the policy specifically targets 'public network access' (a property of the storage account), not firewall rules—firewall rules are a separate configuration that can coexist with disabled public network access. Option D is wrong because the policy does not mention 'Soft Delete' or any blob-level data protection feature; it only evaluates the 'public network access' property.

Practice this question →
5
MCQhard

A social media application stores user posts in Azure Cosmos DB. Each document contains fields: PostID (unique), UserID, Timestamp, Content, LikesCount. The most common query retrieves all posts by a specific UserID ordered by Timestamp descending. Which partition key and indexing strategy minimizes Request Unit (RU) consumption?

A.Partition key: PostID; Index: range on Timestamp
B.Partition key: UserID; Index: range on Timestamp
C.Partition key: Timestamp; Index: range on UserID
D.Partition key: UserID; Index: composite on (UserID, PostID)
AnswerB

Correct - UserID as partition key keeps each user's posts together. A range index on Timestamp enables efficient in-partition sorting, resulting in low RU.

Why this answer

Option B is correct because the query filters on UserID, so setting UserID as the partition key ensures all posts for a user are in the same physical partition, avoiding cross-partition queries. Adding a range index on Timestamp allows efficient sorting without additional RU overhead, as Cosmos DB can use the index to return results in descending order directly.

Exam trap

The trap here is that candidates often choose a composite index (Option D) thinking it optimizes both filter and sort, but Cosmos DB's indexing engine can satisfy the ORDER BY with a simple range index on the sort column alone, and a composite index would only add unnecessary write RU cost.

How to eliminate wrong answers

Option A is wrong because PostID as partition key would scatter each user's posts across multiple partitions, forcing a fan-out query that scans all partitions and consumes more RUs. Option C is wrong because Timestamp as partition key would also scatter posts for the same user across partitions, and the range index on UserID does not help sort by Timestamp efficiently. Option D is wrong because while UserID partition key is correct, a composite index on (UserID, PostID) is unnecessary and adds write overhead; a simple range index on Timestamp is sufficient for the ORDER BY clause.

Practice this question →
6
MCQmedium

A media company stores user profiles in Azure Cosmos DB using the Core (SQL) API. Each profile document contains a userId (unique), name, email, and a subscriptions array containing objects with a serviceName and startDate. The application needs to efficiently retrieve a single user by userId and also run a query to find all users who have a subscription to the service 'PremiumVideo'. Which partition key design is most appropriate for this workload?

A.Partition key on email
B.Partition key on userId
C.Partition key on serviceName (extracted from subscriptions array)
D.Partition key on a composite key combining userId and serviceName
AnswerB

Correct. Partitioning by userId ensures even distribution and efficient point reads. The subscription query can still run as a cross-partition query, which is acceptable for this workload.

Why this answer

Option B is correct because partitioning on userId ensures each document is evenly distributed across physical partitions, as userId is unique and used for point reads (the most efficient operation in Cosmos DB). The query for users with a 'PremiumVideo' subscription will be a cross-partition query regardless of partition key choice, but the primary workload—retrieving a single user by userId—is optimized with this design. Partitioning on userId also avoids hot partitions and adheres to the best practice of using a high-cardinality, frequently queried field as the partition key.

Exam trap

The trap here is that candidates assume partitioning on a frequently queried field like serviceName will optimize the subscription query, but they overlook that Cosmos DB requires the partition key to be a top-level property with high cardinality, and that point reads (by userId) are the most common and cost-sensitive operation in this workload.

How to eliminate wrong answers

Option A is wrong because email is not used in the primary point-read query (by userId), and partitioning on email would scatter documents across partitions for userId-based lookups, requiring inefficient cross-partition queries. Option C is wrong because serviceName is an array element, not a top-level property; Cosmos DB cannot use an array element as a partition key directly, and even if extracted, it would create a low-cardinality key (few distinct values like 'PremiumVideo'), leading to hot partitions and throttling. Option D is wrong because a composite key combining userId and serviceName is unnecessary and adds complexity; it does not improve point-read efficiency for userId alone (the primary workload) and would still require cross-partition queries for the subscription filter.

Practice this question →
7
MCQmedium

A mobile gaming company stores player session data as key-value pairs. Each player has a unique PlayerID, and the application needs to read/write the player's current level and score with very low latency. The data does not require complex queries, and the schema (attributes per player) can vary. The company wants a fully managed, globally distributed NoSQL database. Which Azure data store should they choose?

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

The Table API is a key-value store that provides low-latency access, global distribution, and a flexible schema. It is designed for simple lookups by partition key and row key, fitting this use case perfectly.

Why this answer

Azure Cosmos DB Table API is the correct choice because it provides a fully managed, globally distributed NoSQL database that supports key-value data with schema flexibility. It offers low-latency reads and writes (single-digit milliseconds at the 99th percentile) and automatic global distribution, making it ideal for storing player session data with varying attributes per player.

Exam trap

The trap here is that candidates may confuse Azure Cache for Redis as a durable database, but it is primarily an in-memory cache that requires additional configuration for persistence and global distribution, whereas Cosmos DB Table API is a fully managed, globally distributed NoSQL database with built-in durability and low latency.

How to eliminate wrong answers

Option B (Azure SQL Database) is wrong because it is a relational database requiring a fixed schema and complex query capabilities, which contradicts the requirement for schema flexibility and key-value simplicity. Option C (Azure Blob Storage) is wrong because it is an object storage service for unstructured blobs (files, images, videos), not a low-latency key-value store for small data items like player level and score. Option D (Azure Cache for Redis) is wrong because it is an in-memory caching service, not a fully managed, globally distributed durable database; it would require additional persistence and replication setup to meet the durability and global distribution needs.

Practice this question →
8
MCQhard

Refer to the exhibit. You are analyzing the configuration of an Azure Storage account. Which of the following is true about this account?

A.It supports Azure Data Lake Storage Gen2.
B.It allows all network traffic by default.
C.Encryption uses Azure Key Vault.
D.It is a general-purpose v1 storage account.
AnswerA

isHnsEnabled indicates Data Lake Storage Gen2.

Why this answer

The property 'isHnsEnabled' is set to true, which enables the hierarchical namespace for Azure Data Lake Storage Gen2. Option A is wrong because the storage is not Blob Storage only; it's StorageV2 with HNS. Option C is wrong because the network ACLs have default action 'Deny' and no rules, so access is denied by default.

Option D is wrong because the encryption key source is Microsoft.Storage, not Azure Key Vault.

Practice this question →
9
MCQeasy

Your team needs to store unstructured data such as documents, images, and videos for a data lake analytics project. The data will be processed by Azure Data Lake Storage Gen2. Which storage account type should you create?

A.StorageV2 (general-purpose v2) with hierarchical namespace enabled
B.BlobStorage
C.QueueStorage
D.FileStorage
AnswerA

This is the required account type for Data Lake Storage Gen2.

Why this answer

Azure Data Lake Storage Gen2 requires a storage account with hierarchical namespace enabled. Option A is wrong because Blob Storage alone does not have hierarchical namespace. Option B is wrong because File Storage is for file shares.

Option D is wrong because Queue Storage is for messaging.

Practice this question →
10
Multi-Selectmedium

Which TWO are valid access tiers for Azure Blob Storage? (Choose two.)

Select 2 answers
A.Premium
B.Cold
C.Cool
D.Frozen
E.Hot
AnswersC, E

Cool tier is for infrequently accessed data.

Why this answer

Hot, Cool, and Archive are the three access tiers. Premium is a performance tier, not an access tier. Cold is not a standard tier.

Practice this question →
11
Multi-Selecthard

Which THREE of the following are features of Azure Data Lake Storage Gen2?

Select 3 answers
A.Integration with Azure Active Directory (Microsoft Entra ID)
B.Geo-redundant storage (GRS)
C.POSIX-compliant access control lists (ACLs)
D.Atomic rename of directories
E.Fixed-size block storage
AnswersA, C, D

It supports Azure AD-based authentication and authorization.

Why this answer

Azure Data Lake Storage Gen2 combines Blob Storage with a hierarchical namespace. Option A is correct: it supports POSIX-like access control lists. Option B is correct: it integrates with Azure Active Directory (Microsoft Entra ID) for authentication.

Option C is correct: it supports atomic rename of directories. Option D is wrong because fixed-size blocks are a feature of Blob Storage, but Data Lake Storage Gen2 uses hierarchical namespace, not fixed-size blocks. Option E is wrong because Geo-redundant storage (GRS) is a replication option, not a feature specific to Data Lake Storage Gen2.

Practice this question →
12
MCQmedium

A development team is designing an application that stores user session data in Azure Cosmos DB. Each session document contains a sessionId (unique), userId, timestamp, and a JSON field 'metadata' that can include various optional properties. The application frequently queries by userId to retrieve all sessions for a particular user. Which property should be chosen as the partition key to optimize query performance and ensure even data distribution?

A.sessionId
B.userId
C.timestamp
D.metadata
AnswerB

userId is the most common filter, and using it as partition key allows queries for a specific user to be routed to a single partition, offering fast and efficient reads.

Why this answer

The partition key should be the property most frequently used in queries and that provides high cardinality for even distribution. Since the application frequently queries by userId to retrieve all sessions for a user, choosing userId as the partition key ensures that all session documents for a given user are stored in the same logical partition, making these queries efficient and fast. Additionally, userId typically has a large number of distinct values, which promotes even data distribution across physical partitions.

Exam trap

The trap here is that candidates often choose sessionId because it is unique, not realizing that a high-cardinality key that is not used in queries leads to inefficient cross-partition queries, while a key like userId balances query efficiency with distribution.

How to eliminate wrong answers

Option A is wrong because sessionId is unique per document, which would cause each query by userId to fan out across all partitions, resulting in cross-partition queries that are slower and more expensive. Option C is wrong because timestamp often has low cardinality (many documents share the same timestamp) and can lead to hot partitions, especially if many sessions are created simultaneously, causing uneven data distribution and throttling. Option D is wrong because metadata is a JSON field with optional, unpredictable properties; using it as a partition key can lead to skewed distribution and poor query performance, as the partition key value may be missing or vary inconsistently.

Practice this question →
13
Multi-Selectmedium

Which TWO of the following are characteristics of Azure Blob Storage?

Select 2 answers
A.Enforces a fixed schema for stored data
B.Supports access tiers (Hot, Cool, Archive)
C.Supports storing large binary objects such as videos
D.Provides ACID transactions across multiple records
E.Only supports block blobs
AnswersB, C

Blob Storage offers tiered storage for cost optimization.

Why this answer

Options A and C are correct. Blob Storage supports storing large unstructured data like videos (A) and provides access tiers (C). Option B is wrong because Blob Storage does not enforce a schema.

Option D is wrong because Blob Storage is not a relational database. Option E is wrong because Blob Storage supports both block and append blobs.

Practice this question →
14
MCQeasy

A media company stores high-definition video files for on-demand streaming. The files are accessed very frequently for the first 30 days after upload, then rarely (about once per month) for the next year, and after one year they are rarely accessed but must be retained for compliance (about once per year). Which set of access tier transitions minimizes cost while meeting access requirements?

A.Hot for 30 days, then Cool for 11 months, then Archive
B.Hot for 30 days, then Archive immediately
C.Cool for 30 days, then Cool for 11 months, then Archive
D.Hot for 365 days, then Archive
AnswerA

Hot tier serves the initial frequent access with low latency. Cool tier reduces storage cost during the period of occasional access (once per month) while still allowing retrieval within seconds. Archive tier provides the lowest cost for long-term compliance storage.

Why this answer

Option A is correct because it aligns the Azure Blob Storage access tier transitions with the access pattern: Hot tier for the first 30 days of frequent access, Cool tier for the next 11 months of monthly access, and Archive tier after one year for rare compliance access. This minimizes cost by moving data to progressively cheaper storage tiers as access frequency drops, while still meeting the access requirements (Cool supports monthly access, Archive supports yearly access with retrieval time).

Exam trap

The trap here is that candidates assume the Cool tier is always cheaper than Hot for the first 30 days, but Cool's higher read costs and 30-day minimum charge make Hot more cost-effective for frequent access, and Archive's retrieval latency makes it unsuitable for monthly access.

How to eliminate wrong answers

Option B is wrong because moving directly from Hot to Archive after 30 days ignores the monthly access requirement during the next 11 months; Archive tier has a retrieval latency of up to 15 hours and is not suitable for monthly access. Option C is wrong because starting with Cool for the first 30 days incurs higher cost than Hot for that period (Cool has a higher per-GB read cost and a minimum 30-day storage charge, making it more expensive for frequent access). Option D is wrong because keeping data in Hot for 365 days wastes cost for the 11 months of rare access (Cool is cheaper for monthly access) and then moving to Archive after a year is unnecessary for the first year's access pattern.

Practice this question →
15
MCQhard

Your company uses Azure Cosmos DB with the Core (SQL) API. A collection contains millions of documents, and queries often filter by a property that is not the partition key. What should you do to improve query performance?

A.Create a composite index on the filtered property
B.Increase the provisioned throughput (RU/s)
C.Enable analytical store
D.Change the partition key to the filtered property
AnswerA

Composite indexes can speed up queries on non-partition key properties, but cross-partition queries may still be needed.

Why this answer

Creating a composite index on the filtered property can improve query performance by avoiding cross-partition scans. However, if the property is not the partition key, queries may still need to fan out across partitions. Changing the partition key would require data migration.

Increasing RU/s improves throughput but does not directly address the indexing issue. Enabling analytical store is for analytical queries, not operational.

Practice this question →
16
MCQmedium

A company stores IoT sensor data in Azure Blob Storage. The data is structured as JSON files organized by date. Data scientists need to query this data using SQL statements without moving it. Which Azure service should they use to enable this?

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

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

Why this answer

Azure Synapse Serverless SQL can query JSON files in Blob Storage directly using T-SQL. Option A (Azure Cosmos DB) is for NoSQL data; Option C (Azure SQL Database) is a relational database; Option D (Azure Data Lake Storage Gen2) is a storage layer, not a query service.

Practice this question →
17
MCQhard

A global e-commerce company uses Azure Cosmos DB for its product catalog. The database is replicated across multiple regions. During a regional outage, customers in the affected region report that they cannot update product prices. The application team confirms that read requests succeed. What is the most likely cause of this issue?

A.The Cosmos DB account is configured with a single write region and automatic failover is not enabled.
B.The application is using the wrong connection string for the region.
C.The consistency level is set to eventual, causing write conflicts.
D.The account is using read-only replicas in the affected region.
AnswerA

Writes only succeed in the primary write region.

Why this answer

In a multi-region write configuration, Cosmos DB can handle writes in any region. However, if the account is configured with a single write region, only that region can accept writes. During an outage of the write region, writes fail.

Option A is wrong because read replicas are for read-only scenarios. Option B is wrong because consistency level does not affect write availability. Option D is wrong because failover is automatic if configured.

Practice this question →
18
MCQmedium

A global social media startup stores user profiles as JSON documents in Azure Cosmos DB. Their application frequently reads profiles by user ID and also runs queries to find users based on location or interests. The workload is read-heavy with high throughput requirements. The operations team notices that query performance degrades during peak hours. Which action would most effectively improve query performance?

A.Increase the number of containers
B.Choose a different API (e.g., switch from SQL API to MongoDB API)
C.Increase the provisioned throughput (RU/s)
D.Switch to a different Azure region
AnswerC

Correct. Provisioned throughput is the key resource controlling the number of operations per second. Increasing RU/s provides more computational power for queries.

Why this answer

Increasing the provisioned throughput (RU/s) directly allocates more processing capacity to the Cosmos DB container, allowing it to handle higher request volumes and reduce throttling during peak hours. Since the workload is read-heavy and query performance degrades under high throughput demands, raising RU/s is the most effective and immediate action to improve performance.

Exam trap

The trap here is that candidates may confuse throughput (RU/s) with other scaling mechanisms like partitioning or API choice, but the core issue in a read-heavy, high-throughput scenario is insufficient provisioned capacity, not data organization or protocol differences.

How to eliminate wrong answers

Option A is wrong because increasing the number of containers does not improve query performance for existing data; it only helps with data partitioning or isolation, and can actually increase cost without addressing throughput limits. Option B is wrong because switching the API (e.g., from SQL API to MongoDB API) does not change the underlying throughput or query engine; it only changes the wire protocol and query syntax, and performance degradation is a capacity issue, not an API compatibility issue. Option D is wrong because switching to a different Azure region addresses latency or geo-replication needs, not the throughput or throttling issues that cause performance degradation during peak hours.

Practice this question →
19
MCQhard

A company stores large archives of legal documents in Azure Blob Storage. The documents must remain immutable; they cannot be modified or deleted for 7 years due to regulatory requirements. The data is accessed only for compliance audits, which occur less than once a year. The company wants to minimize storage costs while ensuring immutability and data durability. Which combination of features should they configure?

A.Cool access tier with a time-based retention policy
B.Archive access tier with a time-based retention policy
C.Hot access tier with versioning enabled
D.Archive access tier with legal hold
AnswerB

The Archive tier is the lowest cost storage tier for rarely accessed data. Combined with a time-based retention policy, it enforces immutability for 7 years while minimizing costs.

Why this answer

The Archive access tier provides the lowest storage cost for data that is rarely accessed, such as legal documents accessed less than once a year. A time-based retention policy enforces immutability for a fixed 7-year period, preventing modifications or deletions. This combination meets regulatory requirements while minimizing storage costs.

Exam trap

The trap here is that candidates may confuse 'legal hold' (which is indefinite and manually managed) with 'time-based retention policy' (which automatically expires after a set duration), leading them to incorrectly choose the Archive tier with legal hold instead of the correct time-based retention policy.

How to eliminate wrong answers

Option A is wrong because the Cool access tier has higher storage costs than the Archive tier, and the data is accessed less than once a year, making Cool suboptimal for cost minimization. Option C is wrong because versioning alone does not enforce immutability; it allows deletion of versions or overwriting of data, and the Hot tier is the most expensive, contradicting the cost minimization goal. Option D is wrong because a legal hold does not automatically expire after 7 years; it requires manual removal and is intended for indefinite holds, not fixed-duration retention.

Practice this question →
20
MCQmedium

A company develops an IoT device registry that stores device metadata as JSON documents. Each device has a unique DeviceID, and the attributes vary per device type (e.g., sensors, actuators). The application requires low-latency reads by DeviceID and needs global distribution to support devices worldwide. Which Azure Cosmos DB API should they choose to natively support JSON documents with flexible schema?

A.Azure Cosmos DB SQL API
B.Azure Cosmos DB Table API
C.Azure Cosmos DB for MongoDB API
D.Azure Cosmos DB Gremlin API
AnswerA

The SQL API is the native JSON document API for Cosmos DB, offering rich querying and global distribution with low-latency point reads by ID.

Why this answer

The Azure Cosmos DB SQL API (formerly DocumentDB) is the correct choice because it provides native support for storing and querying JSON documents with flexible schema, allowing each device document to have a unique DeviceID and varying attributes per device type. It offers low-latency reads by DeviceID via direct point reads using the partition key, and supports global distribution through multi-region writes and automatic replication, meeting the worldwide deployment requirement.

Exam trap

The trap here is that candidates often choose the MongoDB API because they associate JSON with MongoDB, but the SQL API is the native JSON document API in Cosmos DB and is the correct answer for 'natively support JSON documents with flexible schema' in the context of Azure Cosmos DB.

How to eliminate wrong answers

Option B (Azure Cosmos DB Table API) is wrong because it is designed for key-value and tabular data with a fixed schema, not for flexible JSON documents with varying attributes per device type. Option C (Azure Cosmos DB for MongoDB API) is wrong because while it supports JSON-like documents via BSON, it is a wire-protocol compatibility layer for MongoDB drivers and does not provide the native SQL query capabilities or the same optimized point-read performance for DeviceID as the SQL API; the question specifically asks for an API that natively supports JSON documents with flexible schema, which the SQL API does directly. Option D (Azure Cosmos DB Gremlin API) is wrong because it is built for graph data models and traversals using the Gremlin query language, not for document storage or key-based lookups.

Practice this question →
21
MCQeasy

A company archives legal documents that must be kept for 10 years. Access to these documents is extremely rare (maybe once a year). They want to minimize storage costs. Which Azure Blob Storage access tier is most cost-effective for this data?

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

Correct. Archive tier offers the lowest storage cost for data that is rarely accessed and for which retrieval latency (hours) is acceptable.

Why this answer

The Archive tier is the most cost-effective for data that is accessed less than once a year and must be retained for a long period (10 years). It offers the lowest storage cost per GB among all Azure Blob Storage access tiers, but has the highest access and data retrieval costs, making it ideal for rarely accessed, long-term archival data like legal documents.

Exam trap

The trap here is that candidates often choose the Cool or Cold tier because they think 'infrequent' or 'rare' access matches those tiers, but they overlook the Archive tier's significantly lower storage cost for data that is accessed less than once a year and has a long retention period.

How to eliminate wrong answers

Option A is wrong because the Hot tier is optimized for frequent access (multiple times per day) and has the highest storage cost, making it prohibitively expensive for data accessed only once a year. Option B is wrong because the Cool tier is designed for data accessed infrequently (about once a month) and has higher storage costs than Archive, with a 30-day minimum storage charge that is unnecessary for this use case. Option C is wrong because the Cold tier is intended for data accessed rarely (about once every 90 days) and still incurs higher storage costs than Archive, with a 90-day minimum storage charge that does not align with the once-a-year access pattern.

Practice this question →
22
Multi-Selecthard

Which THREE are benefits of using Azure Cosmos DB? (Choose three.)

Select 3 answers
A.Automatically indexes all data.
B.Supports SQL Server integration.
C.Guarantees low-latency reads and writes at the 99th percentile.
D.Provides unlimited storage capacity.
E.Requires a fixed schema for all documents.
AnswersA, C, D

Auto-indexing is a key feature.

Why this answer

Cosmos DB offers guaranteed low-latency reads/writes, automatic indexing, and global distribution. Option A is wrong because Cosmos DB is a NoSQL database. Option D is wrong because Cosmos DB does not require a schema.

Option E is wrong because storage is not unlimited; there are limits per container.

Practice this question →
23
Multi-Selectmedium

Which TWO of the following are valid use cases for Azure Queue Storage?

Select 2 answers
A.Building a serverless workflow with Azure Functions
B.Storing JSON documents for querying
C.Storing large binary objects for a website
D.Decoupling front-end and back-end components in a web application
E.Real-time event streaming for analytics
AnswersA, D

Queue Storage can trigger Azure Functions for serverless workflows.

Why this answer

Azure Queue Storage is used for asynchronous message passing between application components. Option B is correct for decoupling application layers. Option E is correct for building serverless workflows with Azure Functions.

Option A is wrong because queue storage is not for storing large binary objects (use Blob Storage). Option C is wrong because queue storage is not for real-time streaming (use Event Hubs). Option D is wrong because queue storage is not for storing JSON documents for query (use Cosmos DB).

Practice this question →
24
MCQmedium

A smart city application collects sensor data from thousands of devices. Data is ingested as JSON messages containing deviceId, timestamp, and reading value. The application must support fast point reads by deviceId and also run queries to retrieve all readings for a specific deviceId within a time range. The development team prefers a SQL-like query language. Which Azure Cosmos DB API should they choose?

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

Correct. SQL API offers SQL-like query syntax, fast point reads, and works directly with JSON documents.

Why this answer

The SQL (Core) API is the best choice because it natively supports SQL-like querying, enabling both fast point reads by deviceId (using the partition key) and efficient time-range queries on a specific deviceId. It also provides native JSON support, which aligns with the JSON message format from the sensors, and allows indexing on timestamp for range queries.

Exam trap

Microsoft often tests the misconception that any API with a SQL-like name (like Cassandra's CQL) is equivalent to the SQL (Core) API, but the key differentiator is native JSON support and the specific query language syntax preferred by the team.

How to eliminate wrong answers

Option B (Table API) is wrong because it uses a key-value store with OData query syntax, not SQL-like queries, and lacks native support for complex range queries on timestamps within a partition. Option C (MongoDB API) is wrong because it uses MongoDB's query language (based on BSON and JSON-like documents), not SQL, and while it supports range queries, the team specifically prefers SQL-like syntax. Option D (Cassandra API) is wrong because it uses CQL (Cassandra Query Language), which is SQL-like but designed for wide-column stores and does not natively support efficient time-range queries on a single partition key without additional modeling (e.g., using clustering columns), and it lacks native JSON support for the ingested messages.

Practice this question →
25
MCQmedium

A mobile gaming company stores player profiles in Azure Cosmos DB. Each profile document contains many optional fields, and queries frequently filter by the player's locale (a field present in about 30% of documents). Which approach will optimize query performance for these filters?

A.Embed all fields in a single document and rely on automatic indexing
B.Normalize the data by storing locale in a separate container and use cross-container queries
C.Define a fixed schema for all documents to ensure every document has the locale field
D.Create a composite index that includes the locale field
AnswerD

A composite index on the locale field (and optionally including other fields) allows the query engine to quickly locate matching documents, reducing RU consumption and improving response time.

Why this answer

Option D is correct because creating a composite index that includes the locale field allows Azure Cosmos DB to efficiently filter queries by locale without scanning every document. Since locale is present in only 30% of documents, a composite index reduces the query RU cost by directly locating matching documents, leveraging the index's sorted structure for faster lookups.

Exam trap

The trap here is that candidates assume automatic indexing is sufficient for all queries, but they overlook that sparsely populated fields benefit from explicit composite indexing to avoid high RU costs from index scans.

How to eliminate wrong answers

Option A is wrong because embedding all fields in a single document with automatic indexing does not optimize queries for a sparsely present field like locale; automatic indexing still requires a full index scan for the field, leading to higher RU consumption. Option B is wrong because normalizing locale into a separate container and using cross-container queries introduces additional latency and RU cost due to cross-partition queries, and Cosmos DB does not support efficient cross-container joins. Option C is wrong because defining a fixed schema to force the locale field on all documents increases storage and write RU costs unnecessarily, and does not improve query performance without an appropriate index on the field.

Practice this question →
26
MCQeasy

You need to choose a non-relational data store for a key-value workload where each item is identified by a partition key and row key. Which Azure service should you use?

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

Table Storage is designed for key-value with partition and row keys.

Why this answer

Azure Table Storage is a key-value store that uses partition key and row key. Option A is wrong because Cosmos DB can also do key-value but Table Storage is simpler. Option C is wrong because Blob Storage is for blobs.

Option D is wrong because Files is for file shares.

Practice this question →
27
MCQhard

A company uses Azure Cosmos DB for a global e-commerce application. The application needs to support multi-region writes and provide strong consistency for inventory updates. Which configuration minimizes write latency while meeting the consistency requirement?

A.Multi-master with bounded staleness consistency
B.Single-region writes with session consistency
C.Single-region writes with strong consistency
D.Multi-master with eventual consistency
AnswerC

Strong consistency is supported only with single-region writes; multi-region writes cannot achieve strong consistency.

Why this answer

Multi-region writes with strong consistency is not supported in Cosmos DB. To minimize write latency with strong consistency, use single-region writes with strong consistency. Option A (multi-master with bounded staleness) does not provide strong consistency; Option C (multi-master with eventual consistency) is weaker; Option D (single-region with session consistency) is not strong.

Practice this question →
28
Multi-Selecteasy

Which TWO of the following Azure services are considered non-relational data stores?

Select 2 answers
A.Azure SQL Database
B.Azure Cosmos DB
C.Azure Table Storage
D.Azure Synapse Analytics
E.Azure Database for PostgreSQL
AnswersB, C

Azure Cosmos DB is a NoSQL database.

Why this answer

Options A and C are correct. Azure Cosmos DB is a NoSQL database (A), and Azure Table Storage is a key-value store (C). Option B is wrong because Azure SQL Database is relational.

Option D is wrong because Azure Database for PostgreSQL is relational. Option E is wrong because Azure Synapse Analytics is a relational analytics system.

Practice this question →
29
MCQmedium

A media publishing company stores high-resolution images and video files for their website. These files are large (hundreds of MBs each) and are accessed only a few times per month, but when accessed, they must be delivered within seconds. Additionally, they need to store a small amount of metadata (e.g., upload date, author) for each file. Which Azure service should they use for storing the binary files?

A.Azure Table Storage
B.Azure Blob Storage
C.Azure File Storage
D.Azure Queue Storage
AnswerB

Azure Blob Storage is optimized for large unstructured binary objects and supports custom metadata.

Why this answer

Azure Blob Storage is designed for storing massive amounts of unstructured binary data, such as high-resolution images and video files. It supports objects up to 4.75 TB in size, offers tiered storage (including cool and archive tiers) to optimize cost for infrequently accessed data, and provides low-latency access (typically under 10 seconds) for retrieval when needed. This makes it the ideal choice for the media publishing company's requirements.

Exam trap

The trap here is that candidates confuse Azure Table Storage (for metadata) with the primary storage for binary files, or they assume Azure File Storage (SMB shares) is suitable for web-serving large media files, when in fact Blob Storage is the correct service for unstructured binary data with infrequent access patterns.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a NoSQL key-value store for structured, non-relational data (e.g., metadata), not for large binary files like images or videos. Option C is wrong because Azure File Storage provides SMB file shares for shared file access across VMs or on-premises, but it is not optimized for storing and serving large, infrequently accessed binary files with blob-tier cost savings. Option D is wrong because Azure Queue Storage is a messaging service for asynchronous communication between application components, not a storage solution for binary files.

Practice this question →
30
MCQeasy

A mobile game developer needs to store player session data. Each session has a unique SessionID, a UserID, a start timestamp, an end timestamp, and a collection of game events (each event is a JSON object). The application requires low-latency point reads by SessionID and the ability to query all sessions for a given UserID within a time range. The schema of game events can vary between sessions (e.g., new event types added frequently). The developer wants a fully managed NoSQL database that supports flexible schemas and secondary indexing. 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 Cache for Redis
AnswerA

Cosmos DB provides document storage with flexible schema, indexing, and low-latency reads. It supports secondary indexes on arbitrary fields like UserID and timestamp.

Why this answer

Azure Cosmos DB with the NoSQL API is the correct choice because it provides a fully managed, globally distributed NoSQL database with native support for flexible schemas (schemaless JSON documents), low-latency point reads by partition key (SessionID), and automatic secondary indexing for querying by UserID within a time range. Its ability to handle varying game event schemas without schema migrations makes it ideal for this use case.

Exam trap

The trap here is that candidates often confuse Azure Table Storage with a fully queryable NoSQL database, but it lacks secondary indexing and complex query support, making it unsuitable for time-range queries on non-key fields.

How to eliminate wrong answers

Option B (Azure Table Storage) is wrong because it is a key-value store with limited querying capabilities (only on PartitionKey and RowKey) and does not support secondary indexing or complex queries like time-range filtering on non-key attributes. Option C (Azure Blob Storage) is wrong because it is an object storage service designed for unstructured data (blobs), not for low-latency point reads or indexed queries on individual records; it lacks native querying and indexing for session data. Option D (Azure Cache for Redis) is wrong because it is an in-memory cache, not a durable database; it does not provide persistent storage, secondary indexing, or the ability to query by UserID across sessions over time.

Practice this question →
31
MCQmedium

A media company stores video files in Azure Blob Storage. They want to use Azure Content Delivery Network (CDN) to serve these videos globally. However, they need to restrict access to only authorized users. What should you implement?

A.Set the blob container to public access.
B.Use Azure Active Directory (Microsoft Entra ID) authentication for the CDN endpoint.
C.Implement shared access signatures (SAS) and token-based authentication on the CDN.
D.Use a firewall on the storage account to allow only CDN IP addresses.
AnswerC

SAS tokens or CDN token authentication can restrict access to authorized users.

Why this answer

Azure CDN with token authentication (using shared access signatures or custom tokens) can restrict access to authorized users. Option A is wrong because public access would allow anyone. Option B is wrong because network restrictions don't work well for global users.

Option C is wrong because Azure AD authentication is not directly supported by CDN for blob access; token auth is the standard approach.

Practice this question →
32
MCQmedium

A gaming company stores player profiles in Azure Cosmos DB using the NoSQL API. Each profile is a JSON document containing fields like playerId, userName, level, inventory (an array of items), and friends (an array of playerIds). The application frequently needs to query all players that have a specific item in their inventory (e.g., 'sword'). Which Cosmos DB feature should they use to support this query efficiently?

A.Change feed
B.Stored procedures
C.Composite index
D.Indexing policy with a wildcard index
AnswerD

A wildcard index ensures all paths (including arrays) are indexed, allowing efficient use of ARRAY_CONTAINS queries.

Why this answer

Option D is correct because a wildcard index in the indexing policy allows Azure Cosmos DB to automatically index all properties within a JSON document, including nested array elements like those in the 'inventory' array. This enables efficient queries such as 'SELECT * FROM c WHERE ARRAY_CONTAINS(c.inventory, {name: "sword"})' without requiring a custom composite index for each possible item. Without a wildcard index, the query would require a full scan of all documents, which is inefficient at scale.

Exam trap

The trap here is that candidates often confuse indexing features, thinking a composite index (Option C) is needed for array queries, when in fact composite indexes are for multi-property equality or range filters, not for array membership queries which require a wildcard index to index the array elements themselves.

How to eliminate wrong answers

Option A is wrong because the change feed is a mechanism for capturing document inserts, updates, and deletes in chronological order, not for querying current data based on array contents. Option B is wrong because stored procedures are server-side JavaScript logic for transactional operations, not a query optimization feature for indexing array elements. Option C is wrong because a composite index is designed to optimize queries with multiple filter conditions (e.g., WHERE level = 10 AND userName = 'Alice'), not for queries that filter on array membership like 'inventory contains item X'.

Practice this question →
33
MCQmedium

A social networking application stores user profiles as JSON documents in Azure Cosmos DB. Each profile includes fields such as 'userName', 'email', 'followersCount', and optional 'interests'. The application needs to perform fast point reads by 'userName' (under 10 ms) and also run queries to find all users with a 'followersCount' greater than a certain value. The development team prefers to use a query syntax similar to SQL. Which Azure Cosmos DB API should they choose?

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

Correct. The SQL API provides a SQL-like query interface for JSON documents, supporting point reads by partition key and flexible queries on any field.

Why this answer

Azure Cosmos DB for NoSQL (SQL API) is the correct choice because it natively supports SQL-like query syntax for querying JSON documents, enabling the required queries such as filtering by 'followersCount'. It also provides fast point reads (under 10 ms) by using the 'userName' field as the partition key, ensuring efficient direct access to individual documents.

Exam trap

The trap here is that candidates may confuse the SQL-like syntax of Cassandra's CQL with the native SQL API, overlooking that Cassandra is a wide-column store not optimized for JSON document queries, while the SQL API is purpose-built for JSON documents and SQL queries.

How to eliminate wrong answers

Option B is wrong because Azure Cosmos DB for MongoDB uses MongoDB's query language (based on BSON and MongoDB operators), not SQL-like syntax, and would require the team to adapt to a different query paradigm. Option C is wrong because Azure Cosmos DB for Table is designed for key-value and tabular data with OData-based queries, not for querying nested JSON documents with SQL-like syntax. Option D is wrong because Azure Cosmos DB for Apache Cassandra uses CQL (Cassandra Query Language), which is similar to SQL but is optimized for wide-column stores and does not natively support querying JSON documents with the same flexibility as the SQL API.

Practice this question →
34
MCQmedium

A social networking application needs to store and query relationships between users, such as 'friends of friends' to recommend new connections. The application must traverse these relationships efficiently. Which Azure NoSQL data store and API should they choose?

A.Azure Cosmos DB with MongoDB API
B.Azure Cosmos DB with Gremlin API
C.Azure Table Storage
D.Azure Cosmos DB with SQL API
AnswerB

Correct. The Gremlin API is designed for graph data models and supports traversal queries using the Gremlin graph query language.

Why this answer

Azure Cosmos DB with Gremlin API is correct because it provides a graph database model specifically designed for storing and querying highly connected data, such as user relationships. The Gremlin API supports graph traversal queries (e.g., 'friends of friends') natively using the Apache TinkerPop graph traversal language, enabling efficient navigation of edges and vertices without expensive join operations.

Exam trap

The trap here is that candidates often confuse document databases (like MongoDB API or SQL API) with graph databases, assuming any NoSQL store can handle relationships efficiently, but only a dedicated graph database like Gremlin API provides native traversal operators for multi-hop queries.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB with MongoDB API is a document-oriented store that lacks native graph traversal capabilities; modeling 'friends of friends' would require multiple queries or application-level joins, which is inefficient. Option C is wrong because Azure Table Storage is a key-value store with no support for relationships or graph traversal; it cannot efficiently query multi-hop connections like 'friends of friends'. Option D is wrong because Azure Cosmos DB with SQL API is a document store using SQL-like queries, which does not provide native graph traversal operators; traversing relationships would require recursive queries or client-side logic, leading to poor performance.

Practice this question →
35
MCQmedium

A mobile gaming company stores player activity logs as JSON documents. Each document has a unique ActivityID, a PlayerID, a timestamp, and a variable set of attributes depending on the game event (e.g., level started, item purchased). The application requires low-latency point reads by ActivityID and needs to query logs by PlayerID for a given time range. Schema flexibility is critical because new game events are added frequently. Which Azure Cosmos DB API should they choose?

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

Correct. The NoSQL API provides native JSON support, flexible schema, automatic indexing, and SQL-like querying for efficient point reads and range queries.

Why this answer

The NoSQL API (formerly SQL API) is the correct choice because it natively supports JSON documents with flexible schemas, enabling the variable attributes required for new game events. It provides low-latency point reads by ActivityID via direct partition key lookups and supports efficient queries by PlayerID within a time range using composite indexes or cross-partition queries with filtering. This API is optimized for schema-agnostic, document-based workloads and offers the richest query capabilities for JSON data in Azure Cosmos DB.

Exam trap

The trap here is that candidates often choose the MongoDB API assuming it is the only option for JSON documents, but they overlook that the NoSQL API provides superior query flexibility and indexing for time-range queries, and that all Cosmos DB APIs support JSON documents but with different query capabilities.

How to eliminate wrong answers

Option B (MongoDB API) is wrong because while it supports JSON-like documents with flexible schemas, its query language is limited to MongoDB's aggregation pipeline and does not natively support the same level of SQL-like querying for time-range filtering across partitions without additional indexing complexity; the NoSQL API provides more straightforward querying for this use case. Option C (Cassandra API) is wrong because it uses a wide-column store model with a fixed schema defined by CQL tables, which cannot accommodate the variable set of attributes in JSON documents without schema changes, and it lacks native support for JSON document storage and querying. Option D (Gremlin API) is wrong because it is designed for graph data models and traversals, not for document storage or point reads by ActivityID, and it cannot efficiently handle the flexible schema and time-range queries required for player activity logs.

Practice this question →
36
MCQhard

You are designing a solution to store and analyze large volumes of streaming data from social media feeds. The data is semi-structured (JSON) and will be used for real-time dashboards. You need to choose a storage solution that can handle high-ingestion throughput and support querying with Azure Synapse Serverless SQL. Which storage option should you choose?

A.Azure Table Storage
B.Azure Data Lake Storage Gen2
C.Azure Cosmos DB
D.Azure Cache for Redis
AnswerB

Optimized for big data analytics and compatible with Synapse Serverless SQL.

Why this answer

Option A is correct because Azure Data Lake Storage Gen2 (ADLS Gen2) is built on Blob Storage, supports high-throughput ingestion, and can be queried by Azure Synapse Serverless SQL. Option B is wrong because Azure Cosmos DB is optimized for transactional workloads, not analytical queries with Synapse Serverless SQL directly (though Synapse Link exists). Option C is wrong because Azure Table Storage is not designed for analytics.

Option D is wrong because Azure Cache for Redis is an in-memory cache.

Practice this question →
37
MCQmedium

A mobile gaming company stores player data in Azure Cosmos DB using the Core (SQL) API. Each document contains fields: playerId, nickname, score, level, and an inventory array of item objects (each with name and type). The company wants to query all players whose score is above 5000 and who have a specific item (e.g., a sword) in their inventory. Which query clause should they use?

A.A) WHERE c.score > 5000 AND c.inventory.some(item => item.name == 'sword')
B.B) WHERE c.score > 5000 AND ARRAY_CONTAINS(c.inventory, {name: 'sword'}, true)
C.C) WHERE c.score > 5000 AND c.inventory.name == 'sword'
D.D) WHERE c.score > 5000 AND 'sword' IN c.inventory
AnswerB

ARRAY_CONTAINS checks if the array contains an object that matches the specified properties. The third parameter 'true' enables partial matching, so it finds items where name equals 'sword' regardless of other fields.

Why this answer

Option B is correct because ARRAY_CONTAINS with the third parameter set to 'true' performs a partial match, checking if any element in the inventory array has a 'name' property equal to 'sword'. This is the standard way to query for an item within an array of objects in Azure Cosmos DB's SQL API, as it correctly handles the nested structure without requiring a JOIN or subquery.

Exam trap

The trap here is that candidates often confuse SQL array syntax (like IN or direct property access) with the specialized ARRAY_CONTAINS function required for querying arrays of objects in Cosmos DB, or they mistakenly apply JavaScript array methods that are not supported in the SQL API.

How to eliminate wrong answers

Option A is wrong because 'c.inventory.some(item => item.name == 'sword')' uses JavaScript-like syntax that is not valid in Azure Cosmos DB SQL API queries; the SQL API does not support arrow functions or the .some() method. Option C is wrong because 'c.inventory.name == 'sword'' assumes that 'name' is a direct property of the array, but arrays do not have a 'name' property; this would either return undefined or cause a query error. Option D is wrong because ''sword' IN c.inventory' checks if the string 'sword' is an exact element of the array, but the inventory array contains objects, not strings, so this condition will never be true.

Practice this question →
38
MCQhard

A company stores user profile data in Azure Blob Storage as JSON files. Each file represents one user. They need to provide real-time search capabilities on user attributes like name, email, and location. The search must support partial matches and return results within 500 ms. The data volume is 10 TB and grows by 1 GB daily. They have a limited budget and want to minimize operational overhead. Which Azure solution should they choose?

A.Import the JSON files into Azure Cosmos DB and use the SQL API to search.
B.Use Azure Data Lake Analytics with U-SQL to query the files.
C.Use Azure Cognitive Search to index the JSON files and provide search capabilities.
D.Load the data into Azure SQL Database and create full-text indexes.
AnswerC

Cognitive Search is designed for full-text search, supports partial matches, and integrates with Blob Storage.

Why this answer

Azure Cognitive Search (option A) is a managed search service that indexes JSON data from Blob Storage and supports partial matches with low latency. Option B (Azure Cosmos DB) requires data migration and may not support partial match efficiently. Option C (Azure SQL Database) requires importing data and schema changes.

Option D (Azure Data Lake Analytics) is for batch processing, not real-time search.

Practice this question →
39
MCQmedium

A company stores user profiles as JSON documents. Each profile includes standard fields (userId, name, email) and optional fields (preferences, history). The application needs fast key lookups by userId and SQL-like queries on optional fields. Which Azure Cosmos DB API should they choose?

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

This API natively stores JSON documents, supports flexible schema, and allows SQL-like queries on any field, meeting both fast key lookups and ad-hoc query needs.

Why this answer

The SQL (Core) API is the correct choice because it natively supports JSON documents with flexible schemas, enabling fast key-value lookups on the `userId` field (via automatic indexing) and rich SQL-like querying (e.g., `SELECT * FROM c WHERE c.preferences.theme = 'dark'`) on optional fields. It is the only Azure Cosmos DB API that provides a SQL query syntax directly over JSON, making it ideal for mixed workloads of point reads and ad-hoc queries on nested or optional properties.

Exam trap

The trap here is that candidates confuse the MongoDB API's support for JSON documents with the ability to run SQL queries, when in fact MongoDB uses its own query language and does not support SQL syntax, leading them to incorrectly choose MongoDB over the SQL (Core) API.

How to eliminate wrong answers

Option B (MongoDB API) is wrong because, while it supports JSON-like documents and key lookups, its query language is MongoDB's query syntax (e.g., `find({preferences: {theme: 'dark'}})`) rather than SQL-like queries, and it does not offer native SQL syntax for the described requirement. Option C (Cassandra API) is wrong because it uses the Cassandra Query Language (CQL) and a wide-column storage model, which is not optimized for JSON documents with optional fields or SQL-like queries on nested properties. Option D (Table API) is wrong because it is designed for key-attribute store with a flat schema, not for JSON documents with nested optional fields, and its query capabilities are limited to OData filters and partition key lookups, not SQL-like queries on arbitrary JSON paths.

Practice this question →
40
Multi-Selectmedium

Which TWO scenarios are appropriate for using Azure Blob Storage? (Choose two.)

Select 2 answers
A.Storing key-value pairs with partition and row keys.
B.Running SQL queries on structured data.
C.Storing JavaScript functions for server-side logic.
D.Storing backup files and archival data.
E.Storing images and videos for a website.
AnswersD, E

Blob Storage is commonly used for backups and archives.

Why this answer

Azure Blob Storage is designed for storing large amounts of unstructured data, such as binary files and text. Backup files and archival data are ideal use cases because Blob Storage supports hot, cool, and cold access tiers optimized for long-term retention and cost-effective storage. Additionally, storing images and videos for a website leverages Blob Storage's ability to serve static assets directly via HTTP/HTTPS, with built-in CDN integration for fast global delivery.

Exam trap

The trap here is that candidates confuse Azure Blob Storage with other Azure services that handle structured data (like Table Storage or SQL Database) or compute (like Azure Functions), leading them to select options that describe those services instead of focusing on unstructured data storage scenarios.

Practice this question →
41
MCQhard

A retail company uses Azure Cosmos DB to store product catalog data. They experience high request unit (RU) consumption during peak hours, leading to throttling. Which action should they take to reduce RU consumption without changing the application code?

A.Switch to the Cassandra API
B.Create a composite index on frequently queried fields
C.Enable the Azure Cosmos DB integrated cache
D.Increase the provisioned RU/s
AnswerC

The integrated cache serves repeated queries without consuming RU.

Why this answer

Option D is correct because enabling Cosmos DB caching (Azure Cosmos DB integrated cache) reduces RU consumption by serving repeated queries from cache. Option A is wrong because increasing RU/s would raise costs and not reduce consumption. Option B is wrong because creating a secondary index would increase RU consumption for writes.

Option C is wrong because switching to Cassandra API may not reduce RU consumption.

Practice this question →
42
Multi-Selecthard

A company uses Azure Cosmos DB with the SQL API. They need to implement a data partitioning strategy to optimize query performance and avoid hot partitions. Which THREE practices should they follow?

Select 3 answers
A.Use the same partition key for all items
B.Use a synthetic partition key if natural keys are not suitable
C.Avoid monotonically increasing partition key values
D.Keep partition key values as small as possible
E.Choose a partition key with high cardinality
AnswersB, C, E

Synthetic keys can improve distribution when natural keys have low cardinality.

Why this answer

Choosing a high-cardinality partition key (option A) distributes data evenly. Using a synthetic partition key (option C) can combine multiple attributes for better distribution. Avoiding monotonically increasing keys (option D) prevents hot partitions.

Option B (using the same partition key for all items) is incorrect for large datasets. Option E (keeping partition key values very small) is not a primary consideration.

Practice this question →
43
Multi-Selecteasy

A company is choosing a non-relational data store for a new application that requires flexible schema, high availability, and low latency across multiple geographic regions. Which TWO Azure services meet these requirements?

Select 2 answers
A.Azure Files
B.Azure SQL Database
C.Azure Cache for Redis
D.Azure Cosmos DB
E.Azure Table Storage
AnswersD, E

Supports multi-region writes, flexible schema, and low latency.

Why this answer

Azure Cosmos DB (option A) offers multi-region replication, flexible schema, and low latency. Azure Table Storage (option D) is a NoSQL key-value store with global replication (read-access geo-redundant storage) and low latency. Option B (Azure SQL Database) is relational.

Option C (Azure Files) is file storage. Option E (Azure Cache for Redis) is an in-memory cache, not a primary data store.

Practice this question →
44
MCQhard

A hospital stores medical images in Azure Blob Storage. They must ensure that images are encrypted at rest using customer-managed keys (CMK) and that access to the keys is audited. What should you implement?

A.Use Azure Disk Encryption to encrypt the storage account.
B.Apply Azure Information Protection labels to the blobs.
C.Enable Azure Storage Service Encryption with a customer-managed key in Azure Key Vault.
D.Use Transparent Data Encryption (TDE) on the storage account.
AnswerC

This provides encryption at rest with CMK and allows auditing via Key Vault logs.

Why this answer

Azure Storage encryption with customer-managed keys stored in Azure Key Vault provides the required control and auditing. Option B is wrong because Azure Disk Encryption is for VMs, not Blob Storage. Option C is wrong because Azure Information Protection is for classification, not encryption at rest.

Option D is wrong because Azure SQL Database TDE is for SQL databases.

Practice this question →
45
MCQmedium

A real-time leaderboard for an online game needs to store player scores and quickly retrieve the top 100 players. The data must update frequently as players achieve new scores, and the application requires sub-millisecond read and write latency. Which Azure data store is best suited for this requirement?

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

Azure Cache for Redis provides in-memory data structures including sorted sets, enabling high-performance leaderboard operations with sub-millisecond latency. It is purpose-built for such real-time scenarios.

Why this answer

Azure Cache for Redis is an in-memory data store that provides sub-millisecond read and write latency, making it ideal for real-time leaderboards that require frequent updates and fast retrieval of top scores. Its sorted set data structure (ZADD/ZRANGEBYSCORE) allows efficient insertion of player scores and O(log N) retrieval of the top 100 players without disk I/O overhead.

Exam trap

Microsoft often tests the misconception that any low-latency NoSQL store (like Cosmos DB) can match Redis for sub-millisecond, in-memory operations, but the key differentiator is Redis's exclusive sorted set data structure and its dedicated in-memory architecture.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB Core (SQL) API, while fast, typically has single-digit millisecond latencies and is not optimized for the sub-millisecond, in-memory throughput required for real-time leaderboard updates. Option B is wrong because Azure Table Storage is a key-value store with higher latency (10-50 ms) and lacks native sorted set operations, making it unsuitable for frequent score updates and top-N queries. Option D is wrong because Azure Blob Storage is designed for large, unstructured data with high latency (100+ ms) and no support for real-time atomic score updates or ranking queries.

Practice this question →
46
MCQeasy

A mobile gaming startup needs to store player profiles that can have varying attributes (e.g., some players have a 'nickname', others have 'avatar URL'). The application must read a player's profile by PlayerID with very low latency (under 10 ms) from any location worldwide. The data does not require complex queries or joins. Which Azure data store should they choose?

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

Azure Cosmos DB is a globally distributed NoSQL database that supports flexible schemas and offers low-latency reads (under 10 ms) at any scale. It is the best fit for this scenario.

Why this answer

Azure Cosmos DB is the correct choice because it is a globally distributed, multi-model database service that guarantees single-digit-millisecond read latencies (under 10 ms) at any scale from any Azure region. Its schema-agnostic nature allows storing player profiles with varying attributes (e.g., nickname, avatar URL) without requiring a fixed schema, and it supports point reads by PlayerID with a consistency model that can be tuned for performance. This directly matches the requirements of low-latency global reads and flexible, non-relational data.

Exam trap

The trap here is that candidates often confuse Azure Table Storage with Cosmos DB Table API, but the question specifies 'Azure Table Storage' (the older, standalone service) which lacks the global distribution and low-latency guarantees of Cosmos DB, leading them to incorrectly choose Option C.

How to eliminate wrong answers

Option A is wrong because Azure SQL Database is a relational database with a fixed schema, requiring predefined columns for attributes, which does not support varying attributes without complex schema changes or JSON columns that add overhead, and its global read latency is typically higher than 10 ms without additional geo-replication configurations. Option C is wrong because Azure Table Storage is a NoSQL key-value store that can handle varying attributes, but it does not guarantee single-digit-millisecond read latencies globally; its latency is higher (often 10-50 ms) and it lacks the built-in global distribution and low-latency SLAs of Cosmos DB. Option D is wrong because Azure Blob Storage is designed for unstructured binary or text data (e.g., files, images) and is not optimized for low-latency point reads of individual player profiles by ID; it typically has higher latency (tens to hundreds of milliseconds) and does not support querying by PlayerID natively without additional indexing or metadata layers.

Practice this question →
47
Multi-Selectmedium

Which TWO of the following are true about Azure Cosmos DB?

Select 2 answers
A.The default consistency level is Strong.
B.It uses DTUs to measure performance.
C.It guarantees single-digit millisecond latency for reads and writes at the 99th percentile.
D.It is a relational database management system.
E.It supports multiple data models including document, key-value, graph, and column-family.
AnswersC, E

Cosmos DB provides low-latency guarantees.

Why this answer

Azure Cosmos DB is a globally distributed, multi-model database. Option A is correct: it supports multiple APIs including SQL, MongoDB, Cassandra, etc. Option D is correct: it offers guaranteed single-digit millisecond latency at the 99th percentile.

Option B is wrong because Cosmos DB does not support the relational model natively; it uses non-relational models. Option C is wrong because Cosmos DB uses provisioned throughput (RU/s), not DTUs. Option E is wrong because the default consistency level is Session, not Strong.

Practice this question →
48
MCQhard

A global social media platform stores user profile images (JPEG) and activity logs in JSON format. The logs have varying structures based on the type of activity. The application requires low-latency reads of images from any region and the ability to query logs using SQL-like syntax. Which Azure data storage solution should they use for each data type?

A.Azure Table Storage for images and Azure Cosmos DB (Table API) for logs
B.Azure Blob Storage with a CDN for images and Azure Cosmos DB (SQL API) for logs
C.Azure Files for images and Azure SQL Database for logs
D.Azure Disk Storage for images and Azure Cosmos DB (MongoDB API) for logs
AnswerB

Blob Storage efficiently stores unstructured images, and CDN ensures low-latency global access. Cosmos DB SQL API provides SQL-like queries for the varying JSON logs.

Why this answer

Azure Blob Storage is optimized for storing large binary objects like JPEG images, and integrating it with Azure CDN ensures low-latency reads globally by caching content at edge nodes. Azure Cosmos DB with the SQL API provides native support for querying JSON documents with varying schemas using SQL-like syntax, making it ideal for the activity logs.

Exam trap

The trap here is that candidates may confuse Azure Table Storage (key-value) with Cosmos DB Table API, or assume Azure SQL Database can handle JSON logs via OPENJSON, but the question explicitly requires SQL-like syntax for varying structures, which Cosmos DB SQL API handles natively without schema enforcement.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a key-value store designed for structured data, not for large binary files like images, and it does not support SQL-like queries for JSON logs. Option C is wrong because Azure Files is a file share service for SMB protocols, not optimized for high-throughput image delivery with CDN, and Azure SQL Database is a relational store that requires a fixed schema, making it unsuitable for logs with varying structures. Option D is wrong because Azure Disk Storage provides block-level storage for VMs, not a globally distributed object store for images, and Cosmos DB with MongoDB API uses MongoDB query syntax, not SQL-like syntax.

Practice this question →
49
MCQhard

A social media startup stores user profile data, posts, and comments in Azure Cosmos DB. They notice that the logical partition size for a popular user's profile is growing beyond 20 GB, causing performance issues. The current partition key is 'userId'. Which action should they take to solve this?

A.Change the partition key to a synthetic key combining userId and postId
B.Increase the RU/s
C.Split the container into multiple containers by userId range
D.Use a different API like MongoDB
AnswerA

A synthetic key like 'userId_postId' ensures that each post gets its own logical partition, preventing any single partition from exceeding 20 GB.

Why this answer

A is correct because the logical partition size limit in Azure Cosmos DB is 20 GB. By using a synthetic partition key that combines 'userId' and 'postId', you distribute the data for the popular user across multiple logical partitions, preventing any single partition from exceeding the 20 GB limit and resolving the performance bottleneck.

Exam trap

The trap here is that candidates often confuse throughput (RU/s) scaling with storage limits, thinking that increasing RU/s will fix a partition size issue, when in fact the 20 GB logical partition limit is a hard storage constraint that requires partition key redesign.

How to eliminate wrong answers

Option B is wrong because increasing the RU/s only improves throughput (request rate) but does not solve the underlying issue of a single logical partition exceeding the 20 GB storage limit, which causes throttling and performance degradation. Option C is wrong because splitting the container by 'userId' range does not help; the problem is that one specific user's data is too large, and splitting by range would still place all that user's data in one partition. Option D is wrong because changing the API (e.g., to MongoDB) does not alter the Cosmos DB logical partition size limit of 20 GB; the same storage constraint applies regardless of the API used.

Practice this question →
50
MCQmedium

A gaming company stores player profiles as JSON documents. Each profile includes standard fields like playerId, username, and email, as well as optional fields such as achievements, gamePreferences, and friendsList. The application needs to look up profiles by playerId with low latency (under 10 ms) and also run SQL-like queries to find players who have a specific achievement. Which Azure Cosmos DB API should they choose?

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

The SQL API stores JSON documents and supports querying with a SQL dialect. Point reads by partition key (playerId) are low-latency, and SQL queries can easily filter on optional fields like achievements. This makes it the best choice.

Why this answer

The SQL (Core) API is the correct choice because it natively supports JSON documents with flexible schemas (including optional fields like achievements) and provides low-latency point reads by playerId (partition key) under 10 ms. It also enables SQL-like queries (e.g., SELECT * FROM c WHERE ARRAY_CONTAINS(c.achievements, 'specificAchievement')) to find players with a specific achievement, which aligns directly with the requirement.

Exam trap

The trap here is that candidates often choose the MongoDB API because it is associated with JSON documents, but they overlook the explicit requirement for SQL-like queries, which only the SQL (Core) API supports natively among the Azure Cosmos DB APIs.

How to eliminate wrong answers

Option A (Table API) is wrong because it is designed for key-value and tabular data with a fixed schema, not for JSON documents with nested optional fields like achievements or friendsList, and it lacks native SQL-like querying for array containment. Option B (Cassandra API) is wrong because it uses CQL (Cassandra Query Language) and a wide-column store model, which does not natively support JSON document structures or SQL-like queries for array elements; it also requires a predefined schema. Option C (MongoDB API) is wrong because while it supports JSON documents and flexible schemas, it uses MongoDB's query language (e.g., db.collection.find({achievements: 'specificAchievement'})) rather than SQL-like queries, and the question explicitly requires SQL-like query capability.

Practice this question →
51
MCQhard

You are analyzing a SQL script for an Azure Synapse Analytics dedicated SQL pool as shown in the exhibit. The table 'SensorData' will contain billions of rows. Which statement about the table design is correct?

A.The table uses a clustered columnstore index, which is ideal for large data warehousing tables
B.The table is replicated across all compute nodes
C.The table uses round-robin distribution
D.The table uses a heap structure
AnswerA

Clustered columnstore indexes are recommended for large tables in Synapse to improve compression and query performance.

Why this answer

A hash distribution on DeviceID distributes rows across distributions based on the hash of DeviceID, which is good for large tables queried frequently by DeviceID. Clustered columnstore index is optimal for large tables in Synapse. Round-robin is for staging tables.

Clustered index is for small tables. The table is not replicated because replication is for small dimension tables.

Practice this question →
52
MCQeasy

A retail company stores product catalog data as JSON documents. Each product has a different set of attributes depending on its category (e.g., electronics have 'voltage', clothing has 'size'). The application needs to query products by category and price range efficiently. Which Azure data store is most appropriate for this workload?

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

Correct. Cosmos DB is a NoSQL database that supports schema-flexible JSON documents and provides fast queries on any attribute, ideal for product catalogs with varying attributes.

Why this answer

Azure Cosmos DB is the most appropriate choice because it natively supports JSON documents with flexible schemas, enabling each product to have a different set of attributes per category. Its indexing policies can be configured to efficiently support queries filtering by category and price range, and it offers low-latency, high-throughput access ideal for retail catalog workloads.

Exam trap

The trap here is that candidates often choose Azure SQL Database because they assume all structured data requires a relational store, overlooking the fact that JSON documents with varying schemas are better served by a NoSQL document database like Cosmos DB.

How to eliminate wrong answers

Option B (Azure SQL Database) is wrong because it requires a fixed relational schema, making it cumbersome to store products with varying attributes per category without extensive use of EAV (Entity-Attribute-Value) patterns or JSON columns, which negate the benefits of a relational store. Option C (Azure Blob Storage) is wrong because it is designed for unstructured binary or text data, not for querying individual JSON documents by fields like category and price range; it lacks native indexing and query capabilities for document-level attributes. Option D (Azure Table Storage) is wrong because it is a key-value store that does not support native JSON document storage or querying by nested attributes; it requires flat schemas and cannot efficiently handle queries on multiple properties like price range across different product categories.

Practice this question →
53
MCQmedium

You need to store log files from multiple virtual machines in a central location. Each log file is appended to continuously and can be up to 1 TB. The solution must support concurrent appends from many VMs and provide low-latency read access for real-time monitoring. Which Azure storage solution should you choose?

A.Azure Cosmos DB
B.Azure Blob Storage with append blobs
C.Azure Files
D.Azure NetApp Files
AnswerB

Append blobs are designed for logging scenarios with concurrent appends.

Why this answer

Option A is correct because Azure Blob Storage (with append blobs) is designed for append-only logs, supports concurrent appends, and provides low-latency read access. Option B is wrong because Cosmos DB is not optimized for large append-only logs. Option C is wrong because Azure Files is a file share, not optimized for concurrent appends from many clients.

Option D is wrong because Azure NetApp Files is expensive and overkill for log storage.

Practice this question →
54
MCQmedium

A company stores IoT sensor data in Azure Blob Storage. The data is written once, rarely accessed, and must be retained for 10 years for compliance. The cheapest storage tier should be used for the first 30 days after ingestion, then moved to a lower-cost tier. Which storage tier configuration should you recommend?

A.Use the Hot tier for the first 30 days, then move to the Cool tier.
B.Use the Cool tier for the first 30 days, then move to the Archive tier.
C.Use the Archive tier from the start.
D.Use the Hot tier for the first 30 days, then move to the Archive tier.
AnswerD

Hot is cost-effective for frequent access; Archive is cheapest for long-term retention.

Why this answer

Option A is correct because the Hot tier is optimal for frequent access during the first 30 days, and the Archive tier is the cheapest for long-term retention (10 years) with rare access. Option B is wrong because the Cool tier is more expensive than Archive for long-term retention. Option C is wrong because the Cool tier is not the cheapest for 10 years.

Option D is wrong because the Hot tier is more expensive than needed for the first 30 days.

Practice this question →
55
MCQmedium

A social networking application needs to store and query relationships between users, such as 'friends of friends'. The application should be able to traverse these relationships efficiently to recommend new connections. Which Azure NoSQL data store and API should they choose?

A.Azure Cosmos DB with the Gremlin API
B.Azure Cosmos DB with the Table API
C.Azure Cache for Redis
D.Azure Blob Storage
AnswerA

Correct. The Gremlin API is a graph database that efficiently stores and queries relationships between entities, ideal for recommendation engines based on friend connections.

Why this answer

Azure Cosmos DB with the Gremlin API is the correct choice because Gremlin is a graph traversal language specifically designed for querying highly connected data, such as social network relationships. It allows efficient traversal of edges (e.g., 'friends of friends') using graph algorithms, which is exactly what the application needs for recommending new connections. Other APIs like Table API or services like Blob Storage lack native graph traversal capabilities.

Exam trap

The trap here is that candidates often confuse the Table API (which is also NoSQL) as suitable for relationships, but it cannot perform multi-hop graph traversals, while Azure Cache for Redis might seem plausible due to its set operations, but it lacks a graph query language and persistence guarantees.

How to eliminate wrong answers

Option B is wrong because the Table API is a key-value store optimized for simple lookups by partition and row key, and it cannot perform graph traversals like 'friends of friends'. Option C is wrong because Azure Cache for Redis is an in-memory cache, not a persistent data store, and while it supports data structures like sets, it lacks a native graph query language for multi-hop traversals. Option D is wrong because Azure Blob Storage is an object store for unstructured binary data (e.g., images, videos) and has no query engine for relationship traversal.

Practice this question →
56
MCQeasy

A company uses Azure Table Storage to store user session data. The data must be encrypted at rest. What should you do?

A.No action is required; Azure Storage encrypts data at rest by default.
B.Enable Azure Storage Service Encryption (SSE).
C.Use Azure SQL Database Transparent Data Encryption (TDE).
D.Implement client-side encryption before storing data.
AnswerA

Azure Storage automatically encrypts all data.

Why this answer

Azure Table Storage, as part of Azure Storage, automatically encrypts all data at rest using Azure Storage Service Encryption (SSE) with 256-bit AES encryption. This encryption is enabled by default for all new and existing storage accounts, including Table Storage, and cannot be disabled. Therefore, no additional action is required to meet the encryption-at-rest requirement.

Exam trap

The trap here is that candidates may think encryption at rest requires explicit configuration (like enabling SSE or TDE), not realizing that Azure Storage encrypts all data at rest by default, making options B, C, and D unnecessary or incorrect for this specific scenario.

How to eliminate wrong answers

Option B is wrong because Azure Storage Service Encryption (SSE) is already enabled by default for all Azure Storage accounts, including Table Storage; explicitly enabling it is unnecessary and redundant. Option C is wrong because Transparent Data Encryption (TDE) is a feature specific to Azure SQL Database and SQL Server, not applicable to Azure Table Storage, which is a non-relational, key-value store. Option D is wrong because client-side encryption is an optional, additional layer of security for scenarios requiring end-to-end encryption, but it is not required to achieve encryption at rest, which is already handled server-side by Azure Storage by default.

Practice this question →
57
MCQmedium

A social media startup needs to store user sessions as key-value pairs. Each session has a unique session ID, and the data needs to be globally distributed across multiple Azure regions to support low-latency reads for users worldwide. The development team expects heavy write throughput and needs flexible schema. Which Azure data store should they choose?

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

Azure Cosmos DB supports global distribution, multiple consistency levels, and flexible schema, making it ideal for globally distributed key-value workloads with high throughput.

Why this answer

Azure Cosmos DB is the correct choice because it provides globally distributed, multi-region writes and reads with turnkey global distribution, supports flexible schema via its document model, and offers multiple consistency levels to balance performance and data integrity. It is designed for high-throughput, low-latency workloads like user sessions, with session IDs serving as natural partition keys for efficient key-value lookups.

Exam trap

The trap here is that candidates often confuse Azure Cache for Redis (a caching layer) with a durable, globally distributed data store, overlooking that session data requiring persistence and global replication needs a database like Cosmos DB, not an in-memory cache.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a NoSQL key-value store but lacks native global distribution with multi-region writes and low-latency reads across regions; it is region-bound and requires manual replication. Option B is wrong because Azure Blob Storage is optimized for unstructured binary or text data (e.g., images, logs) and does not support key-value access patterns with high write throughput or flexible schema for session data. Option D is wrong because Azure Cache for Redis is an in-memory cache, not a durable data store; it is designed for temporary caching and cannot guarantee persistence or global distribution for session data that must survive restarts or be replicated across regions.

Practice this question →
58
MCQmedium

A gaming company stores player scores in Azure Cosmos DB using the NoSQL API. Each document contains fields: PlayerID (unique to the 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

GameID is the attribute used in the query filter. Choosing it as the partition key ensures that all scores for a given game are co-located in one partition, allowing a point query to that single partition and minimizing RU cost.

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's data. This minimizes RU consumption by avoiding cross-partition fan-out, as the query engine can target a single partition. Using any other field would force scanning multiple partitions, increasing RU cost.

Exam trap

The trap here is that candidates often pick a unique key like PlayerID thinking it ensures even distribution, but they overlook that the query pattern (filtering by GameID) must drive the partition key choice to avoid cross-partition queries.

How to eliminate wrong answers

Option A is wrong because PlayerID is unique per player, so each partition would hold only one document, leading to excessive partitions and cross-partition queries for the GameID-based query. Option C is wrong because Score is a high-cardinality, frequently updated value that would cause hot partitions and inefficient query routing, as the query filters on GameID, not Score. Option D is wrong because Timestamp is monotonically increasing, which creates a hot partition on the latest timestamp and does not align with the query filter on GameID, forcing full partition scans.

Practice this question →
59
MCQmedium

A social media company stores user session data. Each session record must be quickly looked up by user ID and must have strong consistency so that once a session is written, subsequent reads always return the latest data. The company expects billions of session records globally and needs low-latency reads/writes. Which Azure data store best meets these requirements?

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

Correct. Cosmos DB provides low-latency, globally distributed key-value access with multiple consistency levels including strong consistency.

Why this answer

Azure Cosmos DB with SQL API is the correct choice because it offers single-digit millisecond read/write latencies at any scale, global distribution, and tunable consistency levels including strong consistency. Strong consistency ensures that once a write is acknowledged, all subsequent reads return the latest data, which is critical for session state where stale reads could cause authentication or authorization failures. Cosmos DB also supports automatic indexing and partitioning by user ID, enabling fast lookups across billions of records.

Exam trap

The trap here is that candidates often confuse Azure Table Storage's low cost and key-value model with the strong consistency requirement, not realizing that Table Storage defaults to eventual consistency and cannot guarantee that a read immediately after a write returns the latest data, especially in globally distributed scenarios.

How to eliminate wrong answers

Option B (Azure Blob Storage) is wrong because it is designed for unstructured binary or text data (e.g., images, videos, backups) and does not support low-latency key-value lookups or strong consistency guarantees for individual records; it is optimized for throughput, not point reads. Option C (Azure Table Storage) is wrong because while it supports key-value lookups, it only offers eventual consistency by default and cannot provide strong consistency across globally distributed replicas, which is required for session data. Option D (Azure Cache for Redis) is wrong because it is an in-memory cache that provides low latency but does not guarantee strong consistency (it is eventually consistent) and data is volatile unless persistence is configured, making it unsuitable as a durable primary store for session records that must survive restarts.

Practice this question →
60
MCQmedium

A social media application stores user posts in Azure Cosmos DB. Each post has fields: PostID (unique), UserID, Timestamp, Content, LikesCount. The application frequently queries for all posts by a specific UserID ordered by Timestamp descending. To minimize Request Unit (RU) consumption, which partition key and indexing strategy should be used?

A.Partition key: UserID, and create a composite index on (UserID, Timestamp DESC)
B.Partition key: Timestamp, and sort by UserID in the query
C.Partition key: PostID, and use ORDER BY Timestamp
D.Partition key: UserID, and use ORDER BY PostID
AnswerA

This design localizes all posts for a user in one partition and uses an index that directly supports the filter and sort order.

Why this answer

Option A is correct because UserID is the most frequently filtered attribute, making it an ideal partition key to distribute data evenly and avoid cross-partition queries. Adding a composite index on (UserID, Timestamp DESC) allows the query to be served from a single physical partition with an index seek, minimizing RU consumption by avoiding a full scan or sort operation.

Exam trap

The trap here is that candidates often pick a partition key based on the ORDER BY column (Timestamp) without realizing that the filter column (UserID) should be the partition key to avoid cross-partition queries, and that a composite index is needed to avoid an expensive sort.

How to eliminate wrong answers

Option B is wrong because Timestamp as a partition key would cause hot partitions (e.g., all posts from a trending time) and the query would need to scatter across partitions to filter by UserID, increasing RU. Option C is wrong because PostID as a partition key would scatter each user's posts across many partitions, forcing a cross-partition query with ORDER BY Timestamp that requires a costly sort across partitions. Option D is wrong because using ORDER BY PostID does not satisfy the requirement to order by Timestamp descending, and even with UserID as partition key, the query would need to sort posts by PostID instead of Timestamp, which is incorrect and inefficient.

Practice this question →
61
MCQmedium

A global social media app uses Azure Cosmos DB (NoSQL API) to store user profile data. The app is read-heavy and must serve content with the lowest possible latency to users worldwide. The data is updated by users, and the business has determined that eventual consistency is acceptable because immediate consistency after a write is not critical for profile views. Which consistency level should they choose to minimize read latency?

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

Eventual consistency provides the best read performance and availability, with no ordering guarantees.

Why this answer

Eventual consistency is the correct choice because it offers the lowest read latency by allowing reads to return data immediately without waiting for replication to complete. Since the app is read-heavy, global, and can tolerate eventual consistency for profile views, this consistency level minimizes the time to serve content by not imposing any ordering or staleness guarantees on replicas.

Exam trap

The trap here is that candidates often choose Session consistency because it is the default for many Azure Cosmos DB SDKs, but the question explicitly asks for the lowest read latency with eventual consistency acceptable, making Eventual the correct answer despite Session being a common default.

How to eliminate wrong answers

Option B (Strong) is wrong because it requires all replicas to agree on the latest write before any read can proceed, which adds significant latency, especially across global regions, and is unnecessary given the business's acceptance of eventual consistency. Option C (Bounded staleness) is wrong because it imposes a maximum staleness window (e.g., 5 seconds or 10 operations), which still introduces a replication delay and higher read latency compared to eventual, and is overkill for a scenario where any staleness is acceptable. Option D (Session) is wrong because it guarantees monotonic reads and writes within a single client session, which adds overhead to maintain session context and does not minimize read latency globally; it is designed for per-session consistency, not for lowest-latency global reads.

Practice this question →
62
MCQeasy

A retail company plans to store product catalog data that includes product ID, name, description, price, and a varying set of attributes (e.g., size, color, material). The application requires low-latency reads and writes, global distribution, and the ability to handle schema flexibility. Which Azure data store is best suited for this workload?

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

Azure Cosmos DB is a globally distributed, multi-model NoSQL database that supports flexible schemas, low-latency reads/writes, and global distribution, making it well-suited for product catalog data.

Why this answer

Azure Cosmos DB is the best choice because it provides low-latency reads and writes (single-digit milliseconds at the 99th percentile), global distribution with multi-region writes, and automatic schema flexibility through its document model. It supports varying product attributes (e.g., size, color, material) without requiring schema changes, and its turnkey global distribution ensures data is replicated across regions for fast access.

Exam trap

The trap here is that candidates often confuse Azure Table Storage with Cosmos DB because both are NoSQL, but Table Storage lacks global distribution with multi-region writes and the low-latency guarantees required for this workload, while Cosmos DB is the only option that combines schema flexibility, global distribution, and low-latency reads/writes.

How to eliminate wrong answers

Option A is wrong because Azure SQL Database is a relational store with a fixed schema, requiring ALTER TABLE statements to add new attributes, which cannot handle the varying set of attributes efficiently and does not natively support global distribution with multi-region writes. Option C is wrong because Azure Table Storage is a key-value store that lacks native support for global distribution with multi-region writes and does not provide the same low-latency guarantees as Cosmos DB (Table Storage is optimized for high throughput but not single-digit millisecond latency at scale). Option D is wrong because Azure Blob Storage is designed for unstructured binary data (e.g., images, videos) and does not support querying on individual attributes like product ID or price, nor does it provide schema flexibility for document-like data.

Practice this question →
63
MCQmedium

A startup develops a mobile application that stores user preferences as simple key-value pairs. The app is only used in North America, and the team needs low-latency reads and writes with minimal cost. They do not require global distribution or complex querying. Which Azure data store should they choose?

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

Azure Table Storage is a cost-efficient NoSQL key-value store that offers low-latency access for simple data without complex querying. It is the best choice given the single-region requirement and cost constraint.

Why this answer

Azure Table Storage is the correct choice because it provides a cost-effective, low-latency key-value store for simple data like user preferences, with no need for global distribution or complex querying. It offers single-digit millisecond latency for reads and writes within a single region, and its pay-per-request pricing model minimizes cost for a startup. The Table API in Azure Cosmos DB would be overkill and more expensive for this North America-only, non-distributed scenario.

Exam trap

The trap here is that candidates often confuse Azure Cosmos DB Table API with Azure Table Storage, assuming the Cosmos DB version is always better, but they fail to consider the cost implications and the fact that Azure Table Storage is sufficient for simple, single-region key-value workloads without global distribution.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB (SQL API) is a globally distributed, multi-model database designed for complex queries and high throughput, which is unnecessary and costly for simple key-value pairs with no global distribution requirement. Option B is wrong because Azure Cosmos DB (Table API) provides the same key-value functionality as Azure Table Storage but with global distribution and higher throughput guarantees, leading to significantly higher costs for a single-region, low-traffic app. Option D is wrong because Azure SQL Database is a relational database with full SQL support, which is overkill for simple key-value pairs and incurs higher costs due to its provisioned compute and storage model.

Practice this question →
64
MCQhard

A company uses Azure Blob Storage to store video files for a streaming service. The files are accessed frequently for the first 30 days after upload, then rarely after. The company wants to minimize storage costs while maintaining fast access for frequently accessed files. What should they implement?

A.Azure Content Delivery Network (CDN)
B.Azure Files shares
C.Blob lifecycle management policies
D.Geo-redundant storage (GRS)
AnswerC

Lifecycle management automates moving blobs between tiers (Hot, Cool, Archive) based on age, optimizing cost while keeping frequently accessed data in Hot tier.

Why this answer

Blob lifecycle management policies allow you to automatically transition blobs to cooler, cheaper access tiers (e.g., from Hot to Cool or Archive) based on age. This directly addresses the requirement: after 30 days of frequent access, the policy moves the video files to a lower-cost tier, reducing storage costs while keeping the Hot tier available for the initial high-access period.

Exam trap

The trap here is that candidates often confuse cost optimization with performance acceleration, mistakenly choosing Azure CDN (Option A) because it improves access speed, when the question explicitly asks for minimizing storage costs while maintaining fast access for frequently accessed files.

How to eliminate wrong answers

Option A is wrong because Azure CDN is a content delivery network that caches content at edge locations for faster delivery, not a storage cost optimization mechanism; it does not automatically change the storage tier of the source blobs. Option B is wrong because Azure Files shares provide SMB/NFS file shares for shared access, not a tiering solution for blob storage cost management; they are a different storage service entirely. Option D is wrong because Geo-redundant storage (GRS) replicates data to a secondary region for disaster recovery, which increases storage costs and does not address the need to reduce costs for infrequently accessed data.

Practice this question →
65
MCQhard

You are a data engineer for a global gaming company. The company collects telemetry data from millions of players in real time. Each telemetry event is a JSON object containing player ID, game session ID, event type, timestamp, and a payload of up to 5 KB. The data must be stored for 90 days for real-time analytics and then moved to long-term storage for 5 years for historical analysis. The real-time analytics require querying by player ID and event type with sub-second latency. The long-term storage must be cost-effective and support batch analytics. You need to design a storage solution. Which combination of Azure services should you use to meet these requirements?

A.Store all telemetry in Azure Data Lake Storage Gen2 with a hierarchical namespace, and use Azure Synapse Serverless SQL for real-time queries.
B.Ingest telemetry into Azure Stream Analytics, output to Azure SQL Database for 90 days, then export to Azure Data Lake Storage.
C.Ingest telemetry into Azure Event Hubs and then store in Azure Blob Storage with a lifecycle management policy to delete after 90 days.
D.Ingest telemetry into Azure Cosmos DB with TTL set to 90 days, then use Azure Data Factory to copy expired data to Azure Blob Storage.
AnswerD

Cosmos DB provides low-latency queries; TTL automatically removes data; Blob Storage is cost-effective for long-term.

Why this answer

Option A is correct because Azure Cosmos DB provides sub-second query latency on player ID and event type, with a Time-to-Live (TTL) to automatically expire data after 90 days. Then, you can use Azure Data Factory to copy the expired data to Azure Blob Storage (Cool or Archive) for cost-effective long-term storage. Option B is wrong because Azure Event Hubs is for ingestion, not storage.

Option C is wrong because Azure Stream Analytics is for processing, not storage. Option D is wrong because Azure Data Lake Storage is for analytics, but for real-time sub-second queries, Cosmos DB is better.

Practice this question →
66
MCQmedium

You need to store telemetry data from millions of devices. Each record includes a device ID, timestamp, and metric value. The data will be queried by device ID and time range. Which Azure data store is best suited for this scenario?

A.Azure Data Explorer
B.Azure SQL Database
C.Azure Storage Queues
D.Azure Cosmos DB
AnswerA

ADX is built for high-performance time-series data ingestion and querying, making it ideal for telemetry.

Why this answer

Azure Data Explorer (ADX) is optimized for time-series data and can ingest high volumes of telemetry, with fast queries on time ranges and device IDs. Azure Cosmos DB is good for real-time apps but less efficient for large-scale time-series analytics. Azure SQL Database is relational and may not scale as well.

Azure Storage Queues are for messaging, not storage/query.

Practice this question →
67
MCQhard

A global e-commerce company uses Azure Cosmos DB with multiple write regions to handle high traffic from users worldwide. For their order processing system, they must guarantee that once an order is recorded, all subsequent reads from any region see the most up-to-date order status. However, they also need low write latency globally. Which configuration should they choose to meet these requirements?

A.Use multi-region writes with strong consistency
B.Use single-region writes with strong consistency
C.Use multi-region writes with bounded staleness consistency
D.Use single-region writes with eventual consistency and implement application-level conflict resolution
AnswerB

Correct. Strong consistency provides immediate global consistency, but it requires a single write region. This trade-off meets the guarantee at the cost of slightly higher write latency for remote users.

Why this answer

Strong consistency with single-region writes ensures that all reads in any region return the most recent write, because Cosmos DB replicates writes synchronously to all regions when strong consistency is configured. This guarantees linearizability: once an order is committed, every subsequent read sees that update. Single-region writes avoid the conflict-resolution overhead of multi-region writes while still providing low write latency within the primary region, and reads from secondary regions are served from locally replicated data that is kept fully consistent.

Exam trap

The trap here is that candidates assume multi-region writes are needed for global low-latency writes, but they overlook that strong consistency cannot be combined with multi-region writes, and that single-region writes with strong consistency still provide low write latency in the primary region while guaranteeing immediate read freshness across all regions.

How to eliminate wrong answers

Option A is wrong because multi-region writes with strong consistency is not supported in Azure Cosmos DB; strong consistency can only be used with a single write region. Option C is wrong because bounded staleness consistency allows reads to lag behind writes by a configurable interval (e.g., 100,000 operations or 5 seconds), which violates the requirement that all subsequent reads see the most up-to-date order status immediately. Option D is wrong because eventual consistency does not guarantee that reads return the latest write; it only guarantees that replicas will converge over time, and application-level conflict resolution cannot enforce immediate global read freshness.

Practice this question →
68
MCQmedium

A company uses Azure Cosmos DB with the Cassandra API for a time-series telemetry application. The data model uses a composite primary key (device_id, timestamp). The application queries telemetry for a specific device within a time range. Recently, query performance has degraded as data volume grows. The RU consumption per query is high. Which action should they take to improve performance and reduce RU cost?

A.Change the partition key to timestamp.
B.Increase the provisioned RU/s on the container.
C.Add a secondary index on the timestamp column.
D.Change the clustering order to descending on timestamp.
AnswerD

Descending order makes time-range queries efficient by reading only relevant rows.

Why this answer

Changing the clustering order to descending on timestamp (option C) allows the most recent data to be retrieved first without scanning all rows. Option A (increasing RU) does not improve efficiency. Option B (adding a secondary index) may increase RU.

Option D (changing partition key to timestamp) would scatter device data across partitions, hurting queries by device.

Practice this question →
69
MCQeasy

You need to store JSON documents that are frequently read and written by a web application. Each document is about 10 KB. The solution must provide low-latency access globally. Which Azure data store should you use?

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

Cosmos DB is a globally distributed NoSQL database for JSON.

Why this answer

Azure Cosmos DB is a globally distributed NoSQL database that supports JSON documents and provides low-latency access. Option A is wrong because Blob Storage is object storage, not optimized for individual document reads/writes. Option B is wrong because Table Storage is for key-value data.

Option D is wrong because SQL Database is relational.

Practice this question →
70
MCQmedium

A company stores historical sensor data in Azure Blob Storage. The data is accessed only a few times per year for compliance audits, but when requested, it must be available for reading within 15 minutes. The company wants to minimize storage costs. Which blob access tier should they use?

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

Correct. The Cool tier provides low storage cost for infrequently accessed data while supporting retrieval within minutes, meeting the 15-minute requirement.

Why this answer

The Cool tier is the optimal choice because it balances low storage cost with the ability to retrieve data within minutes, meeting the 15-minute availability requirement. Archive would incur a retrieval delay of up to 15 hours, which violates the compliance audit SLA. Hot and Premium tiers are more expensive and unnecessary for data accessed only a few times per year.

Exam trap

The trap here is that candidates often choose Archive for its lowest storage cost without considering the mandatory rehydration delay, which can take up to 15 hours and violates the 15-minute availability requirement.

How to eliminate wrong answers

Option A (Hot) is wrong because it is designed for frequently accessed data and has higher storage costs, making it cost-inefficient for data accessed only a few times per year. Option C (Archive) is wrong because it has the lowest storage cost but requires a rehydration process that can take up to 15 hours, exceeding the 15-minute availability requirement. Option D (Premium) is wrong because it is optimized for low-latency, high-transaction workloads (e.g., Azure Virtual Machine disks) and incurs the highest storage cost, which is unnecessary for infrequent compliance audits.

Practice this question →
71
MCQmedium

A social networking application stores user profiles as JSON documents. Each profile can have different fields (e.g., education, work history, interests) depending on what the user fills in. The application also needs to traverse friend connections as a graph to recommend new friends. The development team wants to use a single Azure Cosmos DB account for both workloads. Which combination of Azure Cosmos DB APIs should they choose?

A.SQL API for profiles and Gremlin API for graph
B.MongoDB API for profiles and SQL API for graph
C.Gremlin API for both profiles and graph
D.Table API for profiles and Gremlin API for graph
AnswerA

Correct. The SQL API provides flexible querying of JSON documents, and the Gremlin API enables graph traversal. Both can coexist in a single Cosmos DB account using separate containers.

Why this answer

The SQL API (formerly DocumentDB API) is optimized for storing and querying JSON documents with flexible schemas, making it ideal for user profiles with varying fields. The Gremlin API is designed specifically for graph traversal queries, which is required for recommending friends based on friend connections. Using both APIs on the same Cosmos DB account allows the application to handle both workloads efficiently within a single service.

Exam trap

The trap here is that candidates assume the Gremlin API can handle both document and graph workloads because it stores properties as JSON-like data, but they overlook that it lacks the flexible querying and indexing capabilities of the SQL API for unstructured documents.

How to eliminate wrong answers

Option B is wrong because the MongoDB API is designed for MongoDB-compatible document workloads, not for graph traversal; using the SQL API for graph would require manual graph logic and lacks native graph traversal capabilities. Option C is wrong because while the Gremlin API can store JSON-like properties on vertices and edges, it is not optimized for flexible schema document queries or indexing, making it inefficient for storing and querying user profiles with arbitrary fields. Option D is wrong because the Table API is a key-value store with a fixed schema, not suitable for storing complex JSON documents with varying fields, and it does not support graph traversal.

Practice this question →
72
MCQmedium

A gaming company stores player session data as JSON documents. Each document contains fields like sessionId, userId, startTime, and a varying set of optional fields such as deviceType or campaignId. The application needs to query sessions by userId and startTime range using SQL-like queries, and also by sessionId with low latency. Which Azure Cosmos DB API should the company choose?

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

The SQL API provides SQL query support over JSON documents and handles schema flexibility well.

Why this answer

The SQL (Core) API is the correct choice because it natively supports SQL-like queries over JSON documents, enabling efficient filtering by userId and startTime range. It also provides low-latency point reads by sessionId when a well-designed partition key (e.g., /userId) is used, and it offers automatic indexing of all JSON properties, including optional fields like deviceType or campaignId.

Exam trap

The trap here is that candidates may choose the MongoDB API because they assume 'SQL-like queries' require MongoDB's query language, but the Core API actually provides native SQL syntax and is the only Azure Cosmos DB API that supports SQL directly over JSON documents.

How to eliminate wrong answers

Option B (MongoDB API) is wrong because while it supports JSON documents and SQL-like queries via MongoDB's query language, it does not natively support the exact SQL syntax the application requires, and its indexing behavior differs from the Core API's automatic indexing of all fields. Option C (Table API) is wrong because it is designed for key-value storage with a flat schema and does not support nested JSON documents or SQL-like queries on varying optional fields. Option D (Gremlin (Graph) API) is wrong because it is optimized for graph traversal queries on entities and relationships, not for document-based queries on JSON fields like userId or startTime.

Practice this question →
73
MCQmedium

A company stores user-submitted profile photos. Each photo is accessed frequently for the first month after upload, then accessed rarely for the next year. After one year, the photos are deleted. Which Azure Blob Storage access tier should be used for the first month to minimize cost while ensuring low-latency access?

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

Correct. The Hot tier is optimized for frequent access, offering low latency and the highest storage cost but no retrieval cost, which is cost-effective for the high-access initial month.

Why this answer

The Hot tier is correct because it provides low-latency access and is optimized for frequent read/write operations, which matches the requirement of frequent access during the first month. It minimizes cost compared to Premium (which is for high-throughput scenarios) while still offering the necessary performance for user-submitted profile photos.

Exam trap

The trap here is that candidates often choose Cool tier thinking it balances cost and access, but they overlook the frequent access pattern in the first month, which makes Hot tier cheaper due to lower access costs and no early deletion penalty.

How to eliminate wrong answers

Option B (Cool tier) is wrong because it is designed for infrequently accessed data with a 30-day minimum storage duration and higher access costs, which would be more expensive for frequent access in the first month. Option C (Archive tier) is wrong because it has a 180-day minimum storage duration and retrieval latency of hours, making it unsuitable for low-latency access. Option D (Premium tier) is wrong because it uses SSDs and is optimized for high transaction rates and low latency for block blobs, but it is significantly more expensive than Hot tier and unnecessary for this access pattern.

Practice this question →
74
MCQhard

A company stores user session data for a web application. Each session has a unique SessionID, UserID, start time, end time, and a variable set of attributes (e.g., pages visited, clicks, device type). The workload requires low-latency reads by SessionID and occasional queries by UserID and time range. Schema flexibility is critical because the attributes evolve over time. The team wants a fully managed NoSQL database that supports secondary indexing. Which Azure data store should they choose?

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

Correct. Cosmos DB's NoSQL API natively supports JSON documents with flexible schema. It offers low-latency reads on the partition key and allows secondary indexes to support queries on other attributes like UserID.

Why this answer

Azure Cosmos DB (NoSQL API) is correct because it is a fully managed NoSQL database that offers low-latency reads by SessionID (using a partition key), supports secondary indexing for queries by UserID and time range, and provides schema flexibility for evolving session attributes. Its multi-model API and global distribution meet the workload requirements without manual indexing or schema management.

Exam trap

The trap here is that candidates may confuse Azure Table Storage (which is also NoSQL and schema-flexible) with Cosmos DB, but Table Storage lacks secondary indexing, making it unsuitable for queries by UserID and time range without expensive scans.

How to eliminate wrong answers

Option B (Azure SQL Database) is wrong because it is a relational database requiring a fixed schema, which contradicts the need for schema flexibility with evolving attributes. Option C (Azure Table Storage) is wrong because it does not support secondary indexing; queries by UserID and time range would require full table scans, failing the low-latency requirement. Option D (Azure Blob Storage) is wrong because it is an object store for unstructured data (e.g., files, images), not a database with query capabilities or indexing for session data.

Practice this question →
75
MCQmedium

A company stores log files in Azure Blob Storage. Each log file is a CSV file ranging from 100 MB to 1 GB. They need to query the logs using SQL queries and plan to use Azure Synapse Serverless SQL. The logs are stored in a container named 'logs' with a folder structure like 'year=2023/month=01/day=01/logfile.csv'. They want to optimize query performance and reduce data scanned. Which partitioning strategy should they implement?

A.Convert logs to Parquet format and store in a single folder.
B.Use the existing folder structure with year/month/day partitions.
C.Consolidate all logs into a single large CSV file.
D.Use random file names to distribute load.
AnswerB

Synapse Serverless SQL can use folder partitioning to prune partitions, reducing data scanned.

Why this answer

Partitioning by year, month, and day (option A) using folder structure allows Synapse to perform partition elimination, reducing data scanned. Option B (single large file) is not partitioned. Option C (parquet format) is a columnar format that improves performance but does not address partition elimination.

Option D (random GUID names) prevents partition elimination.

Practice this question →
Page 1 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