Knowledge + Practice

CCNA Develop for Azure storage Questions

75 of 179 questions · Page 1/3 · Develop for Azure storage · Answers revealed

Practice these questions Domain overview All questions

1

MCQhard

You are building a compliance solution that stores terabytes of data in Azure Blob Storage. Data is appended frequently and never modified. Regulatory requirements mandate that no data can be overwritten or deleted for 7 years. Which storage configuration should you enable?

A.Enable immutability policy (time-based retention)

B.Enable blob soft delete

C.Enable blob versioning

D.Enable change feed

AnswerA

Correct. A time-based retention policy makes blobs immutable for the specified duration (up to 7 years or more), meeting compliance requirements.

Why this answer

A is correct because a time-based retention policy under Azure Blob Storage immutability policy ensures that blobs cannot be overwritten or deleted for a specified duration (here, 7 years). This meets the regulatory requirement of write-once-read-many (WORM) compliance, and the policy is enforced at the storage container level, preventing any modifications or deletions even by the storage account owner.

Exam trap

The trap here is that candidates often confuse immutability policies with soft delete or versioning, thinking that preserving previous versions or recovering deleted blobs satisfies the 'no overwrite or delete' requirement, but only immutability policies provide a hard enforcement that prevents the operation from succeeding in the first place.

How to eliminate wrong answers

Option B is wrong because blob soft delete only protects against accidental deletion by retaining deleted blobs for a configurable retention period, but it does not prevent overwrites or provide a hard guarantee against deletion—data can still be permanently deleted before the soft-delete retention expires if the policy is changed. Option C is wrong because blob versioning preserves previous versions of a blob when it is overwritten or deleted, but it does not prevent overwrites or deletions from occurring; a user can still overwrite the current version, and the regulatory requirement mandates that no data can be overwritten or deleted at all. Option D is wrong because the change feed provides a transaction log of all changes to blobs in a container, but it does not enforce any retention or immutability—it only records events and does not prevent modifications or deletions.

Practice this question →

2

MCQhard

You need to store a large (terabytes) append-only dataset for compliance purposes. The data must be immutable to prevent tampering after writes. You also want to minimize storage cost and achieve high write throughput. Which Azure Storage solution should you use?

A.Azure Blob Storage with Append Blobs and an immutable blob policy

B.Azure Data Lake Storage Gen2 with Append Blobs and immutability

C.Azure Files with immutable shares

D.Azure NetApp Files with immutability

AnswerA

Correct. Append Blobs are ideal for append operations, and immutability provides tamper-proof storage. Cost-effective for high-volume writes.

Why this answer

Azure Blob Storage with Append Blobs and an immutable blob policy is correct because Append Blobs are optimized for append-only operations (e.g., logging, audit trails) and support high write throughput. Immutable blob policies (WORM – Write Once, Read Many) enforce data immutability at the blob level, preventing modification or deletion during the retention period, which meets compliance requirements. This combination minimizes storage cost by using the cool or archive tier for Append Blobs, while still achieving the required write performance.

Exam trap

The trap here is that candidates often confuse Azure Data Lake Storage Gen2 (which is just Blob Storage with a hierarchical namespace) as having separate immutability features, but immutability is a Blob Storage capability that works identically on Data Lake Storage Gen2; however, the question's append-only requirement is best met by Append Blobs in standard Blob Storage, not by adding the hierarchical namespace overhead of Data Lake Storage Gen2.

How to eliminate wrong answers

Option B is wrong because Azure Data Lake Storage Gen2 is built on Blob Storage and supports Append Blobs, but it does not natively offer immutable blob policies; immutability is a Blob Storage feature, not a Data Lake Storage Gen2 feature, and using Data Lake Storage Gen2 would add unnecessary complexity and cost for a simple append-only compliance scenario. Option C is wrong because Azure Files with immutable shares is designed for SMB file shares and does not support append-only operations or high write throughput at the terabyte scale; it is optimized for shared file access, not streaming append workloads. Option D is wrong because Azure NetApp Files is a high-performance file service for NFS/SMB workloads, not designed for append-only blob storage; it lacks native append-blob semantics and immutable blob policies, and its cost is significantly higher for large-scale compliance data.

Practice this question →

3

MCQhard

You are creating an Azure function that uses an output binding to write messages to an Azure Storage Queue. The function must ensure that messages are not lost if the function fails after writing to the queue. Which approach should you use?

A.Use a separate queue client SDK to write messages and handle errors manually.

B.Write to the queue directly in the function code and rely on the function's retry policy.

C.Use a durable function to orchestrate the writing and processing.

D.Use the queue output binding with a queue trigger input binding in the same function.

AnswerD

This ensures transactional consistency.

Why this answer

Option D is correct because using a queue output binding with a queue trigger input binding in the same function ensures that the message is only written to the queue after the function execution completes successfully. If the function fails after the write, the output binding automatically rolls back the write, preventing message loss. This is achieved through the Azure Functions runtime's transactional behavior with storage bindings.

Exam trap

The trap here is that candidates often assume direct SDK calls or retry policies provide sufficient reliability, but they overlook the atomic write guarantee that only output bindings with a trigger input binding provide in Azure Functions.

How to eliminate wrong answers

Option A is wrong because using a separate queue client SDK bypasses the built-in transactional guarantees of Azure Functions bindings, requiring manual error handling and risking message loss if the function fails after the SDK write. Option B is wrong because writing directly to the queue in function code and relying on the function's retry policy does not guarantee atomicity; if the function fails after the write, the message is already in the queue and cannot be rolled back. Option C is wrong because durable functions are designed for complex orchestration and state management, not for ensuring atomic message writes to a queue; they add unnecessary complexity and do not solve the specific transactional requirement.

Practice this question →

4

MCQmedium

You are building a serverless application that processes images uploaded to an Azure Blob Storage container. When a new blob is added, an Azure Function (PowerShell) is triggered to generate a thumbnail and store it in a different container. The function must run with the least privilege necessary. The function uses a managed identity assigned to the function app. You need to grant the function access to read blobs from the source container and write blobs to the destination container. The storage account already has a private endpoint configured. What is the correct way to assign permissions?

A.Generate a SAS token for the source container with read permission and for the destination container with write permission, and store them in Key Vault for the function to retrieve.

B.Add the function app's managed identity to the storage account's Access Control (IAM) with the 'Storage Blob Data Owner' role on the entire storage account.

C.Add the function app's managed identity to the source container's Access Control (IAM) with the 'Storage Blob Data Reader' role, and to the destination container with the 'Storage Blob Data Contributor' role.

D.Use the storage account connection string in the function app settings and access the blobs using the connection string.

AnswerC

This grants exactly the needed permissions on each container.

Why this answer

Option C is correct because it uses Azure RBAC roles scoped to individual containers, granting the function app's managed identity exactly the permissions needed: 'Storage Blob Data Reader' for reading from the source container and 'Storage Blob Data Contributor' for writing to the destination container. This follows the principle of least privilege, avoids over-permissioning, and works seamlessly with private endpoints since RBAC does not depend on network paths.

Exam trap

The trap here is that candidates often choose the overly broad 'Storage Blob Data Owner' role (Option B) because they think it's simpler, but the question explicitly requires 'least privilege necessary,' making container-scoped roles the correct answer.

How to eliminate wrong answers

Option A is wrong because generating SAS tokens and storing them in Key Vault introduces unnecessary complexity and secret management overhead, and SAS tokens can be leaked or expire; managed identity with RBAC is simpler and more secure. Option B is wrong because assigning the 'Storage Blob Data Owner' role on the entire storage account grants far more permissions than needed (including full control over all containers and data), violating the least privilege requirement. Option D is wrong because using a storage account connection string embeds a shared key in the function app settings, which is a security risk (key exposure) and does not leverage managed identity; it also bypasses the private endpoint's network isolation benefits.

Practice this question →

5

MCQhard

Refer to the exhibit. You are reviewing a role assignment for a managed identity. The JSON shows the role and scope. What access does this assignment grant?

A.Full management access to the storage account.

B.Read access to all containers in the storage account.

C.Read, write, and delete access to blobs in container c1.

D.Read-only access to blobs in container c1.

AnswerC

Storage Blob Data Contributor grants these permissions at container scope.

Why this answer

The role assignment grants the 'Storage Blob Data Contributor' role at the scope of container 'c1'. This role provides read, write, and delete access to blob data within that specific container, but not management operations on the storage account itself. Option C correctly identifies this level of access.

Exam trap

The trap here is that candidates confuse the 'Storage Blob Data Contributor' role with read-only access (Option D) or assume it applies to the entire storage account (Option B), missing the critical scope restriction to container 'c1'.

How to eliminate wrong answers

Option A is wrong because 'Storage Blob Data Contributor' does not grant management access to the storage account (e.g., configuring firewall rules or changing replication); that requires roles like 'Contributor' or 'Owner' at the storage account scope. Option B is wrong because the scope is limited to container 'c1', not all containers in the storage account, and the role allows write/delete operations, not just read. Option D is wrong because the role includes write and delete permissions, not read-only access.

Practice this question →

6

MCQmedium

You need to store large amounts of unstructured data (images and videos) that are accessed rarely (a few times per year) but must be available within minutes when requested. The data must be geo-redundant for disaster recovery. You want to minimize storage costs. Which storage tier and redundancy option should you choose?

A.Hot storage tier with geo-redundant storage (GRS)

B.Cool storage tier with geo-redundant storage (GRS)

C.Archive storage tier with read-access geo-redundant storage (RA-GRS)

D.Premium storage tier with local redundant storage (LRS)

AnswerB

Cool tier provides low storage cost for infrequently accessed data with immediate availability. GRS ensures geo-redundancy for disaster recovery at a moderate cost, meeting all requirements.

Why this answer

The Cool storage tier is designed for data that is infrequently accessed (a few times per year) and stored for at least 30 days, offering lower storage costs than Hot tier while still providing low-latency retrieval within minutes. Geo-redundant storage (GRS) replicates data to a paired secondary region, ensuring disaster recovery with geo-redundancy. This combination meets the requirements of rare access, minutes-availability, geo-redundancy, and minimal cost.

Exam trap

The trap here is that candidates often confuse the Archive tier's low storage cost with its high retrieval latency (hours), forgetting the requirement for data to be available within minutes, or they overlook that GRS is sufficient for geo-redundancy without needing read-access (RA-GRS).

How to eliminate wrong answers

Option A is wrong because the Hot storage tier has higher storage costs than Cool tier, making it suboptimal for rarely accessed data. Option C is wrong because the Archive storage tier has the lowest storage cost but retrieval times can take hours (up to 15 hours for standard priority), not minutes, and RA-GRS is unnecessary since read access is not required. Option D is wrong because Premium storage tier is optimized for low-latency, high-performance workloads (e.g., VMs, databases) and uses local redundant storage (LRS), which does not provide geo-redundancy for disaster recovery.

Practice this question →

7

MCQeasy

You are developing a web application that allows users to upload profile pictures to Azure Blob Storage. The application generates thumbnails using an Azure Function that is triggered by blob creation. You need to ensure that the function only processes image files and ignores other file types. What should you do?

A.Set the trigger's 'source' parameter to 'EventGrid' and filter events by the 'content-type' property.

B.Set the trigger's 'filter' property to '*.jpg,*.png'.

C.Implement the function without filtering and check the content type inside the function, ignoring non-image blobs.

D.Use the blob trigger with a path pattern like 'images/{name}.jpg' and 'images/{name}.png' and use the extension binding to filter.

AnswerD

You can create separate functions for each extension or use a pattern and check the extension in code.

Why this answer

Option D is correct because Azure Blob Storage triggers in Azure Functions support path patterns that filter on blob name extensions, such as 'images/{name}.jpg' and 'images/{name}.png'. This allows the function to only fire when a blob with a matching extension is created, effectively ignoring non-image files without any runtime code or additional services.

Exam trap

The trap here is that candidates often assume you must check the content type inside the function (Option C) because they think blob triggers cannot filter by extension, but Azure Functions actually support path pattern filtering on the trigger binding itself.

How to eliminate wrong answers

Option A is wrong because the 'source' parameter for EventGrid is not a standard property on a Blob trigger; EventGrid-based triggers use a separate EventGrid trigger type, and filtering by 'content-type' would require custom event filtering logic, not a simple parameter. Option B is wrong because the 'filter' property does not exist on a Blob trigger binding; the binding only supports path patterns with curly braces for name and extension, not a comma-separated list of extensions. Option C is wrong because while it would work functionally, it is not the recommended approach; the question asks what you 'should do' to ensure the function only processes image files, and using built-in path pattern filtering is more efficient and avoids unnecessary invocations.

Practice this question →

8

MCQmedium

Refer to the exhibit. You run the Azure CLI command to check if blob encryption is enabled for a storage account. The command returns 'false'. However, you know that Azure Storage encrypts all data at rest by default. What is the explanation?

A.The storage account was created with Azure Disk Encryption instead

B.The command is querying the wrong property; use 'encryption.requireInfrastructureEncryption'

C.The property 'encryption.services.blob.enabled' refers to customer-managed key encryption, not the default encryption

D.The storage account is in a region that does not support encryption

AnswerC

When using Microsoft-managed keys, this property is false; encryption is still active.

Why this answer

Option C is correct because the property `encryption.services.blob.enabled` in the Azure CLI command `az storage account show` specifically indicates whether customer-managed keys (CMK) are enabled for blob encryption, not whether the default Microsoft-managed key encryption is active. Azure Storage automatically encrypts all data at rest using Microsoft-managed keys, and this default encryption is always enabled and cannot be disabled. The command returns 'false' because CMK has not been configured, but the underlying default encryption is still in effect.

Exam trap

The trap here is that candidates assume the `encryption.services.blob.enabled` property reflects the presence of any encryption (including default encryption), when in fact it only indicates whether customer-managed keys are in use, leading them to incorrectly conclude that encryption is disabled.

How to eliminate wrong answers

Option A is wrong because Azure Disk Encryption is a separate feature for encrypting OS and data disks of virtual machines, not for Azure Storage blob encryption, and it does not affect the `encryption.services.blob.enabled` property. Option B is wrong because `encryption.requireInfrastructureEncryption` is a different property that controls double encryption (infrastructure encryption) at the storage account level, not the blob encryption setting queried by the command. Option D is wrong because all Azure Storage accounts in all regions support default encryption at rest; there is no region that lacks this capability.

Practice this question →

9

Multi-Selecthard

A Blob Storage workflow for product images must prevent accidental overwrite and support recovery of prior versions. Which two features should be enabled?

Select 2 answers

A.SFTP support

B.Blob soft delete

C.Static website hosting

D.Blob versioning

AnswersB, D

Soft delete helps recover deleted blobs and versions within the retention period.

Why this answer

Blob soft delete (B) protects against accidental deletion or overwrite by retaining deleted blobs for a configurable retention period, allowing recovery. Blob versioning (D) automatically maintains prior versions of a blob, enabling restoration of any previous state. Together, they provide comprehensive protection against overwrites and support version recovery.

Exam trap

The trap here is that candidates may confuse SFTP support or static website hosting with data protection features, but neither provides versioning or soft-delete capabilities required for overwrite prevention and recovery.

Practice this question →

10

Multi-Selectmedium

A healthcare application stores patient diagnostic images in Azure Blob Storage. The images are accessed by radiologists worldwide. You need to reduce latency for image retrieval while maintaining security and compliance. Which TWO actions should you take?

Select 2 answers

A.Upgrade to Premium Block Blob storage.

B.Enable Azure CDN or Azure Front Door with caching rules.

C.Enable read-access geo-redundant storage (RA-GRS).

D.Use Azure Front Door with private link to the storage account.

E.Use Blob Storage lifecycle management to delete blobs after reading.

AnswersB, D

Caches content at edge locations globally, reducing latency.

Why this answer

Options A and D are correct. Enabling Azure CDN or Azure Front Door caches content at edge locations, reducing latency. Geo-redundant storage provides replication to another region, but does not reduce latency for read access unless read-access is enabled (RA-GRS).

Option B (RA-GRS) provides a secondary read endpoint, but does not improve latency for all users globally. Option C incorrectly suggests deleting the blob after reading. Option E (Premium tier) improves performance but is costly and not specifically for global latency reduction.

Practice this question →

11

Multi-Selecteasy

Which TWO of the following are valid reasons to use Azure Table Storage instead of Azure Cosmos DB?

Select 2 answers

A.Global distribution with multi-master writes

B.Lower latency and higher throughput

C.Simpler API and no need for throughput provisioning

D.Lower cost for simple key-value workloads

E.Support for complex queries with indexing

AnswersC, D

Table Storage has a simpler model.

Why this answer

Option C is correct because Azure Table Storage offers a simpler REST API based on OData and does not require explicit throughput provisioning (RU/s). In contrast, Azure Cosmos DB requires you to configure request units per second for each container, which adds operational complexity. For simple key-value workloads, Table Storage's pay-per-query model with no reserved capacity is more straightforward.

Exam trap

The trap here is that candidates assume 'simpler' always means 'better performance,' but Azure Table Storage's simplicity comes at the cost of limited indexing and throughput, making it unsuitable for low-latency or complex query scenarios.

Practice this question →

12

MCQmedium

An application writes millions of small log entries (500 bytes each) daily. The logs are rarely read, and when read, they are accessed sequentially. You need to minimize storage costs and maximize write throughput. Which Azure Blob Storage type should you use?

A.Block Blob

B.Page Blob

C.Append Blob

D.Archive Blob

AnswerC

Append Blobs are purpose-built for append-only operations, offering high throughput for log data and efficient sequential reads.

Why this answer

Append Blob is optimized for append operations, making it ideal for logging scenarios where new data is continuously added to the end of the blob. It provides high write throughput for small, sequential writes (like 500-byte log entries) and lower storage costs compared to Block Blob for this pattern, as it avoids the overhead of managing multiple blocks per append. Additionally, Append Blob supports sequential read access efficiently, matching the rare, sequential read requirement.

Exam trap

The trap here is that candidates confuse 'Append Blob' with 'Block Blob' because both support blocks, but they fail to recognize that Append Blob is specifically designed for append-only workloads, while Block Blob is not optimized for sequential writes and incurs higher overhead per operation.

How to eliminate wrong answers

Option A is wrong because Block Blob is designed for random read/write access and requires managing blocks for each write, which introduces overhead and reduces write throughput for millions of small appends; it is not optimized for sequential append-only workloads. Option B is wrong because Page Blob is optimized for random read/write operations on fixed-size 512-byte pages (e.g., for virtual machine disks) and incurs higher costs due to its support for frequent updates and snapshots, making it unsuitable for low-cost, append-only logging. Option D is wrong because Archive Blob is a tier for cold data with infrequent access and high retrieval latency (hours), not a blob type; it cannot be used for active writes and would block the required high write throughput.

Practice this question →

13

MCQmedium

You are developing a solution that needs to store and retrieve JSON documents with a flexible schema. The data is accessed via REST API and requires low-latency reads. Which Azure Storage service should you use?

A.Azure Blob Storage

B.Azure Cosmos DB

C.Azure Table Storage

D.Azure Files

AnswerB

Cosmos DB provides flexible schema and low-latency.

Why this answer

Azure Cosmos DB is the correct choice because it natively supports storing and querying JSON documents with a flexible schema via its SQL API, and it guarantees single-digit millisecond read latencies at the 99th percentile, which meets the low-latency requirement. Unlike other Azure storage services, Cosmos DB is a fully managed NoSQL database designed for REST API access with automatic indexing of all JSON properties.

Exam trap

The trap here is that candidates often confuse Azure Blob Storage's ability to store JSON files (as blobs) with the ability to efficiently query and retrieve individual documents with low latency, overlooking the fact that Blob Storage lacks native indexing and querying capabilities for JSON content.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage stores unstructured binary data as blobs and does not provide native JSON document querying or indexing; it requires additional logic to parse and retrieve specific fields. Option C is wrong because Azure Table Storage is a key-value store that stores entities as rows with a fixed schema (partition key and row key), not flexible JSON documents, and it lacks native support for JSON querying or indexing. Option D is wrong because Azure Files provides SMB and NFS file shares for file-level access, not a REST API for JSON document storage and retrieval with low-latency reads.

Practice this question →

14

MCQhard

You are implementing a serverless function in Azure Functions that processes messages from an Azure Storage Queue. The function must ensure that each message is processed at least once and that processing failures are retried up to 5 times. After 5 failed attempts, the message should be moved to a poison queue. What should you configure?

A.Set the message time-to-live (TTL) to 5.

B.Implement a custom retry policy in the function code with a maximum of 5 retries.

C.Use the default queue poison message handling with 'maxDequeueCount' set to 5.

D.Set the visibility timeout to 5 minutes.

AnswerC

This is the built-in mechanism for retries and poison queue management.

Why this answer

Option C is correct because Azure Functions' Storage Queue trigger automatically implements a poison queue mechanism. By setting the 'maxDequeueCount' property in the host.json file to 5, the runtime will dequeue a message up to 5 times; after the 5th failed attempt, the message is automatically moved to the associated poison queue (named {originalqueue}-poison). This ensures at-least-once processing and retry handling without custom code.

Exam trap

The trap here is that candidates often think they need to write custom retry logic (Option B) or adjust visibility timeout (Option D), when Azure Functions provides a declarative configuration-based poison queue solution that handles retries and dead-lettering automatically.

How to eliminate wrong answers

Option A is wrong because message time-to-live (TTL) controls the maximum time a message stays in the queue before being discarded, not the number of retry attempts. Option B is wrong because implementing a custom retry policy in function code is unnecessary and error-prone; the Azure Functions runtime already provides built-in poison queue handling via configuration, and custom retries could lead to duplicate processing or missed poison queue routing. Option D is wrong because setting the visibility timeout to 5 minutes only controls how long a message is hidden after a dequeue failure, not the number of retry attempts; it does not move messages to a poison queue after repeated failures.

Practice this question →

15

MCQmedium

A Cosmos DB container for session records receives hot-partition throttling because the partition key has only five possible values. What should the developer change?

A.Increase the default TTL

B.Enable analytical store only

C.Choose a partition key with higher cardinality and even request distribution

D.Use a stored procedure for every write

AnswerC

A good partition key spreads storage and throughput across logical partitions.

Why this answer

Option C is correct because a partition key with only five values leads to hot partitions, where one or a few partitions handle the majority of requests, causing throttling. By choosing a partition key with higher cardinality (many distinct values) and even request distribution, the load is spread evenly across physical partitions, eliminating hot spots and throttling.

Exam trap

The trap here is that candidates often confuse throttling with performance tuning (TTL) or data storage (analytical store), rather than recognizing that the root cause is an insufficiently granular partition key leading to uneven request distribution.

How to eliminate wrong answers

Option A is wrong because increasing the default TTL (Time to Live) only affects how long data lives in the container; it does not change the partition key design or distribute request load, so it cannot resolve hot-partition throttling. Option B is wrong because enabling analytical store only creates a separate columnar store for analytical queries; it does not alter the transactional partition key or distribute write/read requests, so throttling persists. Option D is wrong because using a stored procedure for every write does not change the underlying partition key distribution; stored procedures execute within a single logical partition and cannot spread load across partitions, so hot partitions remain throttled.

Practice this question →

16

MCQeasy

You are developing an application that stores user-uploaded profile pictures in Azure Blob Storage. Users frequently access these pictures for the first 7 days after upload, then rarely. To minimize costs, you need to automatically delete pictures that are older than 30 days. Which Azure Storage feature should you use to achieve this?

A.Lifecycle management policy

B.Blob snapshots

C.Change feed

D.Soft delete

AnswerA

Correct. Lifecycle management policies can automatically delete blobs after a specified number of days, aligning with the requirement to delete pictures older than 30 days.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automatically tier or expire blobs based on age. By defining a rule that deletes blobs after 30 days from creation, you can remove old profile pictures without manual intervention, directly minimizing storage costs.

Exam trap

The trap here is that candidates may confuse soft delete (which retains deleted blobs) with automatic deletion, or think change feed or snapshots can trigger deletions, when only lifecycle management provides scheduled, rule-based expiration.

How to eliminate wrong answers

Option B (Blob snapshots) is wrong because snapshots are point-in-time read-only copies of a blob, used for versioning or backup, not for automatic deletion based on age. Option C (Change feed) is wrong because it provides transaction logs of blob changes for event processing or replication, not a mechanism to delete blobs automatically. Option D (Soft delete) is wrong because it protects blobs from accidental deletion by retaining them for a specified period, but it does not automatically delete blobs based on age; it requires an explicit delete operation to trigger.

Practice this question →

17

MCQmedium

You are developing a .NET Core application that stores session state data. The data is infrequently updated but must be read quickly for every user request. You need a serverless, globally distributed storage solution with low latency reads. Which Azure storage solution should you use?

A.Azure Table Storage

B.Azure Cosmos DB with SQL API

C.Azure Redis Cache

D.Azure Blob Storage

AnswerB

Cosmos DB offers fast, predictable read latencies, global replication, and serverless capacity, ideal for session data that requires quick reads.

Why this answer

Azure Cosmos DB with SQL API is the correct choice because it provides a globally distributed, serverless database service with single-digit millisecond read latency at any scale, making it ideal for infrequently updated session state that must be read quickly for every user request. Its multi-region replication ensures low-latency reads from any location, and the SQL API offers a familiar query interface for .NET Core applications.

Exam trap

The trap here is that candidates often choose Azure Redis Cache because of its reputation for low-latency caching, but they overlook the 'serverless' and 'globally distributed' requirements, which Redis Cache does not natively satisfy without manual configuration and provisioning, whereas Cosmos DB offers these features out of the box.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a NoSQL key-value store that does not offer global distribution or guaranteed low-latency reads; it is regionally scoped and lacks the throughput and latency guarantees required for fast session reads. Option C is wrong because Azure Redis Cache is an in-memory data store that provides low-latency reads, but it is not serverless (requires provisioning and managing cache tiers) and is not inherently globally distributed; it would require additional configuration like geo-replication, and it is optimized for frequently updated data, not infrequently updated session state. Option D is wrong because Azure Blob Storage is designed for unstructured object storage with higher latency for individual reads, and it does not support the low-latency, high-frequency read patterns needed for session state per user request.

Practice this question →

18

MCQeasy

A Windows desktop application uses standard .NET file system calls such as File.ReadAllText and Directory.GetFiles. The team wants to move the file storage to Azure. The application code must not be rewritten. Which Azure storage service supports this requirement?

A.Azure Files with an SMB share mounted as a drive letter on the Windows machine

B.Azure Blob Storage with the Azure Storage SDK replacing all file system calls

C.Azure Queue Storage for staging files between producer and consumer processes

D.Azure Table Storage with the file content stored as base64-encoded entity properties

AnswerA

SMB shares exposed by Azure Files are indistinguishable from local or network drives at the OS level. The .NET file system APIs translate directly to SMB operations on the share, requiring zero code changes in the application.

Why this answer

Azure Files with an SMB share mounted as a drive letter on the Windows machine allows the existing .NET application to use standard file system calls like File.ReadAllText and Directory.GetFiles without any code changes. This is because the mounted SMB share presents itself as a local drive, and the .NET runtime interacts with it through the standard Windows file system API, which internally uses the SMB protocol (CIFS) to communicate with Azure Files. No SDK or API rewrite is required.

Exam trap

The trap here is that candidates may assume Azure Blob Storage is the only file storage option and overlook Azure Files, which is specifically designed for lift-and-shift scenarios requiring SMB-based file sharing without code changes.

How to eliminate wrong answers

Option B is wrong because Azure Blob Storage with the Azure Storage SDK would require rewriting all file system calls to use the SDK's methods (e.g., BlobClient.DownloadAsync), which violates the requirement that the application code must not be rewritten. Option C is wrong because Azure Queue Storage is a messaging service for asynchronous communication between processes, not a file storage service, and cannot be used with standard file system calls. Option D is wrong because Azure Table Storage is a NoSQL key-value store with a 64 KB entity size limit, making it impractical for storing file content as base64-encoded properties, and it does not support standard file system APIs.

Practice this question →

19

MCQeasy

You are developing a solution that uploads large files to Azure Blob Storage. Users report that uploads fail after 4 minutes. You need to ensure uploads can complete successfully. What should you do?

A.Enable soft delete and versioning on the blob container.

B.Use premium block blob storage accounts.

C.Increase the client-side timeout value in the upload request.

D.Increase the storage account scale limit.

AnswerC

The default per-block timeout is 4 minutes; increasing it allows large uploads.

Why this answer

The default client-side timeout for Azure Blob Storage uploads is 4 minutes. When uploading large files, the operation may exceed this timeout, causing the upload to fail. Increasing the client-side timeout value in the upload request extends the allowed duration, ensuring the upload completes successfully.

Exam trap

The trap here is that candidates may confuse client-side timeout with server-side timeout or storage account limits, leading them to choose options like increasing scale limits or using premium storage, which do not address the root cause of the upload failure.

How to eliminate wrong answers

Option A is wrong because enabling soft delete and versioning protects against accidental deletion or overwrites, but does not affect upload timeout limits. Option B is wrong because premium block blob storage accounts offer consistent low-latency and high transaction rates, but they do not change the default client-side timeout for upload operations. Option D is wrong because increasing the storage account scale limit raises throughput or capacity caps, but does not extend the client-side timeout for individual upload requests.

Practice this question →

20

MCQmedium

You are designing a backup solution for a virtual machine. Monthly backups are large VHD files (up to 1 TB) that must be retained for 7 years. After creation, backups are accessed only rarely (once or twice per year). You need to minimize storage cost. Which storage tier should you use for the VHD files?

A.Hot tier

B.Cool tier

C.Archive tier

D.Premium tier

AnswerC

Archive tier provides the lowest storage cost for data that is accessed less than once a year and can tolerate a retrieval time of several hours.

Why this answer

The Archive tier is the correct choice because it offers the lowest storage cost for data that is rarely accessed (once or twice per year) and has a long retention period (7 years). Azure Archive storage is optimized for data that can tolerate a retrieval latency of several hours, which is acceptable given the infrequent access pattern of these monthly backup VHD files.

Exam trap

The trap here is that candidates often choose Cool tier because they see 'backup' and think 'infrequent' but fail to recognize that 'rarely accessed' (once or twice per year) and 'long retention' (7 years) specifically point to Archive tier as the most cost-effective option, not Cool.

How to eliminate wrong answers

Option A is wrong because the Hot tier is designed for frequently accessed data and incurs higher storage costs, making it unsuitable for backups accessed only once or twice per year. Option B is wrong because the Cool tier, while cheaper than Hot, still has higher storage costs than Archive and is intended for data accessed every 30 days or more, not for annual access patterns. Option D is wrong because the Premium tier is for low-latency, high-performance workloads (e.g., I/O-intensive VMs) and has the highest cost, which is wasteful for rarely accessed backup files.

Practice this question →

21

MCQmedium

You are building an IoT solution that generates millions of small log entries (each less than 1 KB) per day. The logs are rarely read, and when they are read, they are always accessed in chronological order. You need to minimize storage costs and maximize write throughput. Which Azure Blob Storage type should you use?

A.Append Blob

B.Block Blob

C.Page Blob

D.Archive Blob

AnswerA

Correct. Append Blobs are designed for efficient append operations and sequential read, and are cost-effective for logging.

Why this answer

Append Blob is optimized for append operations, making it ideal for scenarios like logging where data is continuously added and rarely modified. It supports high-throughput writes because each append operation is atomic and does not require reading or updating existing blocks, which minimizes overhead. Since the logs are accessed in chronological order, Append Blob's sequential block structure allows efficient streaming reads without random access overhead.

Exam trap

The trap here is that candidates often choose Block Blob because it is the most common blob type for general-purpose storage, but they overlook that Append Blob is specifically designed for append-heavy workloads like logging, where write throughput and cost efficiency for small sequential writes are critical.

How to eliminate wrong answers

Option B (Block Blob) is wrong because while it supports high throughput for large objects, it requires managing block IDs and committing blocks, which adds complexity and overhead for millions of small appends; it is not optimized for frequent append-only writes. Option C (Page Blob) is wrong because it is designed for random read/write operations on fixed-size pages (512 bytes), typically used for virtual machine disks, and its write throughput is lower for small sequential appends due to page alignment requirements. Option D (Archive Blob) is wrong because it is a tier for cold data with high latency and no real-time write throughput optimization; it is meant for long-term storage after data is already written, not for active ingestion.

Practice this question →

22

Matchingmedium

Match each Azure messaging pattern to its description.

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

Concepts

Matches

Point-to-point messaging for decoupling components

Pub/sub messaging with multiple subscribers

Big data streaming ingestion service

Push notification service for mobile apps

Why these pairings

Azure offers various messaging services for different patterns.

Practice this question →

23

Multi-Selecthard

A company stores customer images in Azure Blob Storage. They need to reduce costs by automatically moving blobs that have not been accessed for 30 days to Cool tier, and after 90 days to Archive tier. They also need to delete blobs after one year. Which two Azure features should they implement? (Choose two.)

Select 1 answer

A.Azure Blob Storage lifecycle management policy

B.Azure Blob Storage object replication

C.Azure Blob Storage soft delete

D.Azure Blob Storage immutability policy

E.Azure Blob Storage versioning with a retention policy

AnswersA

Lifecycle management policies can automate tier transitions and deletions based on last modified or creation time.

Why this answer

Azure Blob Storage lifecycle management policy is the correct feature because it allows you to define rules to automatically transition blobs to cooler tiers (Cool, Archive) based on the 'last accessed' or 'last modified' time, and to delete blobs after a specified period. This directly meets the requirement to move blobs after 30 days to Cool, after 90 days to Archive, and delete after one year, without manual intervention.

Exam trap

The trap here is that candidates may confuse lifecycle management with soft delete or versioning, thinking those features can also handle automatic tiering and deletion, but they are designed for data protection and recovery, not cost-optimized tier transitions based on age.

Practice this question →

24

MCQeasy

You need to ensure that data stored in Azure Blob Storage is encrypted at rest using a customer-managed key stored in Azure Key Vault. Which feature should you configure?

A.Azure Storage encryption with customer-managed keys in Azure Key Vault

B.Azure Disk Encryption (ADE) for the storage account

C.Azure Information Protection (AIP) for the blob container

D.Azure Storage Service Encryption (SSE) with Microsoft-managed keys

AnswerA

This enables encryption at rest using a key stored in Key Vault, meeting the requirement.

Why this answer

Azure Storage encryption with customer-managed keys in Azure Key Vault allows you to use your own encryption keys to protect data at rest in Blob Storage. This feature leverages Azure Storage Service Encryption (SSE) but wraps the data encryption key with a customer-managed key stored in Azure Key Vault, providing full control over key rotation and access policies.

Exam trap

The trap here is that candidates confuse Azure Disk Encryption (ADE) with storage account encryption, or assume that default Microsoft-managed keys satisfy the requirement for customer-managed keys, when in fact you must explicitly configure customer-managed keys in Azure Key Vault.

How to eliminate wrong answers

Option B is wrong because Azure Disk Encryption (ADE) encrypts OS and data disks of virtual machines using BitLocker or DM-Crypt, not the data stored in Azure Blob Storage. Option C is wrong because Azure Information Protection (AIP) classifies and protects documents and emails with labels and rights management, not encryption at rest for blob containers. Option D is wrong because Azure Storage Service Encryption (SSE) with Microsoft-managed keys encrypts data at rest by default, but it does not allow you to use your own customer-managed keys from Azure Key Vault.

Practice this question →

25

MCQmedium

You are a developer at a global e-commerce company. The company uses Azure Blob Storage to store product images and customer uploads. The application is deployed in the East US region. You need to design a solution that meets the following requirements: - Customers upload images (up to 10 MB) that must be immediately accessible worldwide after upload. - You must minimize egress costs for data transfer from Azure to customers. - The solution must be resilient to regional outages. - You must not use any custom caching logic. Which approach should you implement?

A.Use read-access geo-redundant storage (RA-GRS) and direct customers to the secondary endpoint for reads.

B.Use Premium Block Blob storage in multiple regions and use Traffic Manager for routing.

C.Use Azure CDN from Microsoft with the storage account as origin, and enable geo-replication on the storage account.

D.Use Azure Front Door with caching enabled, and point it to a single Blob Storage account in East US.

AnswerD

Front Door caches at edges, reduces egress, and provides failover to a secondary origin if configured.

Why this answer

Option A is correct. Azure Front Door provides global load balancing and caching at edge locations, reducing latency and egress costs by serving cached content from the closest edge. It also provides regional failover.

Option B is incorrect because CDN alone does not provide regional failover or origin load balancing. Option C is incorrect because RA-GRS provides a secondary read endpoint but does not cache globally; egress costs are still incurred from the secondary region. Option D is incorrect because Premium Blob Storage does not provide global caching or failover.

Practice this question →

26

MCQmedium

You are developing a solution that uses Azure Table Storage to store time-series data. You need to query data for a specific device within a time range efficiently. Which two properties should you use as the PartitionKey and RowKey?

A.PartitionKey = timestamp, RowKey = reverse deviceId

B.PartitionKey = timestamp, RowKey = deviceId

C.PartitionKey = deviceId, RowKey = timestamp

D.PartitionKey = deviceId, RowKey = reverse timestamp

AnswerC

DeviceId as PartitionKey distributes data evenly; timestamp as RowKey allows efficient time range queries per device.

Why this answer

Option C is correct because using deviceId as the PartitionKey ensures all data for a specific device is stored in the same partition, enabling efficient point queries. Using timestamp as the RowKey allows range queries within a time range for that device, as RowKey is sorted lexicographically within a partition. This design optimizes query performance by minimizing partition scans and leveraging Azure Table Storage's natural ordering.

Exam trap

The trap here is that candidates often assume timestamp should be the PartitionKey for time-series data, but this ignores the need for partition-level query efficiency, leading to costly cross-partition scans instead of single-partition range queries.

How to eliminate wrong answers

Option A is wrong because using timestamp as the PartitionKey scatters data for the same device across multiple partitions, requiring cross-partition queries that are slower and more expensive. Option B is wrong because it also uses timestamp as the PartitionKey, causing the same cross-partition issue, and deviceId as RowKey does not support efficient time-range queries for a specific device. Option D is wrong because using a reversed timestamp as RowKey would sort data in descending order, which breaks natural time-range queries (e.g., BETWEEN) that rely on ascending lexicographic order, and the PartitionKey of deviceId is correct but the RowKey design is suboptimal.

Practice this question →

27

MCQmedium

You are developing a web application that uses Azure Files shares for storing user documents. Users complain that they sometimes see stale file listings. The application uses the SMB protocol. What should you do to ensure the file listing is always current?

A.Set the SMB_DIRECTORY_CACHE_MAX_AGE registry key to 0 on clients.

B.Enable soft delete for the file share.

C.Switch to using REST API for file listings.

D.Disable CDN caching for the storage account.

AnswerA

This disables directory caching on SMB clients, ensuring fresh listings.

Why this answer

Option A is correct because the SMB protocol caches directory listings on the client side to improve performance. By setting the SMB_DIRECTORY_CACHE_MAX_AGE registry key to 0, you disable this caching, forcing the client to always fetch the latest directory listing from the Azure file share. This ensures that users see current file listings instead of stale cached data.

Exam trap

The trap here is that candidates often confuse client-side caching with server-side features like soft delete or CDN, or assume that switching to a different API (REST) will bypass the caching issue, when in fact the root cause is the SMB protocol's built-in directory cache on the client.

How to eliminate wrong answers

Option B is wrong because soft delete is a data protection feature that recovers accidentally deleted files; it does not affect client-side caching of directory listings. Option C is wrong because switching to the REST API for file listings does not change the client-side SMB caching behavior—the issue is caused by the SMB protocol's directory cache, not the API used. Option D is wrong because CDN caching is for static content delivery and is not involved in SMB-based file share listings; disabling it would not resolve client-side SMB caching.

Practice this question →

28

MCQeasy

Your application stores user profile images in Azure Blob Storage. You need to serve these images to users with low latency from a domain name that you own. What should you use?

A.Enable static website hosting and configure a custom domain directly on the storage account.

B.Create an Azure CDN endpoint with a custom domain and point it to the blob container.

C.Configure a custom domain in Azure DNS and point it to the storage account endpoint.

D.Use Azure Front Door with a custom domain.

AnswerB

Azure CDN provides low-latency content delivery with custom domain support.

Why this answer

Option B is correct because Azure CDN provides global edge caching, which reduces latency for serving static images from Blob Storage. By configuring a custom domain on the CDN endpoint, you can serve content under your own domain name while benefiting from CDN acceleration. This combination addresses both the low-latency requirement and the custom domain ownership.

Exam trap

The trap here is that candidates often confuse Azure CDN with Azure Front Door or static website hosting, assuming any custom domain on a storage account automatically provides low latency, but only CDN adds the necessary edge caching layer for static blob content.

How to eliminate wrong answers

Option A is wrong because enabling static website hosting on a storage account serves static content (e.g., HTML, JS) but does not inherently provide low-latency edge caching; it only allows a custom domain for the static website endpoint, not for blob containers. Option C is wrong because pointing a custom domain in Azure DNS directly to the storage account endpoint (e.g., via a CNAME record) bypasses any caching layer, resulting in higher latency for users far from the storage account's primary region. Option D is wrong because Azure Front Door is a global load balancer and application delivery service optimized for HTTP(S) traffic with advanced routing and WAF, which is overkill for simple static image serving and incurs higher cost and complexity compared to CDN.

Practice this question →

29

MCQhard

Refer to the exhibit. You run the Azure CLI command to list blobs in a container that are larger than 1 MB. The command returns no results even though you know there are blobs larger than 1 MB. What is the most likely cause?

A.The JMESPath query uses backticks incorrectly

B.The storage account has hierarchical namespace enabled (Azure Data Lake Storage Gen2)

C.The --container-name parameter is case-sensitive

D.The --account-name parameter is incorrect

AnswerB

When hierarchical namespace is enabled, the blob list output uses a different schema; the 'properties' object may not exist or be structured differently, causing the query to fail.

Why this answer

The Azure CLI command uses the `az storage blob list` command with a JMESPath query to filter blobs larger than 1 MB. However, when a storage account has hierarchical namespace enabled (Azure Data Lake Storage Gen2), the blob listing API returns directory entries and file entries in a flat list, but the `az storage blob list` command does not support the hierarchical namespace by default. The command may return no results because the underlying REST API (Blob Service REST API) does not properly enumerate blobs in a Data Lake Storage Gen2 account without using the `--use-hierarchical-namespace` flag or the `az storage fs file list` command instead.

This is a known limitation where the standard blob list operation fails to list files in a hierarchical namespace-enabled account.

Exam trap

Microsoft often tests the distinction between Azure Blob Storage and Azure Data Lake Storage Gen2, specifically that the `az storage blob list` command does not work as expected in hierarchical namespace accounts, leading candidates to overlook the storage account type as the root cause.

How to eliminate wrong answers

Option A is wrong because backticks in JMESPath queries are used correctly in the command to denote a comparison value; the issue is not with backtick syntax but with the storage account type. Option C is wrong because the `--container-name` parameter in Azure CLI is not case-sensitive; container names are lowercase by convention but the CLI handles them case-insensitively. Option D is wrong because if the `--account-name` parameter were incorrect, the command would fail with an authentication or resource-not-found error, not return an empty result set.

Practice this question →

30

MCQeasy

Your company stores sensitive financial documents in Azure Blob Storage. You need to ensure that only authorized users can access the blobs, and you must avoid exposing storage account keys. You want to generate time-limited URLs that grant access to specific blobs. What should you use?

A.Shared Access Signatures (SAS)

B.Storage account access keys

C.Azure role-based access control (RBAC)

D.Managed identities for Azure resources

AnswerA

SAS tokens provide time-limited, delegated access to specific blobs.

Why this answer

Option D is correct because Shared Access Signatures (SAS) allow you to grant time-limited, specific permissions to a blob without exposing account keys. Option A is incorrect because Azure RBAC does not provide time-limited, delegated access to a specific blob. Option B is incorrect because storage account keys grant full access to the account.

Option C is incorrect because managed identities are used for service-to-service authentication, not for generating time-limited URLs.

Practice this question →

31

MCQmedium

You deploy the ARM template shown in the exhibit. After deployment, you need to change the replication to geo-redundant storage (GRS) with read access (RA-GRS). What should you do?

A.Redeploy the same template; Standard_GRS already provides geo-redundancy.

B.Set the 'supportsHttpsTrafficOnly' property to false.

C.Change the 'accessTier' to 'Cool'.

D.Update the 'sku.name' to 'Standard_RAGRS' and redeploy.

AnswerD

Standard_RAGRS provides read-access geo-redundant storage.

Why this answer

Option D is correct because the ARM template initially deploys a storage account with 'Standard_GRS' (geo-redundant storage), but to enable read access to the secondary region (RA-GRS), you must change the SKU name to 'Standard_RAGRS'. Redeploying the template with this updated property updates the replication setting to RA-GRS, which provides both geo-redundancy and read access to the secondary endpoint.

Exam trap

The trap here is that candidates confuse 'Standard_GRS' (which already provides geo-redundancy) with 'Standard_RAGRS', not realizing that read access to the secondary region requires an explicit SKU change, not just a property toggle.

How to eliminate wrong answers

Option A is wrong because 'Standard_GRS' provides geo-redundancy but does not allow read access to the secondary region; you need 'Standard_RAGRS' for read access. Option B is wrong because the 'supportsHttpsTrafficOnly' property controls whether HTTPS is required for storage account access, not replication type. Option C is wrong because changing the 'accessTier' to 'Cool' affects blob storage pricing and performance, not the replication strategy.

Practice this question →

32

MCQmedium

An app must store relational state and perform transactions across multiple tables with T-SQL support. Which Azure data service should the developer choose?

A.Azure Queue Storage

B.Azure SQL Database

C.Azure Cache for Redis

D.Azure Blob Storage

AnswerB

Azure SQL Database supports relational schema, T-SQL, and transactions.

Why this answer

Azure SQL Database is a fully managed relational database service that supports T-SQL and ACID transactions across multiple tables, making it the correct choice for storing relational state and performing transactional operations. It provides built-in high availability, automatic backups, and elastic scaling, which are essential for enterprise applications requiring consistent, multi-table transactions.

Exam trap

The trap here is that candidates often confuse Azure SQL Database with Azure Storage services (Blob, Queue, Cache) because all fall under the 'Azure storage' domain, but only Azure SQL Database provides relational, T-SQL-based transactional capabilities.

How to eliminate wrong answers

Option A is wrong because Azure Queue Storage is a message queuing service for asynchronous communication, not a relational database; it does not support T-SQL or multi-table transactions. Option C is wrong because Azure Cache for Redis is an in-memory data store used for caching and session state, lacking relational capabilities, T-SQL support, and transactional integrity across tables. Option D is wrong because Azure Blob Storage is an object storage service for unstructured data (blobs), not a relational database; it cannot execute T-SQL queries or enforce ACID transactions across tables.

Practice this question →

33

MCQmedium

You are designing a solution that needs to react to changes in an Azure Cosmos DB container in real-time. Whenever a new document is inserted or updated, a downstream service must be triggered to process the change. You want to build a serverless solution that reliably captures each change exactly once. Which Azure Cosmos DB feature should you use?

A.Stored procedures

B.T-SQL queries

C.Change feed

D.Triggers

AnswerC

The change feed provides a sequential log of changes to items in a container. Azure Functions can bind to the change feed to trigger on each change, enabling reliable real-time processing.

Why this answer

The Change feed in Azure Cosmos DB is designed to capture document-level changes (inserts and updates) in the order they occur and provides an event-driven, serverless mechanism to reliably process each change exactly once. It integrates natively with Azure Functions, enabling real-time reactions without polling or custom tracking.

Exam trap

The trap here is that candidates confuse Change feed with triggers, but triggers are synchronous and transactional, whereas Change feed provides an asynchronous, at-least-once (with idempotent handling) stream designed for event-driven architectures.

How to eliminate wrong answers

Option A is wrong because stored procedures are transactional scripts executed within the database engine, not designed for capturing or streaming changes to downstream services. Option B is wrong because T-SQL queries are used for ad-hoc data retrieval and do not provide a continuous, ordered stream of changes. Option D is wrong because triggers in Cosmos DB are pre- or post-operation hooks that run within the same transaction scope, not for decoupled, exactly-once event delivery to external services.

Practice this question →

34

Multi-Selecthard

A company stores sensitive customer data in Azure Blob Storage. They require that all access to the storage account be logged and that any access from outside the corporate network be denied. They also need to allow read access from a specific Azure web app without exposing the storage account publicly. Which three actions should be taken? (Choose three.)

Select 3 answers

A.Enable Azure Defender for Storage

B.Enable diagnostic settings for the storage account and send logs to a Log Analytics workspace

C.Assign the 'Storage Blob Data Reader' role to the web app's managed identity

D.Configure the storage account firewall to allow access only from the virtual network/subnet of the web app

E.Generate a SAS token and store it in the web app's configuration

AnswersB, C, D

This captures all requests and fulfills the logging requirement.

Why this answer

Option B is correct because enabling diagnostic settings for the storage account and sending logs to a Log Analytics workspace captures all access logs (including read, write, and delete operations) as required by the scenario. This satisfies the logging requirement without exposing the storage account publicly, as logs are sent over the Azure backbone network.

Exam trap

The trap here is that candidates often confuse Azure Defender for Storage (a security monitoring service) with diagnostic logging, or they incorrectly assume that a SAS token is the only way to grant access to a web app, overlooking managed identity and role-based access control (RBAC).

Practice this question →

35

Multi-Selecthard

Which TWO of the following are correct about Azure Cosmos DB consistency levels?

Select 2 answers

A.Strong consistency provides the highest availability.

B.Strong consistency is available in all Azure regions.

C.Session consistency is the default consistency level for all new Cosmos DB accounts.

D.Bounded staleness consistency is the default consistency level.

E.Eventual consistency is the default consistency level for all new Cosmos DB accounts.

AnswersB, E

Strong consistency is supported globally.

Why this answer

Option B is correct because Strong consistency is available in all Azure regions when the Cosmos DB account is configured to use it. However, it is important to note that Strong consistency cannot be combined with multi-region writes; it only supports a single write region. This ensures that all reads return the most recent write, but it comes at the cost of higher latency and reduced availability during regional outages.

Exam trap

Microsoft often tests the misconception that Strong consistency provides high availability, when in reality it sacrifices availability for consistency, and that Session consistency is not the default, leading candidates to incorrectly select Bounded staleness or Eventual consistency as defaults.

Practice this question →

36

MCQeasy

Your application writes temperature data to Azure Table Storage every second. You have noticed that queries for the latest readings are slower than expected. What is the most likely cause?

A.The storage account access tier is set to Cool.

B.The table name is too long.

C.The application is using an outdated version of the Azure Storage SDK.

D.The PartitionKey is not being used in the query filter.

AnswerD

Queries without PartitionKey can be slow as they scan all partitions.

Why this answer

In Azure Table Storage, queries that do not include the PartitionKey in the filter result in a full table scan, which is significantly slower than a point query that uses both PartitionKey and RowKey. Since the application writes data every second, the latest readings likely have a timestamp-based RowKey, but without filtering by PartitionKey, the query must scan all partitions, causing poor performance.

Exam trap

The trap here is that candidates often focus on SDK versions or storage tiers, but the real performance killer in Table Storage is failing to include the PartitionKey in the query filter, which forces a full table scan.

How to eliminate wrong answers

Option A is wrong because the storage account access tier (Cool vs. Hot) affects blob storage pricing and performance, not Table Storage query speed. Option B is wrong because table names in Azure Table Storage can be up to 63 characters, and length does not impact query performance.

Option C is wrong because while an outdated SDK might lack optimizations, it would not cause a fundamental performance issue like missing PartitionKey filtering; the primary bottleneck is the query design, not the SDK version.

Practice this question →

37

MCQmedium

A serverless app must react whenever audit documents are inserted or updated in Cosmos DB. Which trigger should the Azure Function use?

A.Queue trigger

B.Timer trigger

C.HTTP trigger

D.Cosmos DB trigger

AnswerD

The Cosmos DB trigger reads the change feed and invokes the function for inserts and updates.

Why this answer

The Azure Cosmos DB trigger listens to the change feed of a Cosmos DB container, which captures inserts and updates to documents. This makes it the ideal choice for reacting to audit document changes in a serverless app, as it automatically invokes the function when new or modified documents appear in the feed.

Exam trap

The trap here is that candidates may confuse the Cosmos DB trigger with a generic database trigger, forgetting that it specifically relies on the change feed and not on direct database events like stored procedures or triggers in SQL Server.

How to eliminate wrong answers

Option A is wrong because a Queue trigger responds to messages in an Azure Storage Queue, not to document changes in Cosmos DB. Option B is wrong because a Timer trigger runs on a fixed schedule (e.g., every 5 minutes) and cannot react to real-time data changes. Option C is wrong because an HTTP trigger requires an explicit HTTP request to invoke the function, and it does not automatically fire when documents are inserted or updated in Cosmos DB.

Practice this question →

38

MCQmedium

You are building a data pipeline that writes billions of small log records (each ~200 bytes) to Azure Blob Storage. The logs are always written in chronological order and are read sequentially in order. You must minimize storage cost and achieve maximum write throughput. Which blob type should you use?

A.Block blobs in the Cool tier

B.Append blobs in the Hot tier

C.Page blobs in the Premium tier

D.Block blobs in the Archive tier

AnswerB

Append blobs are designed for efficient append operations, providing high write throughput for log data. Hot tier is appropriate for frequently written data.

Why this answer

Append blobs are optimized for append operations, making them ideal for writing billions of small log records in chronological order. They support high-throughput sequential writes without the overhead of managing block IDs, and the Hot tier provides low-latency access for immediate reading, minimizing storage cost while maximizing write throughput.

Exam trap

The trap here is that candidates often choose Block blobs (Option A) thinking they are the default for any data, but they overlook the append-specific optimization and the overhead of block management for billions of small writes.

How to eliminate wrong answers

Option A is wrong because Block blobs require managing block IDs and committing blocks, which adds overhead for billions of small writes and reduces throughput; the Cool tier also incurs early deletion penalties if logs are read soon after writing. Option C is wrong because Page blobs are designed for random read/write operations (e.g., VHDs) and use a fixed 512-byte page size, which is inefficient for small log records and incurs higher costs in the Premium tier. Option D is wrong because the Archive tier has high latency for read access (hours to rehydrate) and is not suitable for logs that need to be read sequentially in order; Block blobs also suffer from the same block management overhead as Option A.

Practice this question →

39

MCQhard

Refer to the exhibit. You have an Azure Storage account with a blob container named container1. The container's public access level is set to Blob (anonymous read access for blobs only). You attempt to assign the custom role defined in the JSON using Azure PowerShell. The role assignment fails. What is the most likely reason?

A.The action 'Microsoft.Storage/storageAccounts/blobServices/containers/read' is not a valid action.

B.The principal ID is invalid.

C.The condition StringEquals expects publicAccess to be 'none', but the container has Blob (anonymous) access.

D.The resource scope is incorrectly formatted.

AnswerC

Condition fails because public access is not 'none'.

Why this answer

C is correct because the custom role includes a condition that uses the `StringEquals` operator to check that the `publicAccess` property of the container is set to `'none'`. Since `container1` has public access level set to `Blob (anonymous read access for blobs only)`, the condition evaluates to false, causing the role assignment to fail. Azure role assignments with conditions require all specified conditions to be met; otherwise, the assignment is rejected.

Exam trap

The trap here is that candidates often overlook the condition in the custom role definition and focus on the action or scope, assuming the failure is due to a syntax error or invalid principal, rather than recognizing that Azure RBAC conditions are evaluated at assignment time and can block the assignment if the resource's current state does not satisfy the condition.

How to eliminate wrong answers

Option A is wrong because `Microsoft.Storage/storageAccounts/blobServices/containers/read` is a valid Azure RBAC action that grants read access to blob containers. Option B is wrong because the principal ID is a standard GUID and there is no indication in the question that it is invalid; the failure is due to the condition, not the principal. Option D is wrong because the resource scope (e.g., `/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account}/blobServices/default/containers/container1`) is correctly formatted for a container-level role assignment.

Practice this question →

40

MCQmedium

You have an Azure Storage account that contains a blob container with thousands of small files. You need to generate a URL that allows users to download a single file for a limited time without changing the storage account's firewall rules or requiring authentication. Which approach should you use?

A.Create a Shared Access Signature (SAS) for the specific blob with a time limit

B.Provide the storage account key to the user so they can authenticate

C.Assign the user an RBAC role (e.g., Storage Blob Data Reader) and have them authenticate via Microsoft Entra ID

D.Set the blob container's public access level to Blob (anonymous read access for blobs)

AnswerA

SAS provides secure, time-limited delegated access to a specific resource without sharing the account key.

Why this answer

A Shared Access Signature (SAS) for a specific blob provides delegated, time-limited access to that blob without requiring the storage account key or changing firewall rules. By generating a SAS token with a defined expiration time and attaching it to the blob URL, users can download the file directly via HTTPS while the storage account remains secured behind its firewall and authentication requirements.

Exam trap

The trap here is that candidates often confuse a container-level SAS or public access with a service-level SAS, or mistakenly think RBAC roles can provide anonymous access, when in fact only a blob-level SAS meets the exact constraints of time-limited, single-file, no-authentication access without altering firewall rules.

How to eliminate wrong answers

Option B is wrong because providing the storage account key grants full administrative access to the entire storage account, including all containers and blobs, which violates the principle of least privilege and is not a limited-time or single-file solution. Option C is wrong because assigning an RBAC role and requiring Microsoft Entra ID authentication would still require the user to authenticate, which contradicts the requirement of 'without requiring authentication.' Option D is wrong because setting the container's public access level to Blob makes all blobs in the container anonymously readable indefinitely, which does not provide time-limited access and bypasses the need for a SAS token.

Practice this question →

41

MCQeasy

You are designing a solution that stores customer order data in Azure Table Storage. The data includes OrderID (string), CustomerID (string), OrderDate (datetime), and TotalAmount (decimal). You need to query orders for a specific customer within a date range efficiently. Which partition key and row key design should you use?

A.PartitionKey = OrderDate, RowKey = OrderID

B.PartitionKey = CustomerID, RowKey = OrderDate (inverted ticks for descending order)

C.PartitionKey = OrderDate, RowKey = CustomerID

D.PartitionKey = OrderID, RowKey = CustomerID

AnswerB

Groups orders by customer and supports efficient range queries on OrderDate.

Why this answer

Option B is correct because Azure Table Storage queries are most efficient when they use PartitionKey for exact matches and RowKey for range scans. By setting PartitionKey = CustomerID, all orders for a specific customer are stored in the same partition, allowing fast retrieval. Using RowKey = OrderDate (inverted ticks for descending order) enables efficient date-range filtering within that partition, as Azure Table Storage supports range queries on RowKey.

Exam trap

The trap here is that candidates often choose PartitionKey = OrderDate thinking it enables date-range queries, but they overlook that Azure Table Storage requires PartitionKey to be an exact match for efficient queries, and date-range filtering must be done on RowKey within a single partition.

How to eliminate wrong answers

Option A is wrong because PartitionKey = OrderDate scatters orders for the same customer across many partitions, requiring a full table scan to gather all orders for a customer. Option C is wrong because PartitionKey = OrderDate has the same scattering issue, and RowKey = CustomerID does not support efficient date-range filtering within a partition. Option D is wrong because PartitionKey = OrderID creates a unique partition per order, making it impossible to query all orders for a customer without scanning every partition.

Practice this question →

42

MCQmedium

You design an application that writes millions of small sensor readings (each ~100 bytes) to Azure Blob Storage. The data is appended to files every minute and after 7 days it is archived for compliance. You need to minimize write costs and storage costs. Which blob type and tier strategy should you use?

A.Block blobs with Hot tier and a lifecycle rule to move to Cool after 7 days.

B.Append blobs with Hot tier and a lifecycle rule to move to Archive after 7 days.

C.Page blobs with Premium tier.

D.Append blobs with Cool tier and no lifecycle rule.

AnswerB

Append blobs are ideal for append-heavy workloads, Hot tier optimizes write performance, and Archive provides the lowest cost for compliance data not accessed frequently.

Why this answer

Append blobs are optimized for append operations, making them ideal for continuously adding small sensor readings without rewriting existing data, which minimizes write costs. Moving the blobs to the Archive tier after 7 days via a lifecycle rule reduces storage costs for compliance data, as Archive is the lowest-cost tier for infrequently accessed data.

Exam trap

The trap here is that candidates often choose block blobs (Option A) assuming they are the default for all data, overlooking the append blob's specific optimization for append operations and the cost benefits of Archive tier for compliance data.

How to eliminate wrong answers

Option A is wrong because block blobs require rewriting the entire block list for each append operation, leading to higher write costs and inefficiency for millions of small appends. Option C is wrong because page blobs are designed for random read/write access (e.g., VHDs) and use Premium tier, which is expensive and unsuitable for append-heavy sensor data. Option D is wrong because using Cool tier without a lifecycle rule keeps data in Cool tier indefinitely, missing the opportunity to further reduce storage costs by moving to Archive after 7 days.

Practice this question →

43

MCQeasy

You are designing a solution to store user-uploaded images. The images are accessed infrequently (a few times per month) and must be available for download within seconds when requested. You need to minimize storage costs while meeting the access requirements. Which Azure Blob Storage access tier should you choose for the container?

A.Hot tier

B.Cool tier

C.Cold tier

D.Archive tier

AnswerB

Cool tier is ideal for data accessed infrequently (a few times per month) with low storage cost and sub‑second latency.

Why this answer

The Cool tier is optimal because the images are accessed infrequently (a few times per month) but require immediate download within seconds. Cool tier offers lower storage costs than Hot tier while maintaining low-latency access (milliseconds), meeting the access requirement without incurring the higher storage cost of Hot tier.

Exam trap

The trap here is that candidates often confuse 'infrequent access' with 'cold storage' and choose Cold or Archive tiers, failing to recognize that 'available within seconds' eliminates any tier requiring rehydration (Archive) or having a 90-day minimum duration (Cold).

How to eliminate wrong answers

Option A is wrong because the Hot tier is designed for frequent access (multiple times per day) and has higher storage costs, which would unnecessarily increase costs for infrequently accessed images. Option C is wrong because the Cold tier is intended for data accessed at most once per quarter (every 90 days) and has a higher minimum storage duration (90 days) and early deletion fee, making it cost-inefficient for monthly access patterns. Option D is wrong because the Archive tier has the lowest storage cost but requires rehydration (taking hours, not seconds) before data can be downloaded, violating the requirement that images be available within seconds.

Practice this question →

44

MCQhard

You develop a C# application that stores sensitive documents in Azure Blob Storage. You need to generate a time-limited shared access signature (SAS) that allows a client to only read and list blobs in a specific container. The SAS must be valid for exactly 1 hour from the current time. Which code snippet correctly creates the SAS? (Assume BlobServiceClient and BlobContainerClient are properly initialized.)

A.var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "c", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);

B.var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "b", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);

C.var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "c", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.All }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);

D.var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "c", StartsOn = DateTimeOffset.UtcNow.AddDays(-1), ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);

AnswerA

This correctly sets resource to 'c' for container-level SAS, includes Read and List permissions, and generates the SAS URI using the container client.

Why this answer

Option A is correct because it sets the `Resource` property to "c" for container-level SAS, uses `StartsOn` as the current UTC time, `ExpiresOn` exactly 1 hour later, and specifies only `Read` and `List` permissions via the `BlobContainerSasPermissions` enum. This combination generates a time-limited SAS URI that allows a client to read and list blobs within the specified container for exactly one hour.

Exam trap

The trap here is confusing the `Resource` property value "c" (container) with "b" (blob), leading candidates to pick Option B, and overlooking that `StartsOn` must be set to the current time (or omitted) to achieve exactly 1 hour validity, not a past time as in Option D.

How to eliminate wrong answers

Option B is wrong because it sets `Resource = "b"`, which is intended for blob-level SAS, not container-level SAS; this would generate a SAS that applies to a single blob rather than the entire container, failing the requirement to list blobs. Option C is wrong because it uses `Permissions = BlobContainerSasPermissions.All`, which grants full control (including delete, write, etc.) instead of restricting to only Read and List permissions, violating the principle of least privilege. Option D is wrong because it sets `StartsOn = DateTimeOffset.UtcNow.AddDays(-1)`, making the SAS valid from 24 hours in the past; this means the SAS is already active for a full day before the current time, not exactly 1 hour from now as required.

Practice this question →

45

MCQmedium

You are building a serverless application that needs to react to insertions and updates in an Azure Cosmos DB container. You want to process these changes using an Azure Function. Which trigger should you configure for the function?

A.Cosmos DB trigger

B.Blob trigger

C.Event Grid trigger

D.Service Bus trigger

AnswerA

The Cosmos DB trigger uses the change feed to respond to inserts and updates in the container.

Why this answer

A Cosmos DB trigger is the correct choice because it is specifically designed to react to changes in a Cosmos DB container by leveraging the change feed. The Azure Function runtime polls the change feed for inserts and updates, invoking the function with batches of documents as they occur. This provides a native, serverless integration without needing additional services.

Exam trap

The trap here is that candidates may confuse the Cosmos DB trigger with the Event Grid trigger, thinking Event Grid can directly subscribe to Cosmos DB changes, but Event Grid requires a custom event publisher or a separate Azure service like Azure Functions to bridge the change feed.

How to eliminate wrong answers

Option B is wrong because a Blob trigger reacts to changes in Azure Blob Storage (blob creation or updates), not to changes in a Cosmos DB container. Option C is wrong because an Event Grid trigger handles events from various Azure services (e.g., resource creation, blob events) but does not natively subscribe to the Cosmos DB change feed; it would require custom event publishing. Option D is wrong because a Service Bus trigger processes messages from a Service Bus queue or topic, which is a messaging system unrelated to Cosmos DB data changes.

Practice this question →

46

MCQmedium

You need to store large files that are written once and then frequently read for the first 30 days. After 30 days, the files are rarely accessed (once or twice per year) but must remain available for 5 years. You want to minimize storage costs. Which storage tier and lifecycle management rule should you apply?

A.Hot tier with a lifecycle rule to move to Cool after 30 days

B.Cool tier with a lifecycle rule to move to Archive after 30 days

C.Hot tier with a lifecycle rule to move to Archive after 30 days

D.Archive tier with a lifecycle rule to move to Cool after 30 days

AnswerA

Hot tier provides low latency for frequent reads. After 30 days, moving to Cool reduces cost while maintaining reasonable access for rare reads.

Why this answer

Option A is correct because the Hot tier is optimized for frequent reads, and the lifecycle rule moves data to the Cool tier after 30 days when access drops, balancing performance and cost. After 30 days, the files are rarely accessed, so moving them to Cool (not Archive) keeps them available for occasional reads without the high retrieval costs and latency of Archive. This minimizes storage costs while meeting the 5-year retention requirement.

Exam trap

The trap here is that candidates assume Archive is always cheapest for long-term storage, ignoring the retrieval cost and latency for the rare but annual reads, and overlook the 30-day minimum billing period in Archive.

How to eliminate wrong answers

Option B is wrong because starting in the Cool tier incurs higher write costs and lower initial performance for the first 30 days of frequent reads, which is not cost-effective. Option C is wrong because moving directly to Archive after 30 days would impose a 30-day minimum billing period and high retrieval costs for the rare but annual reads, making it more expensive than Cool. Option D is wrong because starting in the Archive tier is designed for cold data with infrequent access, but the first 30 days have frequent reads, leading to unacceptable latency and high rehydration costs.

Practice this question →

47

MCQmedium

You need to store millions of small JSON documents (each less than 1 KB) that are accessed by key. The data is read-heavy and requires low-latency access. Which Azure storage solution should you use?

A.Azure Files

B.Azure Table Storage

C.Azure Cosmos DB

D.Azure Blob Storage

AnswerC

NoSQL database with low-latency key-value access.

Why this answer

Azure Cosmos DB is the correct choice because it provides single-digit millisecond latency for point reads by key, supports automatic indexing of JSON documents, and offers a globally distributed, multi-model database service. For millions of small JSON documents accessed by key in a read-heavy workload, Cosmos DB's throughput-provisioned model and consistency levels optimize for low-latency access at scale.

Exam trap

The trap here is that candidates confuse Azure Table Storage's key-value nature with JSON document support, but Table Storage stores entities as flat rows with limited property types and no native JSON indexing, whereas Cosmos DB is purpose-built for JSON documents with automatic indexing and guaranteed low latency.

How to eliminate wrong answers

Option A is wrong because Azure Files provides SMB/NFS file shares with higher latency and is designed for shared file access, not key-value lookups on millions of small JSON documents. Option B is wrong because Azure Table Storage is a NoSQL key-value store but lacks native JSON support, automatic indexing, and single-digit millisecond latency guarantees; it is optimized for structured tabular data, not JSON documents. Option D is wrong because Azure Blob Storage is optimized for large binary objects (blobs) and has higher latency for small objects due to per-blob metadata overhead and lack of native indexing by key; it is not designed for high-throughput point reads on millions of tiny JSON documents.

Practice this question →

48

MCQmedium

An application stores customer invoices in Azure Blob Storage. Deleted blobs must be recoverable for 14 days. What should be enabled?

A.Blob soft delete with a 14-day retention period

B.Archive access tier

C.Static website hosting

D.Immutable blob legal hold

AnswerA

Blob soft delete retains deleted blobs for the configured retention period.

Why this answer

Blob soft delete protects against accidental deletion by retaining deleted blobs for a specified retention period. Enabling it with a 14-day retention period ensures that deleted invoices remain recoverable for exactly 14 days, meeting the requirement without additional cost or complexity.

Exam trap

The trap here is confusing soft delete (which recovers deleted blobs) with immutable storage (which prevents deletion or modification) or access tiers (which affect storage cost and retrieval speed, not recovery).

How to eliminate wrong answers

Option B is wrong because the Archive access tier is for cost-effective long-term storage with retrieval delays (hours), not for short-term recovery of deleted blobs. Option C is wrong because static website hosting serves web content from a container, not recover deleted blobs. Option D is wrong because an immutable blob legal hold prevents modification or deletion of blobs for legal purposes, but it does not provide a time-limited recovery window for already deleted blobs.

Practice this question →

49

MCQeasy

You need to allow a client application to read a specific blob from Azure Blob Storage for one hour, without exposing your storage account key. Which approach should you use?

A.Provide the storage account access key to the client

B.Generate a shared access signature (SAS) URI with read permission and expiry of one hour

C.Use Azure RBAC to grant the client the Storage Blob Data Reader role for one hour

D.Make the blob publicly accessible for one hour using a stored access policy

AnswerB

A SAS token provides secure, delegated access with controlled permissions and expiry, perfect for this scenario.

Why this answer

Option B is correct because a shared access signature (SAS) URI allows you to delegate limited access (read permission) to a specific blob for a defined time period (one hour) without exposing your storage account key. The SAS token is generated using the account key but does not reveal it, ensuring secure, time-bound access.

Exam trap

The trap here is that candidates may confuse RBAC with SAS, thinking RBAC can be used for temporary access, but RBAC does not support built-in expiry and requires manual revocation, whereas SAS provides precise time-bound delegation.

How to eliminate wrong answers

Option A is wrong because providing the storage account access key grants full administrative access to the entire storage account, not just a single blob, and violates the requirement to not expose the key. Option C is wrong because Azure RBAC role assignments (like Storage Blob Data Reader) are not designed for temporary, per-blob access with a one-hour expiry; they are persistent until changed and apply at the storage account, container, or blob level, but cannot be set to auto-expire after one hour without custom scripting. Option D is wrong because making the blob publicly accessible removes all access control, allowing anyone to read it indefinitely until manually changed, and does not provide a one-hour expiry mechanism.

Practice this question →

50

MCQhard

Your application writes millions of small log entries per hour to an Azure Storage account. You notice throttling errors (HTTP 503) during peak traffic. You need to minimize throttling without changing the application code. What should you do?

A.Request a storage account limit increase from Azure Support

B.Use a separate storage account for log data

C.Change the replication type to geo-redundant storage (GRS)

D.Enable soft delete on the blob container

AnswerB

Separate accounts increase aggregate limits and reduce throttling.

Why this answer

Option B is correct because using a separate storage account for log data isolates the high-volume write traffic from other workloads, distributing the request load across different storage account endpoints. Azure Storage accounts have scalability targets (e.g., up to 20,000 requests per second per account for blob storage), and splitting logs into a dedicated account prevents hitting those limits, reducing HTTP 503 throttling errors without requiring code changes.

Exam trap

The trap here is that candidates may think throttling can be resolved by increasing limits or changing replication settings, but Azure's scalability targets are fixed per account, and the only way to increase throughput without code changes is to distribute the load across multiple storage accounts.

How to eliminate wrong answers

Option A is wrong because requesting a storage account limit increase from Azure Support does not change the per-account scalability targets (e.g., ingress/egress limits, request rate limits) which are fixed by Azure's architecture; support can only increase quotas for specific resources like capacity, not throughput or request rates. Option C is wrong because changing replication type to geo-redundant storage (GRS) does not affect throttling; GRS provides durability and disaster recovery by replicating data to a secondary region, but it does not increase the request rate or throughput limits of the storage account. Option D is wrong because enabling soft delete on the blob container protects against accidental deletion by retaining deleted blobs for a retention period, but it has no impact on request throttling or storage account scalability limits.

Practice this question →

51

MCQmedium

You are designing a cost-effective solution to store log files that are accessed infrequently after 30 days. The logs must be retained for 7 years for compliance. Data must be available within 1 hour of a request. Which Azure Blob Storage access tier and lifecycle management rule should you use?

A.Use Hot tier initially, then move to Archive after 30 days, and delete after 7 years.

B.Use Archive tier immediately and set a lifecycle rule to delete after 7 years.

C.Use Cool tier initially, then move to Archive after 30 days, and delete after 7 years.

D.Use Hot tier for 30 days, then Cool tier until 90 days, then Archive tier until deletion after 7 years.

AnswerD

This balances cost and retrieval time.

Why this answer

Option D is correct because it balances cost and compliance: the Hot tier handles initial frequent writes, Cool tier reduces cost for infrequent access after 30 days, and Archive tier provides the lowest-cost storage for long-term retention while still allowing rehydration within 1 hour (via High Priority rehydration). The lifecycle rule deletes the blobs after 7 years to meet compliance requirements.

Exam trap

The trap here is that candidates often overlook the 1-hour availability requirement and choose Archive tier immediately (Option B) or skip the Cool tier (Option A), not realizing that Archive rehydration can take up to 15 hours unless High Priority is explicitly used, and that Hot tier is more cost-effective for the initial high-write period.

How to eliminate wrong answers

Option A is wrong because moving directly from Hot to Archive after 30 days skips the Cool tier, which would incur higher costs for the infrequent access period (30–90 days) compared to using Cool tier. Option B is wrong because storing logs immediately in Archive tier prevents timely access (rehydration can take up to 15 hours, exceeding the 1-hour requirement) and does not address the initial 30-day period where logs are accessed frequently. Option C is wrong because it uses Cool tier initially, but the logs are accessed frequently in the first 30 days, making Hot tier more cost-effective for writes; Cool tier has higher write costs and lower availability for frequent access.

Practice this question →

52

MCQmedium

You are a developer for a healthcare company that stores patient diagnostic images in Azure Blob Storage. The images are uploaded by medical devices and must be retained for 7 years due to regulatory requirements. After 7 years, the data must be permanently deleted. The images are accessed infrequently after the first month. You need to design a storage lifecycle management policy to minimize costs while meeting compliance. The storage account uses general-purpose v2 with LRS. The container is named 'diagnostics'. Which of the following policies should you implement?

A.Move blobs to Cool tier after 30 days, and delete after 30 days.

B.Move blobs to Cool tier after 30 days, move to Archive tier after 90 days, and delete after 7 years.

C.Move blobs to Archive tier immediately after upload, and delete after 7 years.

D.Move blobs to Cool tier after 1 year, and delete after 7 years.

AnswerB

Optimizes cost by using Cool for infrequent access, Archive for long-term retention, and deletion after compliance period.

Why this answer

Option B is correct because it aligns with the access pattern: blobs are moved to the Cool tier after 30 days (when infrequent access begins), then to the Archive tier after 90 days for long-term, low-cost storage, and finally deleted after 7 years to meet regulatory retention and deletion requirements. This minimizes costs by using the most cost-effective tier for each stage of the data lifecycle.

Exam trap

The trap here is that candidates may choose Option C thinking Archive is cheapest immediately, but they overlook the early deletion penalty and the fact that data is accessed frequently in the first month, making Cool tier more appropriate initially.

How to eliminate wrong answers

Option A is wrong because deleting after 30 days violates the 7-year retention requirement. Option C is wrong because moving blobs immediately to Archive tier incurs early deletion fees if accessed within 180 days, and the data is accessed frequently in the first month, making Archive tier cost-ineffective. Option D is wrong because moving to Cool tier after 1 year misses the opportunity to reduce costs earlier (after 30 days of infrequent access), and the Cool tier is more expensive than Archive for long-term storage.

Practice this question →

53

MCQeasy

You store application logs in Azure Blob Storage. The logs are accessed frequently for the first 7 days, then rarely. After 30 days, they must be deleted to minimize cost. Which approach should you use?

A.Manually move blobs to cool tier after 7 days and delete after 30 days using a script

B.Use blob snapshots and delete snapshots after 30 days

C.Configure a lifecycle management policy to tier to cool after 7 days and delete after 30 days

D.Use Azure Data Factory to copy old logs to archive storage and delete original

AnswerC

Lifecycle management policies automatically transition blobs between tiers and delete them based on rules, reducing cost and management overhead.

Why this answer

Option C is correct because Azure Blob Storage lifecycle management policies allow you to automatically transition blobs to a cooler tier (cool) after a specified number of days and then delete them after another period, all without manual intervention or additional services. This directly meets the requirement of frequent access for 7 days, rare access afterward, and deletion at 30 days, minimizing cost by leveraging tiered storage and automated rules.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing manual scripting (A) or a heavy orchestration tool (D), missing that Azure provides a native, policy-driven mechanism (lifecycle management) specifically designed for automated tiering and deletion based on age.

How to eliminate wrong answers

Option A is wrong because manually moving blobs with a script is error-prone, does not scale, and contradicts the principle of automation in Azure; lifecycle management provides a built-in, reliable alternative. Option B is wrong because blob snapshots are point-in-time copies used for versioning or backup, not for tiering or deletion based on age; they do not address the need to move logs to a cooler tier or delete them after 30 days. Option D is wrong because Azure Data Factory is an orchestration service for data movement and transformation, not designed for simple tiering or deletion of blobs; using it for this purpose adds unnecessary complexity and cost compared to a native lifecycle policy.

Practice this question →

54

Multi-Selecthard

Which THREE of the following are true about Azure Blob Storage access tiers? (Choose THREE.)

Select 3 answers

A.Hot tier has lower storage cost than Cool tier.

B.Archive tier allows immediate read access to blobs.

C.You can change the access tier of a blob after it has been uploaded.

D.Cool tier is suitable for data that is accessed infrequently (30+ days).

E.Archive tier has the lowest storage cost.

AnswersC, D, E

Access tier can be changed after upload.

Why this answer

Option C is correct because Azure Blob Storage allows you to change the access tier of a blob after it has been uploaded, either by directly setting the tier on the blob or using lifecycle management policies. This flexibility enables you to optimize storage costs based on changing access patterns without re-uploading data.

Exam trap

The trap here is that candidates often confuse storage cost with access cost, assuming the Hot tier is cheaper overall, or mistakenly believe Archive blobs can be read immediately after tier change, ignoring the rehydration latency.

Practice this question →

55

MCQmedium

You develop an application that stores large binary files (up to 1 GB) in Azure Blob Storage. The application must minimize latency when reading these files from different geographic regions. The files are updated infrequently (once per month) and must be read-only for the application. You need to configure the storage account for optimal read performance and cost. What should you use?

A.Use Azure Blob Storage with Premium Block Blob Storage and enable geo-replication.

B.Use Azure Blob Storage with a Content Delivery Network (CDN) endpoint.

C.Use Azure Files with a Premium tier and geo-redundant storage.

D.Use Azure Blob Storage with read-access geo-redundant storage (RA-GRS) and serve reads from the secondary region.

AnswerD

RA-GRS provides low-latency reads from a secondary region for users worldwide, and the cost is acceptable for infrequent updates.

Why this answer

Option D is correct because read-access geo-redundant storage (RA-GRS) provides a secondary read-only endpoint in a paired region, allowing the application to read from the closest region to minimize latency. Since files are updated infrequently (once per month) and are read-only, RA-GRS offers cost-effective geo-distributed read performance without the premium cost of CDN or Premium Blob Storage.

Exam trap

The trap here is that candidates often confuse RA-GRS with GRS, forgetting that only RA-GRS provides a read-only secondary endpoint for active reads, while standard GRS requires a manual failover to access the secondary region.

How to eliminate wrong answers

Option A is wrong because Premium Block Blob Storage uses SSD-backed storage optimized for low-latency writes and high transaction rates, but it does not include geo-replication by default and is significantly more expensive than standard tiers, making it cost-inefficient for infrequently updated, read-heavy large files. Option B is wrong because a CDN endpoint caches content at edge nodes to reduce latency for repeated reads, but for large binary files up to 1 GB, CDN egress costs can be high, and the first read from each edge node still requires a full fetch from the origin, which does not minimize latency as effectively as reading directly from a geographically close secondary region. Option C is wrong because Azure Files with Premium tier is designed for SMB/NFS file shares with low-latency access for enterprise applications, not for large binary blob storage, and geo-redundant storage (GRS) does not provide a read-access secondary endpoint, so reads cannot be served from the secondary region without failover.

Practice this question →

56

MCQeasy

You need to store terabytes of archival data that must be retained for 10 years. The data is accessed once or twice per year. You need to minimize storage costs. Which Azure Storage tier should you use?

A.Cool

B.Hot

C.Archive

D.Premium

AnswerC

Archive tier offers the lowest storage cost for long-term archival data with rare access.

Why this answer

The Archive tier is designed for data that is rarely accessed (a few times per year or less) and has a flexible retrieval latency of several hours, making it ideal for long-term retention of terabytes of archival data for 10 years at the lowest storage cost. It offers the lowest per-GB storage price among Azure Blob Storage tiers, directly meeting the requirement to minimize costs for infrequently accessed data.

Exam trap

The trap here is that candidates often confuse 'infrequent access' with 'archival access' and pick the Cool tier, forgetting that the Archive tier is specifically designed for data accessed only a few times per year and offers significantly lower storage costs for long-term retention.

How to eliminate wrong answers

Option A is wrong because the Cool tier is optimized for data that is accessed infrequently (about once per month) and has higher storage costs than Archive, making it more expensive for data accessed only once or twice per year. Option B is wrong because the Hot tier is designed for frequently accessed data with the highest storage cost, which would be wasteful for archival data that is rarely accessed. Option D is wrong because the Premium tier uses SSD-based storage for low-latency, high-performance scenarios (e.g., interactive workloads) and has the highest cost, making it unsuitable for minimizing storage costs for archival data.

Practice this question →

57

MCQhard

You are developing an application that writes telemetry data to Azure Table Storage. Each telemetry event is about 5 KB in size, and the application writes up to 10,000 events per second. The data is queried by device ID and timestamp range. What is the most efficient partitioning strategy to maximize write throughput and query performance?

A.Use timestamp as the partition key and device ID as the row key.

B.Use device ID as the partition key and timestamp as the row key.

C.Use device type as the partition key and timestamp as the row key.

D.Use a single partition key for all events and use timestamp as the row key.

AnswerB

This distributes writes across partitions and allows efficient range queries.

Why this answer

Option B is correct because using device ID as the partition key distributes writes across multiple partitions, avoiding throttling from a single partition's scalability limit (up to 20,000 operations per second per partition). Using timestamp as the row key enables efficient range queries for a specific device within a time window, leveraging the table's natural sort order on row key.

Exam trap

The trap here is that candidates often choose timestamp as the partition key (Option A) because they think it naturally supports time-range queries, but they overlook the severe write throttling caused by a hot partition at each timestamp second.

How to eliminate wrong answers

Option A is wrong because using timestamp as the partition key would cause all writes at the same second to hit the same partition, creating a hot partition that throttles throughput and fails to meet the 10,000 events/second requirement. Option C is wrong because device type likely has low cardinality (e.g., a few types), leading to uneven load distribution and poor query performance when filtering by device ID. Option D is wrong because a single partition key for all events creates a single partition bottleneck, severely limiting write throughput (max ~2,000 ops/sec per partition) and making queries by device ID inefficient without a secondary index.

Practice this question →

58

MCQeasy

You are developing an application that reads data from Azure Table Storage. The application must retrieve all entities for a specific partition key. Which query approach is the most efficient?

A.Query with a filter on RowKey only.

B.Query with a filter on both PartitionKey and RowKey.

C.Query all entities and filter in application code.

D.Query with a filter on PartitionKey only.

AnswerD

Querying by PartitionKey targets a single partition efficiently.

Why this answer

In Azure Table Storage, the PartitionKey is the primary index for partitioning data. Querying with a filter on PartitionKey only allows the service to perform a partition scan, which is the most efficient way to retrieve all entities within a single partition because it avoids cross-partition queries and leverages the partition-level index directly.

Exam trap

The trap here is that candidates often assume filtering on both PartitionKey and RowKey is the most efficient, but that retrieves only a single entity, not all entities for a partition, while filtering on PartitionKey alone is the correct and most efficient approach for retrieving all entities in a partition.

How to eliminate wrong answers

Option A is wrong because filtering on RowKey only forces a full table scan across all partitions, which is inefficient and incurs higher latency and cost. Option B is wrong because filtering on both PartitionKey and RowKey is overly restrictive; it retrieves only a single entity (or a small range) rather than all entities for the partition. Option C is wrong because querying all entities and filtering in application code transfers unnecessary data over the network and wastes compute resources, violating the principle of server-side filtering.

Practice this question →

59

MCQhard

Your company has a storage account with a hierarchical namespace enabled (Azure Data Lake Storage Gen2). You need to authorize an application to write data to a specific container using a managed identity. The application runs on an Azure VM with a system-assigned managed identity. Which role assignment should you use?

A.Assign the 'Storage Blob Data Contributor' role on the container to the managed identity.

B.Assign the 'Contributor' role on the storage account to the managed identity.

C.Assign the 'Storage Blob Data Reader' role on the container to the managed identity.

D.Assign the 'Owner' role on the storage account to the managed identity.

AnswerA

This role grants write access to the container's data.

Why this answer

Option A is correct because the 'Storage Blob Data Contributor' role grants read, write, and delete permissions to blob data at the container scope. For Azure Data Lake Storage Gen2 with a hierarchical namespace, this role provides the necessary ACL-based access for a managed identity to write data to a specific container, without granting control plane permissions.

Exam trap

The trap here is that candidates often confuse Azure RBAC roles (like 'Contributor' or 'Owner') with data plane roles, mistakenly thinking control plane permissions automatically grant data access, but for Azure Storage, data plane and control plane permissions are separate and require specific role assignments like 'Storage Blob Data Contributor'.

How to eliminate wrong answers

Option B is wrong because the 'Contributor' role is an Azure RBAC role that grants full management access to the storage account resource itself (control plane), but does not grant any data plane permissions to write blobs or files. Option C is wrong because the 'Storage Blob Data Reader' role only allows read access to blob data, not write access, so the application cannot write data. Option D is wrong because the 'Owner' role grants full control plane access to the storage account, including managing role assignments, but does not grant data plane write permissions by itself; it also violates the principle of least privilege by providing excessive permissions.

Practice this question →

60

Multi-Selectmedium

Which TWO authentication methods can be used to authorize access to Azure Blob Storage without requiring shared keys?

Select 2 answers

A.Shared access signature (SAS) token

B.Microsoft Entra ID (formerly Azure AD) authentication

C.Storage account access keys

D.Client certificate-based authentication

E.Managed identities for Azure resources

AnswersB, E

Entra ID authentication does not use shared keys.

Why this answer

Microsoft Entra ID (formerly Azure AD) authentication and managed identities for Azure resources are both identity-based authentication methods that do not require shared keys. Entra ID authentication uses OAuth 2.0 tokens to authorize access to Blob Storage, while managed identities provide an automatically managed identity in Entra ID for Azure resources, eliminating the need for developers to manage credentials. Both methods support role-based access control (RBAC) for fine-grained permissions.

Exam trap

Microsoft often tests the misconception that a SAS token is a keyless method, but in reality, a SAS token is generated using a shared key (account key or user delegation key), so it does not meet the 'without requiring shared keys' condition.

Practice this question →

61

MCQmedium

Refer to the exhibit. You run the Get-AzStorageAccount cmdlet and see the output above. You need to enable the hierarchical namespace feature for this storage account. What should you do first?

A.Change the replication to LRS.

B.Set the -EnableHierarchicalNamespace parameter to true on the existing account.

C.Change the access tier to Hot.

D.Delete the storage account and create a new one with -EnableHierarchicalNamespace $true.

AnswerD

HNS must be enabled at creation time.

Why this answer

The hierarchical namespace feature (which enables Azure Data Lake Storage Gen2) cannot be enabled on an existing storage account; it must be set at creation time. Therefore, you must delete the current account and create a new one with the `-EnableHierarchicalNamespace $true` parameter. Option D is correct because it follows this immutable requirement.

Exam trap

The trap here is that candidates assume `-EnableHierarchicalNamespace` is a settable property like `-AccessTier` or `-SkuName`, but Azure enforces it as a creation-only flag, making deletion and recreation the only path.

How to eliminate wrong answers

Option A is wrong because changing replication to LRS does not affect the ability to enable hierarchical namespace; replication is independent of the namespace feature. Option B is wrong because the `-EnableHierarchicalNamespace` parameter cannot be set on an existing account; it is a creation-only property and attempting to update it will fail. Option C is wrong because the access tier (Hot, Cool, Archive) is unrelated to hierarchical namespace; changing it does not enable the feature.

Practice this question →

62

MCQmedium

You are designing an Azure Table Storage table to store temperature readings from IoT devices. Each reading includes a device ID (string), timestamp (datetime), temperature value, and location. You need to optimize the table design for this query: "Retrieve all temperature readings for a specific device ID within a given one-hour time range." The query must be efficient and minimize partition scans. Which PartitionKey and RowKey combination should you use?

A.PartitionKey = device ID, RowKey = timestamp (formatted as inverted ticks)

B.PartitionKey = timestamp (rolled up to day), RowKey = device ID

C.PartitionKey = location, RowKey = device ID

D.PartitionKey = device ID + timestamp (composite), RowKey = empty

AnswerA

All readings for a device are in one partition; the sorted RowKey enables a point query range scan, minimizing partition scans.

Why this answer

Option A is correct because using device ID as the PartitionKey ensures all readings for a specific device are in the same partition, allowing efficient point queries. Using timestamp formatted as inverted ticks (e.g., DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks) as the RowKey enables range queries within a one-hour window by leveraging the lexicographic ordering of RowKey values, minimizing partition scans.

Exam trap

The trap here is that candidates often choose a composite key (Option D) thinking it uniquely identifies rows, but they overlook that Azure Table Storage requires RowKey for range queries, and an empty RowKey prevents efficient filtering within a partition.

How to eliminate wrong answers

Option B is wrong because rolling up timestamp to day as PartitionKey scatters readings for the same device across multiple partitions, requiring a partition scan for each day to retrieve data within a one-hour range, which is inefficient. Option C is wrong because using location as PartitionKey does not group readings by device ID, so querying for a specific device would require scanning all partitions, defeating the purpose of partition optimization. Option D is wrong because a composite PartitionKey of device ID + timestamp prevents efficient range queries on RowKey (empty), as Azure Table Storage requires RowKey for range filtering; without a meaningful RowKey, you cannot perform a range scan within a partition.

Practice this question →

63

MCQmedium

Your application stores user-generated content in Azure Blob Storage. You need to implement a shared access signature (SAS) that allows users to upload files to a specific container but not read or delete. The SAS must be valid for one hour. Which type of SAS should you use?

A.Account SAS

B.Service SAS

C.Stored access policy

D.User delegation SAS

AnswerB

Service SAS can be restricted to a container with only write permission.

Why this answer

A Service SAS is the correct choice because it allows you to delegate access to a specific Azure Blob Storage resource (in this case, a container) with granular permissions. You can generate a Service SAS scoped to the container with only the 'Create' and 'Write' permissions (no 'Read' or 'Delete'), and set its expiry to one hour. This meets the requirement of allowing uploads while preventing reads or deletes.

Exam trap

The trap here is that candidates often confuse 'Service SAS' with 'Account SAS' because both can be used for blobs, but the Account SAS applies to the entire storage account and cannot be restricted to a single container, whereas the Service SAS is resource-specific.

How to eliminate wrong answers

Option A is wrong because an Account SAS grants access to multiple services (blob, queue, table, file) and all resources under the storage account, making it too broad and not scoped to a single container. Option C is wrong because a stored access policy is not a type of SAS; it is a server-side policy that can be used to control SAS permissions and expiry, but the question asks for the type of SAS itself. Option D is wrong because a User delegation SAS is secured with Azure AD credentials and is used for operations like listing blobs or reading/writing with specific RBAC roles, but it is typically used for scenarios requiring finer-grained identity-based access, not for a simple time-limited upload-only SAS.

Practice this question →

64

MCQhard

You need to store billions of small telemetry data entries (each ~100 bytes) from IoT devices. The data is written once and rarely updated. You need to run analytical queries on the last 30 days of data daily. The queries scan large ranges of data by timestamp and require sub-second response times. You need the lowest storage cost while meeting query latency requirements. Which Azure Storage solution should you use?

A.Azure Blob Storage with hot access tier and Data Lake Storage Gen2.

B.Azure Table Storage with a timestamp partition key.

C.Azure Cosmos DB with SQL API and automatic indexing.

D.Azure Blob Storage with cool access tier and Azure Data Lake Storage Gen2.

AnswerD

ADLS Gen2 provides the capabilities of Blob Storage with a hierarchical namespace, enabling efficient analytical queries. Cool tier minimizes cost for data that is queried daily but infrequently modified.

Why this answer

Option D is correct because Azure Blob Storage with the cool access tier provides the lowest storage cost for data that is written once and rarely accessed, while Azure Data Lake Storage Gen2 enables hierarchical namespace and POSIX-like access, allowing efficient analytical queries on large timestamp-ranged data with sub-second response times via partitioning and parallel processing.

Exam trap

The trap here is that candidates often choose Azure Cosmos DB (Option C) for its low-latency queries, overlooking that its cost model (RU/s) makes it prohibitively expensive for scanning billions of small records, while Blob Storage with Data Lake Storage Gen2 provides the required performance at a fraction of the cost when using proper partitioning and file formats.

How to eliminate wrong answers

Option A is wrong because the hot access tier has higher storage costs than cool tier, which is unnecessary for data that is rarely updated and only queried daily on the last 30 days. Option B is wrong because Azure Table Storage with a timestamp partition key can lead to hot partitions (all writes go to the same partition) and does not support sub-second analytical queries on large ranges of data efficiently due to lack of indexing and parallel scan capabilities. Option C is wrong because Azure Cosmos DB with SQL API and automatic indexing is optimized for transactional workloads with low-latency point reads, not for large-range analytical scans; it incurs high RU costs for scanning billions of small entries, making it far more expensive than Blob Storage for this use case.

Practice this question →

65

MCQmedium

You are developing a .NET application that needs to store and retrieve large binary objects (up to 4.7 TB) in Azure Blob Storage. The application requires the lowest possible latency for reads and must support object-level tiering. Which blob type should you use?

A.Block blob

B.Archive storage account

C.Page blob

D.Append blob

AnswerA

Block blobs support large objects (up to ~4.7 TB) and offer object-level tiering, making them suitable for this scenario.

Why this answer

Block blobs are designed for storing large binary objects up to approximately 4.74 TB and support object-level tiering (Hot, Cool, Cold, Archive). They offer the lowest read latency among Azure blob types because they can be accessed directly via HTTP/HTTPS and are optimized for streaming and random read access. Object-level tiering allows you to change the access tier of individual blobs without moving the storage account, which meets the requirement for granular cost optimization.

Exam trap

The trap here is that candidates confuse storage account tiers (Hot, Cool, Archive) with blob types, or assume Page blobs are suitable for large binary objects because of their high maximum size, overlooking that Page blobs lack object-level tiering and are designed for VHDs, not general binary storage.

How to eliminate wrong answers

Option B (Archive storage account) is wrong because it is a storage account tier, not a blob type; it applies to the entire account and does not support object-level tiering—individual blobs cannot be moved between tiers within an Archive account. Option C (Page blob) is wrong because it is optimized for random read/write operations on virtual machine disks (VHDs) and has a maximum size of 8 TB, but it does not support object-level tiering and typically has higher latency for large binary object reads compared to block blobs. Option D (Append blob) is wrong because it is designed for append-only operations (e.g., logging) and does not support object-level tiering; it also has a maximum size of 195 GB, far below the 4.7 TB requirement.

Practice this question →

66

MCQmedium

You are developing a .NET Core application that uploads large files (up to 50 GB) to Azure Blob Storage. The application must support resuming uploads that are interrupted due to network failures. Which approach should you use?

A.Use an append blob and append blocks in sequence.

B.Use a block blob and upload blocks in parallel, then commit the block list.

C.Use the Put Blob API to upload the entire file in a single request.

D.Use a page blob and upload pages in sequence.

AnswerB

Block blobs support block-level operations, allowing resumable uploads by re-uploading only failed blocks.

Why this answer

Block blobs are designed for large files and support uploading blocks in parallel, which improves throughput and reliability. By uploading individual blocks and then committing the block list, you can resume an interrupted upload by re-uploading only the missing blocks, as each block is identified by a unique block ID. This approach is ideal for files up to 50 GB and aligns with Azure's recommended pattern for resumable uploads.

Exam trap

Microsoft often tests the misconception that append blobs are suitable for large file uploads because they support appending, but the trap is that append blobs lack the block-level granularity needed for resumable uploads, unlike block blobs which are explicitly designed for this scenario.

How to eliminate wrong answers

Option A is wrong because append blobs are optimized for append operations (e.g., logging) and do not support resumable uploads; if an append fails, you cannot easily resume without re-uploading the entire blob. Option C is wrong because the Put Blob API can only upload blobs up to 5 TB for block blobs, but it uploads the entire file in a single request, which is impractical for large files and does not support resumability; for files over 256 MB, Azure requires using block uploads. Option D is wrong because page blobs are designed for random read/write access (e.g., VHDs) and are not optimized for large file uploads; they do not provide a built-in mechanism for resuming interrupted uploads.

Practice this question →

67

Multi-Selecthard

Which THREE Azure Storage features can be used to enforce immutability for compliance requirements?

Select 3 answers

A.Blob versioning with delete lock policy

B.Legal hold on a blob container

C.Blob immutability policy (time-based retention)

D.Soft delete for blobs

E.Storage account firewall rules

AnswersA, B, C

Versioning with delete lock can prevent permanent deletion.

Why this answer

Option A is correct because blob versioning with a delete lock policy prevents deletion of blob versions, effectively enforcing immutability by ensuring that once a version is created, it cannot be deleted or overwritten. This satisfies compliance requirements such as SEC 17a-4(f) or FINRA rules that mandate data preservation.

Exam trap

The trap here is that candidates may confuse soft delete with immutability, not realizing that soft delete only offers recovery, not prevention of deletion or modification, which is required for true compliance immutability.

Practice this question →

68

MCQhard

You are designing a solution that stores sensitive customer data in Azure Blob Storage. The data must be encrypted at rest using a customer-managed key (CMK) stored in Azure Key Vault. Additionally, the solution must support automatic key rotation every 90 days. You need to configure the encryption settings. Which combination of Azure services and features should you use?

A.Use Azure Information Protection to encrypt the blobs with a customer-managed key.

B.Use Azure Disk Encryption with Azure Key Vault to encrypt the storage account.

C.Use Azure Storage Service Encryption (SSE) with Microsoft-managed keys and enable automatic key rotation.

D.Use Azure Storage encryption with a customer-managed key stored in Azure Key Vault. Configure a key rotation policy in Key Vault to rotate the key every 90 days.

AnswerD

This supports CMK and automatic rotation via Key Vault's key rotation policy.

Why this answer

Option D is correct because Azure Storage Service Encryption (SSE) supports customer-managed keys (CMK) stored in Azure Key Vault for encrypting blob data at rest. Automatic key rotation every 90 days can be achieved by configuring a key rotation policy in Azure Key Vault, which allows you to define a rotation frequency (e.g., 90 days) and automatically generate a new key version. This meets both the CMK and automatic rotation requirements without additional services.

Exam trap

The trap here is that candidates confuse Azure Disk Encryption (for VMs) with Azure Storage encryption (for Blob Storage), or assume that Microsoft-managed keys can be configured to meet a customer-controlled rotation schedule, when in fact only customer-managed keys in Key Vault allow custom rotation policies.

How to eliminate wrong answers

Option A is wrong because Azure Information Protection is a classification and labeling service for data protection policies, not an encryption mechanism for Azure Blob Storage at rest; it does not integrate with Azure Storage SSE for CMK. Option B is wrong because Azure Disk Encryption encrypts virtual machine disks (OS and data disks) using BitLocker or DM-Crypt, not Azure Blob Storage data; it is designed for IaaS VMs, not PaaS storage services. Option C is wrong because it specifies Microsoft-managed keys, which do not satisfy the customer-managed key requirement; automatic key rotation with Microsoft-managed keys is handled by Azure, but the customer cannot control the key material or rotation schedule.

Practice this question →

69

MCQeasy

You need to grant a user from another Microsoft Entra ID tenant access to a specific blob container in your Azure Storage account. The solution must use Azure RBAC and minimize administrative overhead. What should you do?

A.Generate a shared access signature (SAS) with read permissions for the container.

B.Invite the user as a guest in your Microsoft Entra ID tenant and assign the Storage Blob Data Reader role to the container.

C.Add the user as a Storage Blob Data Reader at the storage account level.

D.Share the storage account key with the user.

AnswerB

B2B collaboration enables cross-tenant RBAC.

Why this answer

Option B is correct because it uses Azure RBAC to grant cross-tenant access by inviting the user as a guest in your Microsoft Entra ID tenant, then assigning the Storage Blob Data Reader role at the container scope. This minimizes administrative overhead by leveraging existing role assignments without managing shared keys or SAS tokens, and it follows the principle of least privilege by scoping access to a specific container.

Exam trap

The trap here is that candidates often confuse RBAC with shared access signatures or account keys, assuming that any cross-tenant access requires a SAS token, when in fact Azure AD B2B collaboration with RBAC is the correct, low-overhead solution.

How to eliminate wrong answers

Option A is wrong because a shared access signature (SAS) does not use Azure RBAC; it uses a token-based delegation that requires manual token management and expiration, increasing administrative overhead. Option C is wrong because adding the user as a Storage Blob Data Reader at the storage account level grants access to all containers in the account, violating the requirement to scope access to a specific container. Option D is wrong because sharing the storage account key grants full administrative access to the entire storage account, bypassing RBAC entirely and creating a severe security risk.

Practice this question →

70

MCQhard

A storage account for thumbnail metadata must allow an application to read only blobs under one container for two hours. The application should not receive the account key. What should be issued? The design must avoid adding custom operational scripts.

A.A public access level on the container

B.A service SAS scoped to the container with read permission and expiry

C.A management group assignment

D.The storage account access key

AnswerB

A service SAS can grant limited, time-bound permissions without exposing account keys.

Why this answer

A service SAS (Shared Access Signature) scoped to a specific container with read permission and an expiry time of two hours meets the requirement: it grants time-limited read access to blobs under that container without exposing the account key. The SAS token is issued to the application, which can then use it to authenticate requests directly to Azure Blob Storage, avoiding the need for custom scripts.

Exam trap

The trap here is that candidates may confuse a service SAS with a public access level (Option A) because both allow read access, but they fail to recognize that public access is permanent and unrestricted, whereas a SAS provides time-limited, scoped access without exposing the account key.

How to eliminate wrong answers

Option A is wrong because setting a public access level on the container would allow anonymous read access indefinitely, not for a limited two-hour period, and it does not control which application can read—it's open to anyone. Option C is wrong because a management group assignment is an Azure RBAC construct for organizing subscriptions and managing governance at scale; it does not provide time-bound, scoped access to blob containers. Option D is wrong because providing the storage account access key grants full administrative access to the entire storage account (including all containers, write/delete operations) and cannot be scoped to a single container or limited to two hours; it also violates the requirement that the application should not receive the account key.

Practice this question →

71

MCQmedium

You are developing an IoT solution that stores device metadata (device ID, location, firmware version, last seen timestamp) in Azure Table Storage. Each device has a unique DeviceId and a Timestamp. You need to design the PartitionKey and RowKey to optimize query performance for the following query: Retrieve all firmware versions for devices in a specific city that were last seen within the last 24 hours. The query must be efficient (partition scan minimized). Which key design is most appropriate?

A.PartitionKey = City, RowKey = DeviceId_Timestamp (e.g., "device123_2023-10-01T12:00:00")

B.PartitionKey = City, RowKey = Inverted timestamp (e.g., DateTime.MaxValue.Ticks - Timestamp.Ticks)

C.PartitionKey = DeviceId, RowKey = Timestamp

D.PartitionKey = City, RowKey = DeviceId

AnswerB

This design keeps all devices from the same city in one partition (efficient for city filtering). The row key, when sorted in ascending order, brings the most recent timestamps first. You can use a range query on the row key to get devices with last seen within the last 24 hours by comparing against the inverted timestamp of 24 hours ago.

Why this answer

Option B is correct because it uses City as the PartitionKey, ensuring all devices in the same city are in a single partition, and an inverted timestamp as the RowKey, which allows efficient range queries for the last 24 hours. Azure Table Storage sorts entities by RowKey within a partition, so querying for RowKey values greater than the inverted timestamp for 24 hours ago retrieves only the relevant rows without scanning the entire partition.

Exam trap

The trap here is that candidates often choose Option D (PartitionKey = City, RowKey = DeviceId) because it groups by city, but they overlook that the timestamp filter would still require a full partition scan, failing the 'minimized partition scan' requirement.

How to eliminate wrong answers

Option A is wrong because using DeviceId_Timestamp as the RowKey does not support efficient range queries by timestamp; the query would need to scan all rows in the partition to filter by timestamp. Option C is wrong because PartitionKey = DeviceId scatters each device into its own partition, requiring a full table scan across all partitions to find devices in a specific city and timestamp range. Option D is wrong because RowKey = DeviceId does not allow efficient timestamp filtering; the query would still need to scan all rows in the city partition to find those within the last 24 hours.

Practice this question →

72

MCQeasy

Refer to the exhibit. You are analyzing the Azure Blob Storage service properties configured for a storage account. A web application hosted at https://www.contoso.com attempts to make a PUT request to a blob. The request fails with a CORS error. What is the most likely cause?

A.The request includes a header that is not in the allowed headers list.

B.The request's Origin header does not match the allowed origin.

C.The CORS rule does not include the DELETE method.

D.The exposedHeaders list does not include a required response header.

AnswerB

CORS requires the Origin header to match an allowed origin.

Why this answer

The CORS error occurs because the request's Origin header (https://www.contoso.com) does not match any allowed origin in the CORS rule. Azure Blob Storage enforces exact string matching for the Origin header against the allowed origins list; a mismatch causes the browser to block the PUT request. Since the question states the request fails with a CORS error and the exhibit shows allowed origins that do not include https://www.contoso.com, this is the most likely cause.

Exam trap

The trap here is that candidates often assume CORS errors are always caused by missing methods or headers, but the most common cause is a mismatch between the request's Origin header and the allowed origins list, especially when the allowed origins are not configured to include the exact domain of the web application.

How to eliminate wrong answers

Option A is wrong because if a header not in the allowed headers list is included, the browser would send a preflight OPTIONS request and fail with a CORS error, but the question specifies a PUT request, which typically does not trigger a preflight unless custom headers are used; however, the exhibit shows allowed headers are set to '*', so header mismatch is unlikely. Option C is wrong because the CORS rule not including the DELETE method would only affect DELETE requests, not PUT requests; the error is for a PUT request, so method mismatch is irrelevant. Option D is wrong because exposedHeaders only controls which response headers the browser exposes to the client, not whether the request itself is allowed; missing exposed headers would not cause a CORS error on a PUT request.

Practice this question →

73

MCQeasy

You are developing an application that writes log entries to Azure Blob Storage. Each log entry is approximately 500 bytes, and you expect to generate millions of entries per day. The logs are rarely read, and when they are read, you need to retrieve ranges of logs sequentially. Which blob type should you use to minimize storage costs and maximize write throughput?

A.Block blobs

B.Append blobs

C.Page blobs

D.Azure Files shares

AnswerB

Append blobs are specifically designed for append operations, providing high write throughput and low cost per write. They are ideal for streaming log data where new entries are continuously added.

Why this answer

Append blobs are optimized for append operations, making them ideal for write-heavy, sequential logging scenarios. Each append operation adds data to the end of the blob, achieving high write throughput without the overhead of managing block lists. Since logs are rarely read and accessed sequentially, append blobs minimize storage costs compared to block blobs (which require block management overhead) and page blobs (which are designed for random access and are more expensive).

Exam trap

The trap here is that candidates often choose block blobs because they are the default and most familiar blob type, overlooking that append blobs are specifically designed for append-heavy workloads like logging and provide better write throughput without block management overhead.

How to eliminate wrong answers

Option A is wrong because block blobs require managing block IDs and committing block lists, which adds overhead for frequent small writes (500 bytes each) and reduces write throughput for high-volume logging. Option C is wrong because page blobs are designed for random read/write access (like VHDs) and are priced higher per GB, making them cost-inefficient for sequential log storage. Option D is wrong because Azure Files shares are a fully managed file share service based on SMB protocol, not a blob type, and are not optimized for high-frequency append operations or cost-effective log storage.

Practice this question →

74

MCQeasy

You are building a web application that allows users to upload profile pictures. The images are up to 5 MB in size and must be stored durably. The images are accessed infrequently after upload (a few times per month). You want to minimize storage costs while ensuring the data is available within seconds when requested. Which Azure Blob Storage access tier should you use for the blob container?

A.Hot

B.Cool

C.Archive

D.Premium

AnswerB

Cool tier is optimized for data that is accessed infrequently (a few times per month) but still needs immediate availability. It has lower storage cost than Hot tier and no retrieval delay.

Why this answer

The Cool tier is the optimal choice because the images are accessed infrequently (a few times per month) and are up to 5 MB in size. Cool tier offers lower storage cost than Hot tier while still providing sub-second latency for data retrieval, meeting the requirement of availability within seconds. Archive tier would have the lowest storage cost but incurs a multi-hour rehydration delay, violating the seconds-level availability requirement.

Exam trap

The trap here is that candidates often choose Archive tier thinking it is the cheapest option, overlooking the critical requirement that data must be available within seconds, which Archive cannot provide due to its mandatory rehydration latency.

How to eliminate wrong answers

Option A is wrong because the Hot tier is designed for frequently accessed data and has higher storage costs than Cool, making it cost-inefficient for data accessed only a few times per month. Option C is wrong because the Archive tier requires a rehydration process (taking up to 15 hours) before data can be read, which fails the requirement that data must be available within seconds when requested. Option D is wrong because the Premium tier is optimized for low-latency access (sub-millisecond) and high transaction rates, but it incurs significantly higher costs than Cool and is over-provisioned for infrequently accessed profile pictures.

Practice this question →

75

MCQhard

Your company develops a REST API for a global e-commerce platform that stores product images in Azure Blob Storage. The API uses shared access signatures (SAS) to grant temporary read access to the images. The security team requires that SAS tokens be generated using a user delegation key derived from the application's Microsoft Entra ID credentials, not from the storage account key. Additionally, the SAS must be scoped to a specific container and have a maximum validity of 1 hour. You need to implement the SAS generation in the API using the Azure Storage SDK for .NET. The application authenticates with Microsoft Entra ID using a managed identity assigned to the Azure App Service hosting the API. Which approach should you use?

A.Use the managed identity credentials to create a BlobServiceClient, then call GetUserDelegationKeyAsync to get a key, and then call BlobSasBuilder.GenerateSas using the key.

B.Use the StorageSharedKeyCredential with the storage account key to create a BlobSasBuilder and generate a SAS token.

C.Use DefaultAzureCredential to authenticate, then call GenerateUserDelegationSas on the BlobContainerClient.

D.Use the managed identity credentials to create a BlobServiceClient, then call GetUserDelegationKeyAsync, then create a BlobSasBuilder with the key and call ToSasQueryParameters.

AnswerA

This correctly obtains the user delegation key and generates a SAS with it.

Why this answer

Option A is correct because it follows the required pattern for generating a user delegation SAS: authenticate with managed identity via a BlobServiceClient, call GetUserDelegationKeyAsync to obtain a key derived from Microsoft Entra ID (not the storage account key), then use BlobSasBuilder with that key to call GenerateSas, which produces a SAS token scoped to a specific container with a 1-hour validity. This meets the security team's requirement of using Entra ID credentials and avoids exposing the storage account key.

Exam trap

The trap here is that candidates confuse the user delegation SAS workflow with the simpler account-key-based SAS, or mistakenly think that GenerateUserDelegationSas is a direct method on a container client, when in fact the key must be obtained first from the service client and then used with BlobSasBuilder.

How to eliminate wrong answers

Option B is wrong because it uses StorageSharedKeyCredential with the storage account key, which violates the requirement to use Microsoft Entra ID credentials and exposes the account key. Option C is wrong because GenerateUserDelegationSas is not a method on BlobContainerClient; the correct approach requires explicitly calling GetUserDelegationKeyAsync on the BlobServiceClient and then building the SAS with BlobSasBuilder. Option D is wrong because ToSasQueryParameters returns a Uri query string, not a SAS token string; the correct method to generate the token string is GenerateSas on BlobSasBuilder.

Practice this question →

Page 1 of 3 · 179 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Develop for Azure storage questions.

Start 20-question session