Courseiva

CCNA Develop for Azure storage Questions

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

Practice these questionsDomain overviewAll 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

Enabling an immutability policy with time-based retention places blobs into a Write Once, Read Many (WORM) state for a specified duration. This prevents any modification or deletion of the blob data, including metadata and properties, until the retention period expires. This feature is specifically designed to meet stringent regulatory compliance requirements by ensuring data integrity and non-repudiation over long periods.

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

Azure Blob Storage with Append Blobs is specifically designed for efficient, cost-effective ingestion of log data and other append-only workloads, making it ideal for terabyte-scale datasets. An immutable blob policy, configured as a time-based retention or legal hold, ensures Write Once, Read Many (WORM) compliance by preventing any modification or deletion of data for a specified period, meeting stringent regulatory requirements.

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

Using a queue output binding together with a queue trigger input binding leverages the Azure Functions runtime's transactional behavior. When a function has a queue trigger, the incoming message is kept in the queue until the function completes successfully. If the function fails after writing to the output queue (e.g., a crash or exception), the output binding write is rolled back (not committed), and the input message is not deleted from the source queue.

This ensures no message is lost: the output message is never written if the function fails, and the input message remains for retry. Without the queue trigger, if the function were triggered by another source (e.g., HTTP), a failure after the output write could still result in the output message being committed (since the function completes), but the context of the operation might be lost. The queue trigger input binding provides the necessary atomicity for this specific scenario.

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 option correctly implements the principle of least privilege by assigning specific roles at the container level. The 'Storage Blob Data Reader' role on the source container allows the function to retrieve images, while the 'Storage Blob Data Contributor' role on the destination container enables it to write processed images and potentially read/delete intermediate files. This granular access ensures the function has precisely the permissions needed without over-provisioning.

Why this answer

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

The Storage Blob Data Contributor role is designed to provide comprehensive data access for blobs. When this role is assigned at the scope of container c1, it grants the assigned principal the necessary permissions to perform read, write, and delete operations on blobs exclusively within that specific container. This aligns with the "Contributor" designation for blob data, enabling full manipulation of the blob contents.

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

The Cool storage tier is an optimal choice for infrequently accessed data, such as images and videos, providing a balance between storage cost and immediate availability. Data stored in the Cool tier can be accessed within minutes, aligning with the requirement for quick retrieval. Coupled with Geo-Redundant Storage (GRS), it ensures robust disaster recovery by replicating data to a secondary Azure region, offering a cost-effective solution that meets both availability and redundancy needs.

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.
AnswerA, C

Correct. By setting the trigger source to EventGrid and filtering events by the 'content-type' property (e.g., 'image/jpeg', 'image/png'), the function only triggers for image blobs, avoiding unnecessary invocations for other file types.

Why this answer

Both options A and C are valid methods to ensure the Azure Function only processes image files. Option A uses an Event Grid trigger with filtering on the 'content-type' property, which allows the function to only run for blobs with image content types. Option C checks the content type inside the function and ignores non-image blobs, which also works but runs the function for all blobs.

Option B is incorrect because blob triggers do not have a 'filter' property for extensions. Option D is incorrect because the blob trigger's path pattern does not filter by extension; the function triggers for any blob in the container regardless of the file extension.

Exam trap

Candidates often mistakenly believe that blob trigger path patterns can filter by file extension (Option D), but in reality, the trigger fires for any blob in the container regardless of the pattern. The correct approaches are either using Event Grid trigger with content-type filtering or checking the content type inside the function.

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
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

Blob soft delete provides a critical data protection mechanism by allowing the recovery of blobs, snapshots, or versions that have been accidentally deleted or overwritten. When enabled, deleted data remains recoverable for a specified retention period, preventing permanent loss. This feature ensures that even if a product image is mistakenly removed, it can be restored to its state at the time of deletion, significantly mitigating data loss risks and aiding compliance.

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 →
9
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

Azure Table Storage offers a very straightforward and simple REST API, making it easy to integrate for basic key-value storage needs. A significant advantage is that it operates on a pay-as-you-go model for storage and transactions, completely eliminating the need for users to provision and manage throughput (Request Units), which simplifies operational overhead and cost management for many applications.

Why this answer

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 →
10
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 scenarios requiring fast, sequential writes to the end of a blob, making them the optimal choice for logging, auditing, and IoT data streams. Each new block is added atomically to the end of the blob, ensuring data integrity and high throughput for millions of small log entries without modifying existing content. This design minimizes transaction costs and maximizes efficiency for append-only workloads, perfectly matching the requirement.

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 →
11
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

Azure Cosmos DB is a globally distributed, multi-model database service that natively supports document data, including JSON, with a flexible schema. It automatically indexes all properties within documents, enabling powerful SQL-like query capabilities over JSON data with low-latency access. This makes it an excellent choice for solutions requiring dynamic data structures and efficient querying of document content.

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 →
12
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

The 'maxDequeueCount' property, configurable for Azure Queue Storage bindings in Azure Functions, directly controls the maximum number of times a message can be dequeued and attempted for processing before it is automatically moved to a designated poison queue. Setting 'maxDequeueCount' to 5 ensures that if a function consistently fails to process a message, it will be retried up to four additional times (five total attempts) before being sent to the poison queue for manual inspection or dead-letter processing. This is the standard, built-in mechanism for handling message processing failures and retries.

Why this answer

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 →
13
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

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 →
14
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

Azure Blob Storage lifecycle management policies enable defining rules to automatically transition blobs between access tiers or delete them after a specified period. These policies are configured at the storage account level, allowing users to set conditions based on blob age, last modified time, or creation time. For instance, a rule can be established to automatically delete profile pictures (blobs) that are older than 30 days, directly fulfilling the requirement for automated data retention and cleanup. This optimizes storage costs and ensures compliance with data retention policies.

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 →
15
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

Azure Cosmos DB with the SQL API is an ideal choice for session state due to its guaranteed single-digit millisecond latency for both reads and writes, backed by comprehensive SLAs. It offers native global distribution with multi-region write capabilities, ensuring high availability and low latency for users worldwide without complex configuration. Furthermore, its serverless capacity model allows for automatic and cost-effective scaling based on demand, perfectly suiting dynamic session data requirements.

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 →
16
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 →
17
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

When uploading large files, especially using block blobs, the client-side library often breaks the file into smaller blocks, each with its own timeout. The default per-block timeout, typically around 4 minutes, can be insufficient for very large blocks or slow network conditions, leading to premature termination of the upload. Explicitly increasing this client-side timeout value in the upload request allows more time for each block or the entire file to transfer successfully, directly addressing and resolving upload timeout errors for large files.

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 →
18
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

The Archive tier is the most cost-effective option for storing data that is rarely accessed and can tolerate retrieval times of several hours, with a minimum retention period of 180 days. It offers the lowest storage costs per GB, making it ideal for long-term backups, historical data, or compliance archives where immediate access is not critical. For monthly virtual machine backups, which are typically stored for extended periods and retrieved only in disaster recovery scenarios, the Archive tier provides the optimal balance of cost savings and acceptable recovery time.

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 →
19
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

Append Blobs are specifically optimized for append operations, making them ideal for logging scenarios like IoT telemetry where new data is continuously added to the end of a file. They are designed for high-throughput sequential writes and efficient sequential reads, ensuring cost-effectiveness and performance for millions of small log entries without needing to modify existing data blocks.

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 →
20
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 messaging patterns include Queue Storage for simple queuing, Service Bus Topics for pub-sub with filters, Event Grid for event routing, and Event Hubs for streaming. Common confusions involve attributing advanced features like dead-lettering to Queue Storage or mixing IoT scenarios with Service Bus Topics.

Practice this question →
21
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 2 answers
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, E

A lifecycle management policy offers a robust, automated solution for optimizing storage costs by defining rules to transition blobs between access tiers (Hot, Cool, Archive) or delete them based on age or last modification time. This policy directly automates the movement of less frequently accessed data to more cost-effective tiers or its permanent removal, significantly reducing storage expenses without requiring application changes or manual oversight.

Why this answer

Azure Blob Storage lifecycle management policy allows you to define rules to automatically transition blobs to Cool and Archive tiers based on last access time and delete them after one year. Additionally, versioning with a retention policy automatically removes old blob versions after a specified period, preventing unnecessary storage costs from accumulating. Together, these features optimize storage costs by managing both current blobs and their versions.

Exam trap

Candidates often think only lifecycle management is required, but versioning with a retention policy is also needed to handle blob versions that can accumulate and increase costs. Additionally, some may confuse access tier configuration (which is automatically available) as a separate feature, but it is not an option here.

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

Azure Storage encryption with customer-managed keys (CMK) in Azure Key Vault provides robust encryption at rest for blob data, allowing organizations to maintain full control over their encryption keys. By integrating with Azure Key Vault, customers can manage the lifecycle of their keys, including rotation and revocation, ensuring compliance with stringent regulatory requirements. This approach enhances the security posture by separating key management from data storage, giving customers exclusive access to the encryption keys.

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 →
23
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

Azure Front Door is a global, scalable entry-point that leverages Microsoft's global edge network to deliver web applications and content. With caching enabled, it serves content from edge locations closest to users, significantly reducing latency and egress costs from the origin Blob Storage account. Front Door also inherently provides advanced routing capabilities, including automatic failover to a secondary origin if configured, and Web Application Firewall (WAF) features, making it ideal for global e-commerce scenarios requiring high performance and availability.

Why this answer

Azure Front Door with caching enabled provides global HTTP caching at Microsoft edge nodes, which minimizes egress costs by serving cached content from the edge closest to the user. It also offers built-in regional failover for resilience, and requires no custom caching logic. This meets all requirements: immediate global accessibility, minimized egress costs, regional outage resilience, and no custom caching.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing geo-replication or multiple storage accounts, when a single storage account with a global caching layer like Azure Front Door is simpler, cheaper, and meets all requirements without custom logic.

How to eliminate wrong answers

Option A is wrong because RA-GRS secondary endpoint is read-only and not designed for low-latency global access; it also does not cache content, so egress costs are incurred for every read from the secondary region. Option B is wrong because Premium Block Blob storage in multiple regions with Traffic Manager does not provide caching, leading to higher egress costs and requiring custom logic for replication and failover. Option C is wrong because Azure CDN with geo-replicated storage adds unnecessary complexity and cost; geo-replication is not needed when CDN caching is used, and the CDN itself provides global distribution and resilience.

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

Designating `deviceId` as the `PartitionKey` ensures data is distributed across many partitions, preventing hot spots and maximizing scalability for both writes and reads. With `timestamp` as the `RowKey`, entities for a specific device are stored in chronological order within their partition. This enables highly efficient queries for a single device's data over a specific time range, leveraging the `RowKey`'s ordered nature for rapid range scans.

Why this answer

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. Option A is incorrect because using timestamp as PartitionKey scatters data across partitions, requiring cross-partition queries.

Option B is incorrect for the same reason, and also the RowKey is not optimized for range queries. Option D is incorrect because using reverse timestamp as RowKey does not improve range query efficiency over timestamp directly.

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 →
25
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

SMB clients, by default, cache directory listings to improve performance and reduce network traffic. This caching can lead to stale views of the file share if changes are made by other clients or processes. Setting the SMB_DIRECTORY_CACHE_MAX_AGE registry key to 0 on the client machines effectively disables this directory caching. This forces the client to re-query the Azure File Share for the latest directory contents every time, ensuring immediate visibility of new or modified files and folders.

Why this answer

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 →
26
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 is specifically engineered to cache static content, such as user profile images, at strategically located Points of Presence (PoPs) across the globe. When a user requests an image, it is served from the closest available edge location, dramatically reducing network latency and improving load times for global users. Furthermore, a custom domain can be seamlessly integrated with the CDN endpoint, ensuring a consistent and branded user experience.

Why this answer

Azure CDN is the best choice for serving static images from Blob Storage with low latency using a custom domain. While Azure Front Door can also serve content with low latency, it is primarily a global load balancer and application acceleration service, and for simple image serving from blob storage, CDN is more cost-effective and directly designed for caching static content. Option A (static website hosting) does not provide edge caching for low latency.

Option C (Azure DNS) only resolves the domain; it doesn't provide caching.

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 →
27
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 a storage account has hierarchical namespace enabled, effectively becoming Azure Data Lake Storage Gen2, the JSON output schema for `az storage blob list` changes significantly. Unlike standard Blob Storage, the `properties` object, or specifically `properties.creationTime`, may not exist or be structured differently within the returned JSON for each item. Consequently, the JMESPath query `properties.creationTime` will fail to find a match in the altered schema, resulting in an empty list even if blobs are present.

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 →
28
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

Shared Access Signatures (SAS) are the correct choice because they allow you to delegate access to specific blobs with granular permissions (read, write, delete) and enforce a time-limited validity period, all without exposing the storage account keys. This directly meets the requirement of generating time-limited URLs for authorized access while keeping the account keys secure.

Exam trap

Azure exam often tests the misconception that RBAC or managed identities can generate time-limited URLs, but they cannot—only SAS tokens provide the ability to create scoped, time-bound URLs without exposing account keys.

How to eliminate wrong answers

Option B is wrong because storage account access keys provide full administrative access to the entire storage account, cannot be scoped to specific blobs, and cannot be time-limited, which violates the requirement to avoid exposing keys and to grant granular, temporary access. Option C is wrong because Azure RBAC controls access at the management plane or data plane via Azure AD identities, but it does not generate time-limited URLs; it requires the caller to authenticate with Azure AD, which is not suitable for distributing short-lived, anonymous URLs to specific blobs. Option D is wrong because managed identities provide an Azure AD identity for Azure resources to authenticate to storage, but they do not generate time-limited URLs; they are used for server-to-server authentication without credential management, not for issuing time-bound access tokens to external users.

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

To enable read access to a secondary region for geo-redundant storage, the storage account SKU must be specifically configured for this capability. 'Standard_RAGRS' (Read-Access Geo-Redundant Storage) is the precise SKU designed to provide this functionality. It replicates data to a secondary region and exposes an additional, separate endpoint, allowing applications to read data directly from the secondary location even when the primary region is fully operational, which is essential for high availability and disaster recovery architectures.

Why this answer

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 →
30
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 is a fully managed relational database service that natively supports structured data with defined schemas, T-SQL querying, and robust ACID (Atomicity, Consistency, Isolation, Durability) transactions. It is specifically engineered to maintain data integrity and consistency across complex operations, making it the ideal choice for applications requiring relational state and transactional guarantees.

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 →
31
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 Azure Cosmos DB change feed provides a persistent, ordered, and sequential log of all item modifications within a container, including inserts, updates, and deletes. It acts as a durable event source, allowing external consumers, such as Azure Functions, to reliably read and process these changes in near real-time without impacting database performance. This push-based mechanism is ideal for building event-driven architectures that react to data changes for scenarios like data synchronization, materialized views, or triggering downstream processes.

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 →
32
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

Enabling diagnostic settings for the storage account allows for comprehensive logging of all requests, including successful and failed operations, authentication types, and source IP addresses. By sending these logs to a Log Analytics workspace, the company gains a centralized, queryable repository for auditing all access attempts to the sensitive data. This fully satisfies the requirement to log all access, enabling detailed monitoring, security analysis, and compliance auditing.

Why this answer

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. Assigning the 'Storage Blob Data Reader' role to the web app's managed identity provides secure, credential-less read access for the web app to the storage account, aligning with the principle of least privilege and avoiding public exposure.

Configuring the storage account firewall to allow access only from the virtual network/subnet of the web app ensures that access from outside the corporate network is denied and that the storage account is not exposed publicly, as the web app would access it via a private link or service endpoint within the allowed VNet.

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 →
33
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

In Azure Table Storage, the PartitionKey is a critical component of the primary clustered index, alongside the RowKey, determining how data is physically organized and accessed. When a query filter omits the PartitionKey, the system cannot efficiently locate the relevant data within a specific partition. Instead, it is forced to perform a full scan across all partitions in the table, leading to significantly slower query execution times, especially as the dataset grows large.

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 →
34
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 Azure Cosmos DB trigger for Azure Functions is specifically engineered to listen for changes in an Azure Cosmos DB container's change feed. It automatically processes new inserts and updates (and optionally deletes, depending on configuration) in near real-time, invoking the function for each change. This trigger efficiently leverages the change feed processor library to manage leases and distribute processing across multiple function instances, ensuring reliable and scalable event-driven reactions to data modifications without polling.

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 →
35
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 purpose-built for scenarios requiring efficient append operations, such as logging or streaming data, where new data is continuously added to the end of a blob without modifying existing content. They allow for fast, sequential writes, ensuring high throughput crucial for ingesting billions of small log entries. The Hot tier provides the lowest access latency and transaction costs, making it the most suitable choice for frequently written and immediately accessed data, optimizing both performance and operational cost for active log ingestion.

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 →
36
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

The condition explicitly requires the `publicAccess` property of the container to be set to 'None' for the permission to be granted. However, if the container is configured with 'Blob' or 'Container' anonymous access, this condition evaluates to false. Consequently, the access request is denied because the container's actual public access setting does not match the 'None' value mandated by the RBAC condition.

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 →
37
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

Creating a Shared Access Signature (SAS) for the specific blob is the correct approach because it generates a URI that grants secure, time-limited, and granular access to that single resource. This cryptographically signed token allows the user to directly access the blob via the provided URL without needing to authenticate with their own credentials or be a registered Microsoft Entra ID user. The SAS can be configured with precise permissions (e.g., read-only) and an expiration time, ensuring access is temporary and restricted to only what is necessary.

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 →
38
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

Setting CustomerID as the PartitionKey ensures that all orders belonging to a single customer are stored within the same logical partition. This design optimizes for customer-specific queries, allowing for highly efficient retrieval of all orders for a given customer. Furthermore, using OrderDate (with inverted ticks for descending order) as the RowKey enables fast range queries to fetch a customer's most recent orders or orders within a specific date range, leveraging the RowKey's sorted nature within the partition.

Why this answer

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 →
39
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 →
40
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

The Cool tier provides an optimal balance for data that is accessed infrequently, typically a few times per month, while still requiring sub-second latency for retrieval. It offers lower storage costs compared to the Hot tier, with slightly higher access costs. This tier is well-suited for user-uploaded images where immediate availability is expected upon request, but the overall access frequency is not high enough to justify the Hot tier's premium.

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 →
41
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 option correctly configures a container-level Shared Access Signature (SAS) by setting the 'Resource' type to "c", which targets the entire container. It precisely grants 'Read' and 'List' permissions, aligning with a common requirement to allow users to view container contents without modification. The 'StartsOn' and 'ExpiresOn' properties define a secure, short-lived access window starting immediately, ensuring the principle of least privilege and time-bound access for the generated URI.

Why this answer

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 →
42
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 Azure Cosmos DB trigger is the native and most efficient mechanism for building serverless applications that react to changes in a Cosmos DB container. It directly leverages the built-in change feed functionality of Cosmos DB, which provides a persistent, ordered log of all document inserts, updates, and optionally deletes. This allows an Azure Function to process data modifications in near real-time without the need for inefficient polling, making it ideal for event-driven architectures.

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 →
43
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

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 →
44
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

Azure Cosmos DB is a globally distributed, multi-model database service designed for high-performance, low-latency applications at any scale. Its native support for the document model, where JSON documents are first-class citizens, makes it perfectly suited for storing millions of small JSON documents. It guarantees single-digit millisecond latency for reads and writes, offers automatic indexing, and provides flexible APIs, ensuring efficient and rapid access to the data.

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 →
45
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 specifically addresses accidental deletion or overwrites by retaining deleted or overwritten blobs in a soft-deleted state for a user-defined period. Configuring a 14-day retention ensures that customer invoices, if accidentally deleted, can be restored to their previous state at any point within those two weeks. This feature provides a robust and straightforward recovery mechanism, making it the primary Azure Storage data protection feature for this scenario.

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 →
46
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

Generating a Shared Access Signature (SAS) URI is the most appropriate and secure method for this scenario. A SAS token provides delegated access to specific Azure Storage resources, allowing precise control over permissions (e.g., read-only), the resource itself (a specific blob), and the duration of access (one hour). This ensures the client can only perform the required action for a limited time, adhering to the principle of least privilege and minimizing security risks by not exposing full account credentials.

Why this answer

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 →
47
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

Using a separate storage account for log data is the correct approach because each Azure Storage account has its own independent set of scalability targets, including maximum request rates and ingress/egress bandwidth. By distributing high-volume workloads, such as millions of small log entries, across multiple storage accounts, the application effectively increases its aggregate throughput capacity. This strategy prevents a single account from hitting its throttling limits, ensuring consistent performance and availability for all data operations.

Why this answer

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 →
48
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 strategy provides an optimal balance between cost-effectiveness and data accessibility requirements for log files. The Hot tier ensures immediate, low-cost access for frequently used recent logs (e.g., first 30 days). Transitioning to the Cool tier for the next period (e.g., 30-90 days) reduces storage costs for data that is less frequently accessed but still potentially needed. Finally, moving to the Archive tier for long-term retention (up to 7 years) minimizes costs for rarely accessed historical data, aligning perfectly with typical log data lifecycle patterns.

Why this answer

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 →
49
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

This option provides an optimal balance between cost efficiency and compliance for healthcare data. By transitioning to the Cool tier after 30 days and then to the Archive tier after 90 days, it intelligently aligns storage costs with decreasing access frequency over time. The final deletion after 7 years perfectly satisfies the long-term data retention mandates, making it the most suitable lifecycle policy.

Why this answer

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 →
50
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

Configuring a lifecycle management policy directly addresses the requirements by providing an automated, cost-effective, and serverless solution. These policies allow defining rules that automatically transition blobs between access tiers (e.g., Hot to Cool after 7 days) and delete them (e.g., after 30 days) based on conditions like blob age or last modified time. This native Azure Blob Storage feature eliminates manual scripting, reduces operational overhead, and optimizes storage costs by ensuring data resides in the most appropriate tier.

Why this answer

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 →
51
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

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 →
52
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

Azure Blob Storage with Read-Access Geo-Redundant Storage (RA-GRS) is an excellent choice for this scenario. RA-GRS asynchronously replicates data to a secondary region and allows read access to the data in that secondary region, significantly reducing read latency for geographically dispersed users. Serving reads from the secondary region ensures global availability and improved performance for infrequent reads, while the cost remains acceptable given the infrequent update pattern and the critical need for data redundancy and global accessibility.

Why this answer

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 →
53
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

The Archive access tier is specifically engineered for long-term data retention, offering the absolute lowest storage costs in Azure Blob Storage. It is ideal for data that can tolerate several hours of retrieval latency, making it perfect for terabytes of archival data that must be retained for a decade with infrequent access requirements. This tier provides the most cost-effective solution for meeting long-term compliance and backup needs.

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 →
54
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 is the optimal design for telemetry data. Using the device ID as the partition key effectively distributes write operations across numerous partitions, as each unique device generates its own data stream. This prevents hot partitions and maximizes write throughput. Furthermore, using the timestamp as the row key within each device's partition ensures that data is stored in chronological order, enabling highly efficient range queries for a specific device's telemetry over a time period.

Why this answer

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 →
55
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

Filtering a query solely on the PartitionKey is the most efficient and recommended method for retrieving all entities within a specific partition in Azure Table Storage. This approach allows the service to directly access the targeted partition, which is stored contiguously, minimizing scan operations and maximizing read performance. It leverages the primary indexing mechanism, ensuring fast and cost-effective data retrieval for a partition's contents.

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 →
56
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

The 'Storage Blob Data Contributor' role provides comprehensive permissions to read, write, and delete blob data within the specified scope. Assigning this role at the container level to the managed identity grants the necessary data plane access to create, modify, and manage blobs and directories within that container, aligning perfectly with the requirement to interact with a hierarchical namespace. This adheres to the principle of least privilege by granting only the required data operations, not broader management capabilities.

Why this answer

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 →
57
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

Microsoft Entra ID (formerly Azure AD) authentication is a primary method for securing Azure Storage without relying on shared keys. It enables identity-based access control through Azure Role-Based Access Control (RBAC), where users, groups, or service principals are assigned specific roles to storage resources. This method leverages OAuth 2.0 tokens issued by Entra ID, providing a secure and auditable way to authorize requests without ever exposing or managing shared secrets like account 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 →
58
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

Enabling the Hierarchical Namespace (HNS) is a foundational configuration that dictates how data is organized and accessed within an Azure storage account, providing file system semantics essential for Azure Data Lake Storage Gen2. Since this property cannot be altered after an account has been provisioned, the only method to achieve HNS functionality is to delete the existing storage account. Subsequently, a brand new one must be created, explicitly specifying the `-EnableHierarchicalNamespace $true` parameter during its creation, which inherently requires migrating any data from the old account to the new one.

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 →
59
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

This design is optimal for querying a specific device's temperature history. By using 'device ID' as the PartitionKey, all temperature readings for a single device are co-located within the same physical partition, enabling highly efficient queries for that device. The 'timestamp (inverted ticks)' as RowKey ensures that entries within that partition are sorted in reverse chronological order, allowing for rapid range queries (e.g., all readings for a device within a specific time window) without incurring costly cross-partition scans.

Why this answer

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 →
60
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

A Service SAS is the most appropriate choice as it allows for highly granular control over access to a specific storage service, such as Azure Blob Storage. It can be precisely scoped to a particular container, defining exact permissions like "write-only," and setting an expiry time. This ensures that users can upload content to the designated container without gaining any other access, aligning perfectly with the principle of least privilege for this scenario.

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 →
61
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.
AnswerA

Blob Storage with Data Lake Storage Gen2 lacks native indexing for sub-second range scans over timestamped data, requiring full file scans that cannot meet the query latency requirement. It is tempting because its hot tier offers low-cost bulk storage for immutable telemetry, and it would be correct for archival or batch-processing workloads where sub-second analytical response is not demanded.

Why this answer

Azure Blob Storage with the hot access tier is suitable for data that is accessed frequently (daily queries on the last 30 days), providing lower transaction costs compared to the cool tier for active data. Azure Data Lake Storage Gen2, built on Blob Storage, 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, meeting the performance and scalability requirements at a cost-effective price point for the storage of billions of small entries.

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 →
62
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 are the standard choice for storing large amounts of unstructured object data, such as documents, images, and videos. They are optimized for streaming and parallel uploads, composed of individual blocks, and crucially support object-level tiering (Hot, Cool, Archive). This tiering capability allows for cost optimization based on access frequency, making them highly versatile for various data storage needs up to approximately 4.75 TB.

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 →
63
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 are the most suitable type for storing large files, as they allow a file to be broken down into smaller, manageable blocks. These blocks can be uploaded independently and in parallel using the `Put Block` operation, significantly accelerating the upload process. Once all blocks are successfully uploaded, the `Put Block List` operation commits them in the correct order, enabling robust resumable uploads by only re-uploading failed or missing blocks, which is critical for a 50 GB file.

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 →
64
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

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 →
65
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 option correctly leverages Azure Storage encryption with Customer-Managed Keys (CMK), providing the necessary control over the encryption key lifecycle. Storing the key in Azure Key Vault ensures secure key management and allows for configuring an automatic key rotation policy directly within Key Vault. This setup directly addresses the requirement for both data at rest encryption and scheduled key rotation, enhancing security and compliance without manual intervention.

Why this answer

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 →
66
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

Inviting the user as a guest in your Microsoft Entra ID tenant establishes a B2B collaboration relationship, allowing their external identity to be recognized within your tenant. Once the user is a guest, you can then assign Azure RBAC roles, such as 'Storage Blob Data Reader', directly to the specific container. This approach provides secure, identity-based access with granular control and adheres to the principle of least privilege, as the user only gains the necessary permissions to the specified resource.

Why this answer

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 →
67
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 →
68
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

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.

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 →
69
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 purpose-built for append operations, making them the ideal choice for logging and other data streaming scenarios where new data is continuously added to the end of a file. They allow new blocks of data to be committed sequentially to the end of the blob without modifying existing content, ensuring high write throughput and low cost per write transaction. This design provides a robust and efficient mechanism for maintaining a chronological record of events.

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 →
70
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

The Cool tier is ideal for data that is accessed infrequently, perhaps a few times per month, but still requires immediate availability with low latency. Profile pictures fit this description perfectly, as they are not constantly accessed but must load instantly when requested. This tier offers a cost-effective balance with lower storage costs than Hot and no retrieval delays, making it suitable for user-uploaded content.

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 →
71
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.
AnswerD

This option correctly identifies the initial steps of using managed identity and `GetUserDelegationKeyAsync` to retrieve the user delegation key. However, `ToSasQueryParameters` on `BlobSasBuilder` only converts the builder's configured parameters into an unsigned query string fragment. It does not perform the crucial step of signing the SAS with the user delegation key to generate a complete, cryptographically secure SAS token; that function is performed by `GenerateSas`.

Why this answer

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 ToSasQueryParameters, which produces a SAS token query string 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 a direct 'GenerateUserDelegationSas' method exists on a container client. Additionally, candidates might confuse the conceptual 'generate SAS' with the specific SDK method `ToSasQueryParameters` on `BlobSasBuilder`, which is used after obtaining the user delegation key from the service client.

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 →
72
MCQmedium

You need to store large binary files (up to 2 GB) that are frequently overwritten in place (entire file replaced). You want to minimize storage cost and write latency. Which Azure Blob Storage type should you use?

A.Block Blob
B.Page Blob
C.Append Blob
D.Archive Blob
AnswerA

Block blobs are highly optimized for storing large binary files, including those up to 2 GB, by allowing data to be uploaded in manageable blocks. This architecture enables efficient replacement of the entire blob by committing a new block list, which is crucial for scenarios requiring frequent overwrites. Their low latency and cost-effectiveness for whole-file updates make them the ideal choice.

Why this answer

Block blobs are optimized for storing large binary files (up to ~4.75 TB) and support high-throughput uploads via PutBlock and PutBlockList operations. They allow overwriting an entire blob by uploading a new set of blocks, which minimizes write latency compared to page blobs that require sector-aligned writes. Block blobs also offer lower storage cost than page blobs, making them the best choice for frequently overwritten large files.

Exam trap

The trap here is that candidates often confuse 'frequently overwritten' with 'random access' and choose Page Blob, forgetting that page blobs are optimized for small, random writes (like VHDs) and are more expensive, while block blobs are the correct choice for large file replacement with low latency and cost.

How to eliminate wrong answers

Option B (Page Blob) is wrong because page blobs are designed for random read/write access in 512-byte pages (e.g., VHDs for Azure VMs) and have higher storage costs and write latency due to sector alignment requirements, making them suboptimal for large file overwrites. Option C (Append Blob) is wrong because append blobs only support appending data to the end of the blob and do not allow overwriting existing content in place. Option D (Archive Blob) is wrong because archive blobs are for cold data with infrequent access, have high read latency (hours to rehydrate), and are not designed for frequent overwrites.

Practice this question →
73
MCQmedium

You are developing an application that writes logs to Azure Blob Storage. Each log entry is small (less than 1 KB) and you need to store millions of entries per day. You want to minimize storage costs and maximize write throughput. Which blob type should you use?

A.Block blobs with a high block size.
B.Append blobs.
C.Page blobs.
D.Block blobs with a low block size.
AnswerB

Append blobs are specifically designed and optimized for append operations, making them ideal for logging scenarios where data is continuously added to the end of a file. Each append operation is atomic, ensuring data integrity even with concurrent writes. This sequential write pattern, without requiring knowledge of the total size or complex block management, provides high throughput and efficiency for log files that grow over time.

Why this answer

Append blobs are optimized for append operations, making them ideal for logging scenarios where each log entry is appended to the blob. They provide high throughput for write-heavy, sequential append workloads and are cost-effective because they use the same block blob pricing but avoid the overhead of managing individual blocks for each small entry.

Exam trap

The trap here is that candidates often choose block blobs with a low block size (Option D) thinking it minimizes waste, but they overlook that append blobs are specifically designed for append-heavy workloads and eliminate the need for manual block management, offering better throughput and simplicity.

How to eliminate wrong answers

Option A is wrong because using a high block size (e.g., 100 MB) for small log entries (<1 KB) wastes storage and reduces write throughput due to the overhead of committing large blocks for tiny data. Option C is wrong because page blobs are designed for random read/write access (e.g., Azure VM disks) and are not optimized for append-only logging; they also incur higher costs due to premium storage pricing. Option D is wrong because while low block size reduces wasted space, block blobs still require each append to be staged as a separate block and then committed, adding latency and complexity compared to the native append operation of append blobs.

Practice this question →
74
MCQhard

You have a web application that writes user-uploaded images to Azure Blob Storage. The application uses a shared access signature (SAS) token with read and write permissions. Users report that sometimes they receive 'AuthorizationFailure' errors when uploading images, but the issue is intermittent. What is the most likely cause?

A.The blob container has a soft-delete policy that is preventing uploads
B.The storage account firewall is blocking requests from the web application's IP
C.The SAS token has expired and the application is not regenerating it before it expires
D.The SAS token was generated with an incorrect IP range restriction
AnswerC

Shared Access Signatures (SAS) are time-limited credentials that grant delegated access to Azure Storage resources. When a SAS token expires, any subsequent requests attempting to use that token will be unauthorized and fail. If the application does not proactively regenerate a new SAS token before the current one's expiration, operations will intermittently succeed until expiration, then consistently fail until a valid token is obtained, perfectly aligning with intermittent failure symptoms.

Why this answer

SAS tokens have a defined expiration time. If the application does not regenerate the token before it expires, uploads will intermittently fail with 'AuthorizationFailure' errors. The intermittent nature is explained by the token being valid for some requests and expired for others, depending on when the token was last refreshed.

Exam trap

The trap here is that candidates may confuse intermittent failures with network or firewall issues, but the key clue is 'intermittent' — which points to a time-based expiry rather than a static configuration problem like IP restrictions or soft-delete policies.

How to eliminate wrong answers

Option A is wrong because soft-delete policies do not prevent uploads; they only mark blobs as deleted after a delete operation, and uploads are unaffected. Option B is wrong because a storage account firewall blocking the web application's IP would cause persistent, not intermittent, failures for all requests from that IP. Option D is wrong because an incorrect IP range restriction would cause consistent authorization failures for all requests from outside the allowed range, not intermittent ones.

Practice this question →
75
MCQmedium

A table stores session records in Azure Table Storage. Queries frequently retrieve all records for one customer in a time range. What key design is best?

A.RowKey as a constant value
B.PartitionKey as a random GUID for every record
C.PartitionKey as customer ID and RowKey based on sortable timestamp
D.PartitionKey as the full JSON payload
AnswerC

Setting the PartitionKey as the customer ID and the RowKey based on a sortable timestamp is the optimal design for session records in Azure Table Storage. This structure ensures that all session data for a particular customer is co-located within a single partition, enabling highly efficient point queries or range queries for that customer. The sortable timestamp as the RowKey further allows for rapid retrieval of sessions within a specific time range or in chronological order, leveraging Azure Table Storage's inherent indexing capabilities for fast and cost-effective data access.

Why this answer

Azure Table Storage queries are most efficient when they target a single partition key. Using the customer ID as the PartitionKey ensures all records for a customer are in the same partition, and using a sortable timestamp (e.g., inverted ticks) as the RowKey allows efficient range queries within that partition, leveraging the table's natural index order.

Exam trap

The trap here is that candidates may think randomizing the PartitionKey improves load balancing, but for query-heavy workloads targeting a single entity group, a fixed PartitionKey is essential for performance, and Azure Table Storage handles hot partitions through other mechanisms like entity-level throttling.

How to eliminate wrong answers

Option A is wrong because using a constant RowKey value would cause all records to share the same RowKey, violating the uniqueness requirement and preventing efficient range queries. Option B is wrong because using a random GUID as the PartitionKey scatters each record across different partitions, forcing full table scans for customer-specific queries and eliminating the benefit of partition-level querying. Option D is wrong because storing the full JSON payload as the PartitionKey is not a valid key design; PartitionKey must be a string that identifies the partition, and a large payload would be inefficient and break the key's purpose of grouping related entities.

Practice this question →
Page 1 of 3 · 164 questions totalNext →

Ready to test yourself?

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

Start 20-question session