CCNA Azure Storage Questions — Page 2 of 3

MCQhard

Your application writes millions of small records (each under 1 KB) to Azure Table Storage every day. You notice that query performance degrades over time. Which design change would most improve performance?

A.Store all records in a single blob and use Blob Storage.

B.Use a hash of the timestamp as the PartitionKey to distribute writes evenly.

C.Increase the storage account's throughput limits.

D.Use a single PartitionKey and a sequential RowKey.

AnswerB

Using a hash of the timestamp as the PartitionKey is an effective strategy for distributing high-volume writes evenly across multiple partitions in Azure Table Storage. This approach prevents the creation of "hot partitions" by ensuring that records arriving in close temporal proximity are not necessarily grouped into the same physical partition. By spreading the write load, this method maximizes the overall throughput and scalability of the table, allowing the application to handle millions of small records efficiently without encountering throttling.

Why this answer

Using a hash of the timestamp as the PartitionKey distributes writes evenly across partition ranges, preventing hot partitions. Azure Table Storage scales by splitting partitions across storage nodes; sequential timestamps create a hot partition on the last node, degrading throughput. A hash ensures uniform load, maximizing the account's 20,000 IOPS per partition target.

Exam trap

The trap here is that candidates assume increasing throughput limits (Option C) or using a single partition key (Option D) will fix performance, but Azure's per-partition scaling constraints mean only distributing the partition key (Option B) addresses the hot partition bottleneck.

How to eliminate wrong answers

Option A is wrong because storing all records in a single blob eliminates the query and indexing capabilities of Table Storage, making record-level retrieval impractical and introducing a single point of contention for writes. Option C is wrong because increasing storage account throughput limits does not resolve the root cause of hot partitions; Azure enforces per-partition scaling limits (up to 2,000 entities per second) regardless of account-level limits. Option D is wrong because using a single PartitionKey with a sequential RowKey creates a hot partition on the last partition server, exactly the pattern that causes the observed degradation over time.

Practice this question →

Multi-Selecteasy

You need to grant a user access to read and write blobs in a specific container for exactly 24 hours. The user is external to your organization. Which two methods can you use? (Choose two.)

Select 2 answers

A.Create a shared access signature (SAS) token with an expiry time of 24 hours

B.Share the storage account access key with the user

C.Create an account SAS token with read and write permissions

D.Generate a user delegation SAS key using Azure AD credentials

E.Assign the 'Storage Blob Data Contributor' role to the user's Microsoft account

AnswersA, D

A service-level Shared Access Signature (SAS) token is the most appropriate solution here because it allows for granular, time-limited access to specific resources, such as a container or blob. By generating a service SAS for the target container with read and write permissions and a 24-hour expiry, the user gains the necessary access without compromising the entire storage account. This method adheres to the principle of least privilege, providing temporary, scoped access.

Why this answer

A shared access signature (SAS) token can be scoped to a specific container and granted read and write permissions, with an expiry time set to exactly 24 hours. This allows the external user to access only that container for the specified duration without exposing the storage account key or requiring Azure AD authentication.

Exam trap

The trap here is that candidates often confuse an account SAS with a service SAS, assuming an account SAS can be scoped to a single container, but in reality, an account SAS applies to the entire storage account and cannot be restricted to a specific container.

Practice this question →

MCQeasy

You need to securely connect an on-premises application to Azure Blob Storage without exposing data to the public internet. Which feature should you use?

A.IP firewall rules on the storage account

B.Azure Private Endpoint

C.Storage account access keys

D.Shared access signature (SAS) with stored access policy

AnswerB

Azure Private Endpoint establishes a private link from a virtual network (VNet) to an Azure service, such as a storage account. It assigns a private IP address from the VNet to the storage account's endpoint, making the service accessible only within that VNet or connected networks, like an on-premises environment via VPN or ExpressRoute. This completely bypasses the public internet, ensuring that all traffic remains within the Microsoft backbone and the private network, thus providing the highest level of secure, private connectivity.

Why this answer

Azure Private Endpoint uses a private IP address from your virtual network to connect to Azure Blob Storage over the Microsoft backbone network, ensuring traffic never traverses the public internet. This provides a secure, private connection for on-premises applications via VPN or ExpressRoute, meeting the requirement to avoid public exposure.

Exam trap

The trap here is that candidates often confuse IP firewall rules or SAS tokens as providing private connectivity, when in fact they only control access or authentication but still route traffic over the public internet.

How to eliminate wrong answers

Option A is wrong because IP firewall rules restrict access based on public IP addresses, but traffic still flows over the public internet, failing the 'no public internet' requirement. Option C is wrong because storage account access keys are shared secrets that authenticate requests over HTTPS, but they do not prevent data from traversing the public internet; they also pose security risks if leaked. Option D is wrong because a shared access signature (SAS) with a stored access policy provides time-limited, delegated access over HTTPS, but the data path still uses the public internet endpoint, not a private connection.

Practice this question →

MCQhard

You are developing a .NET application that stores documents in Azure Cosmos DB for NoSQL. The application requires optimistic concurrency control to prevent lost updates when multiple users edit the same document. You need to implement the mechanism using the latest SDK. What should you do?

A.Use a stored procedure that checks the document version before updating.

B.Enable the ETag property on the document and include it in the request options for replace operations.

C.Use a unique index on the document ID to prevent duplicate writes.

D.Set the consistency level to Strong for the Cosmos DB account.

AnswerB

Cosmos DB provides optimistic concurrency control through the ETag property of a document. The ETag is a system-generated value that changes on every update. By including the ETag in the ItemRequestOptions for a replace operation, the SDK sends it as an If-Match header. If the document has been modified since the ETag was retrieved, the operation fails with a PreconditionFailed (412) error. This allows the application to handle conflicts gracefully, such as by retrying or notifying the user. This is the standard and recommended approach for optimistic concurrency in Cosmos DB.

Why this answer

Optimistic concurrency in Cosmos DB is implemented by using the ETag of a document. When you retrieve a document, you get its ETag. When you replace it, you include the ETag in the request options.

If the ETag does not match the current version, the operation fails, allowing you to handle the conflict. This is the standard pattern supported by the SDK. Other options like stored procedures, consistency levels, or unique indexes do not provide the same level of concurrency control.

Exam trap

The trap here is confusing consistency levels with concurrency control; strong consistency ensures up-to-date reads but does not prevent lost updates.

Practice this question →

MCQmedium

Your IoT solution generates billions of small telemetry entries (each ~100 bytes). Data is written once and rarely updated. You need to run analytical queries on the last 30 days of data daily, scanning large ranges by timestamp, requiring sub-second response times. You want the lowest storage cost. Which Azure Storage solution should you use?

A.Azure Blob Storage

B.Azure Table Storage

C.Azure Cosmos DB

D.Azure Data Lake Storage

AnswerB

Azure Table Storage is a highly scalable and cost-effective NoSQL key-value store specifically designed for storing massive amounts of structured, non-relational data. Its architecture allows for efficient storage and retrieval of billions of small telemetry entries, leveraging PartitionKey and RowKey for rapid lookups and range queries, which is crucial for time-series data analysis without the overhead of a full relational database or higher-cost NoSQL alternatives.

Why this answer

Azure Table Storage is correct because it is a NoSQL key-value store optimized for high-volume, low-cost storage of structured data like telemetry entries. It supports efficient range queries on the partition key (e.g., timestamp) and row key, enabling sub-second scans of large date ranges. Its storage cost is the lowest among Azure storage options for this workload, as it charges only for consumed capacity with no minimum throughput commitments.

Exam trap

The trap here is that candidates often choose Azure Cosmos DB for its low-latency queries, overlooking the explicit 'lowest storage cost' requirement, which Table Storage satisfies due to its simpler architecture and lack of provisioned throughput costs.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is designed for unstructured binary or text data, not for efficient range queries on structured fields like timestamps; scanning billions of small entries would require costly and slow blob listing or external indexing. Option C is wrong because Azure Cosmos DB, while supporting fast queries, has significantly higher storage and throughput costs compared to Table Storage, making it unsuitable for the lowest storage cost requirement. Option D is wrong because Azure Data Lake Storage is optimized for big data analytics on large files (e.g., petabytes) and hierarchical namespaces, not for sub-second range queries on billions of tiny records; its cost per GB is higher than Table Storage for this scale.

Practice this question →

MCQhard

Your application uses Azure Queue Storage to process orders. Occasionally, messages are not processed and remain in the queue. You need to ensure that messages are automatically retried after a specified time if they are not deleted. What should you configure?

A.Set the message visibility timeout to a small value

B.Configure a dead-letter queue

C.Enable queue storage logging

D.Increase the message time-to-live (TTL)

AnswerA

When a message is dequeued, it becomes temporarily invisible for the duration of the visibility timeout. Setting a small visibility timeout ensures that if a worker fails to process the message and does not delete it, the message quickly reappears in the queue. This allows another worker, or the same worker after a short delay, to pick up the message for a retry attempt, making it an effective strategy for handling transient processing failures.

Why this answer

Setting the message visibility timeout to a small value ensures that if a message is not deleted after processing (i.e., the worker fails or crashes), the message becomes visible again in the queue after the short timeout. This allows other queue consumers to retry processing the message automatically. The visibility timeout controls how long a message is hidden from other consumers after being dequeued, and a small value reduces the delay before a retry occurs.

Exam trap

The trap here is that candidates often confuse the visibility timeout with the message time-to-live (TTL) or think that logging or dead-letter queues directly enable automatic retries, when in fact the visibility timeout is the key mechanism for controlling retry timing.

How to eliminate wrong answers

Option B is wrong because a dead-letter queue is used to isolate messages that have exceeded their maximum delivery count or failed processing repeatedly, not to automatically retry messages after a specified time. Option C is wrong because enabling queue storage logging only records operations for auditing and diagnostics; it does not affect message retry behavior. Option D is wrong because increasing the message time-to-live (TTL) only extends how long a message can remain in the queue before expiring; it does not control when or how messages are retried after a processing failure.

Practice this question →

MCQeasy

You need to store millions of small JSON documents (each ~1 KB) that are frequently updated by multiple concurrent users. You require low-latency access to individual documents. Which Azure Storage solution should you use?

A.Azure Blob Storage with Block blobs

B.Azure Table Storage

C.Azure Files with SMB protocol

D.Azure Cosmos DB for NoSQL

AnswerB

Azure Table Storage is a highly scalable and cost-effective NoSQL key-value store specifically designed for storing massive quantities of structured, non-relational data. It excels at handling millions of small entities, like 1KB JSON documents, by leveraging PartitionKey and RowKey for efficient lookups and queries. Its design prioritizes low-cost storage and high throughput for simple data models, making it ideal for this scenario where cost-efficiency and scale for small documents are paramount.

Why this answer

Azure Table Storage is a NoSQL key-value store optimized for storing large volumes of structured, non-relational data with low-latency access by partition key and row key. It supports millions of small JSON documents (~1 KB) and handles frequent concurrent updates via optimistic concurrency control using ETags, making it ideal for this scenario.

Exam trap

The trap here is that candidates often choose Azure Cosmos DB for NoSQL because it is a more feature-rich document database, but the question emphasizes cost-effectiveness and simplicity for high-volume, low-latency key-value access, which is exactly where Azure Table Storage excels.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage with Block blobs is designed for large, unstructured binary or text objects (up to ~4.7 TB per blob) and does not provide native key-value lookup for individual small documents; it also lacks built-in optimistic concurrency for frequent updates by multiple users. Option C is wrong because Azure Files with SMB protocol provides file-level access with network shares, not a document store; it introduces protocol overhead and is not optimized for low-latency access to millions of individual small JSON documents. Option D is wrong because Azure Cosmos DB for NoSQL, while capable of storing JSON documents, is a premium, globally distributed database service with higher cost and complexity; for this specific requirement of millions of small, frequently updated documents with low-latency access, Azure Table Storage is the more cost-effective and purpose-built solution.

Practice this question →

MCQhard

You are developing an application that writes blobs to Azure Blob Storage. The application requires high throughput and must handle transient failures. You need to implement a retry policy. Which approach should you use?

A.Use a circuit breaker pattern

B.Implement a custom retry loop with Thread.Sleep

C.Generate a SAS token with a long expiry

D.Configure the retry policy in the Azure.Storage.Blobs SDK

AnswerD

Configuring the retry policy within the Azure.Storage.Blobs SDK is the recommended and most robust approach for handling transient faults during blob write operations. The SDK's built-in retry mechanisms automatically implement best practices like exponential backoff with jitter, which intelligently increases the delay between retries and adds randomness to prevent simultaneous retries from multiple clients. This approach significantly improves application resilience and reliability by gracefully recovering from temporary service interruptions without complex custom code.

Why this answer

The Azure.Storage.Blobs SDK provides built-in retry policies (e.g., ExponentialRetry, FixedRetry) that handle transient failures automatically with configurable delays, retry counts, and backoff strategies. This is the recommended approach because it integrates directly with the SDK's client pipeline, respects service throttling, and avoids blocking threads or reinventing error handling logic.

Exam trap

The trap here is that candidates confuse the circuit breaker pattern (a resilience pattern for preventing cascading failures) with a retry policy, or they incorrectly assume that a custom Thread.Sleep loop is acceptable in modern asynchronous Azure SDK applications.

How to eliminate wrong answers

Option A is wrong because the circuit breaker pattern is designed to prevent repeated calls to a failing service by opening the circuit, not to handle transient failures with retries; it is a complementary pattern, not a retry policy. Option B is wrong because Thread.Sleep blocks the current thread synchronously, which reduces throughput and scalability in an asynchronous application; it also lacks exponential backoff and integration with Azure SDK retry logic. Option C is wrong because a SAS token with a long expiry addresses authentication and access duration, not transient failure handling; retry policies are independent of token expiry.

Practice this question →

MCQmedium

You are deploying an Azure Functions app that processes messages from an Azure Storage queue. The function must ensure that each message is processed at least once, and if processing fails, the message should be retried up to 5 times before being moved to a poison queue. Which configuration should you set?

A.Set the maxDequeueCount property in the host.json for the queue trigger to 5.

B.Manually implement a retry loop in the function code.

C.Set the visibility timeout to 5 minutes in the queue.

D.Set the message time-to-live to 5 in the queue.

AnswerA

The `maxDequeueCount` property, configured within the `host.json` file for a queue trigger, directly controls the maximum number of times an Azure Function will attempt to process a specific queue message. If the function fails to successfully process the message (e.g., due to an unhandled exception) after this many attempts, the message is automatically moved to a designated poison queue. Setting this to 5 ensures the function will retry processing the message up to five times before it is considered unprocessable and moved for further investigation.

Why this answer

The Azure Storage queue trigger's `maxDequeueCount` property in `host.json` controls the maximum number of times a message is dequeued for processing before it is moved to the poison queue. Setting it to 5 ensures that after 5 failed processing attempts, the message is automatically moved to the poison queue, satisfying the at-least-once processing and retry requirements without custom code.

Exam trap

The trap here is that candidates often confuse the `maxDequeueCount` property with other queue settings like visibility timeout or TTL, mistakenly thinking those control retry behavior, when in fact only `maxDequeueCount` governs the number of retries before poison queue escalation.

How to eliminate wrong answers

Option B is wrong because manually implementing a retry loop in the function code is unnecessary and error-prone; the Azure Functions runtime already provides built-in retry logic via the `maxDequeueCount` property, and manual loops can lead to infinite retries or improper poison message handling. Option C is wrong because setting the visibility timeout to 5 minutes only controls how long a message remains invisible after being dequeued, not the number of retry attempts; it does not limit retries or move messages to a poison queue. Option D is wrong because setting the message time-to-live (TTL) to 5 (likely meaning 5 seconds or 5 minutes) controls how long a message stays in the queue before expiring, not the retry count; expired messages are simply deleted, not moved to a poison queue.

Practice this question →

MCQeasy

You are building a solution that needs to process large CSV files uploaded to Azure Blob Storage. Each file can be up to 1 GB. You want to minimize processing time and cost. Which approach should you recommend?

A.Use Azure Data Factory to copy the data from Blob Storage to Azure SQL Database and perform transformations.

B.Use Azure Logic Apps to trigger a function that parses the CSV and inserts into Cosmos DB.

C.Download the file to an Azure VM and use a custom script to parse and insert into a database.

D.Use Azure Stream Analytics to read the CSV from Blob Storage and output to a data warehouse.

AnswerA

Azure Data Factory (ADF) is purpose-built for orchestrating and automating large-scale data movement and transformation workflows, making it ideal for batch processing large CSV files. It offers managed integration runtimes, robust connectivity to various data stores like Blob Storage and Azure SQL Database, and powerful data flow capabilities for complex transformations without writing extensive code. ADF's scalable architecture ensures efficient and reliable ingestion and processing of substantial data volumes into a relational database.

Why this answer

Azure Data Factory (ADF) is the correct choice because it is a fully managed, serverless data integration service designed for high-scale data movement and transformation. ADF can directly read large CSV files from Blob Storage using Copy Activity with built-in parallelization and chunking, then transform the data using Mapping Data Flows or stored procedures in Azure SQL Database, all without provisioning VMs or managing infrastructure. This minimizes both processing time (via scale-out) and cost (pay-per-use, no idle compute).

Exam trap

The trap here is that candidates often choose Logic Apps or Stream Analytics because they are 'serverless' and 'low-code', but they fail to recognize that these services are optimized for small payloads or real-time streams, not for batch processing of multi-gigabyte files.

How to eliminate wrong answers

Option B is wrong because Azure Logic Apps is a workflow orchestration service, not a data processing engine; it would require pulling the entire 1 GB CSV into memory via a trigger, causing timeouts (default 2-min timeout) and high memory consumption, making it unsuitable for large files. Option C is wrong because downloading a 1 GB file to an Azure VM introduces network transfer latency, VM provisioning costs, and manual scaling overhead, which increases both time and cost compared to serverless alternatives. Option D is wrong because Azure Stream Analytics is designed for real-time streaming data (e.g., IoT events) and cannot efficiently process batch-oriented, large CSV files; it lacks native CSV parsing and batch transformation capabilities, leading to poor performance and higher cost.

Practice this question →

MCQeasy

You are developing a solution that stores user-uploaded profile pictures. Users upload pictures that are then displayed on their profile page. After 30 days, if the user hasn't logged in, the system moves the picture to cold storage. You need to choose the initial access tier for the container to optimize cost and performance for frequently accessed pictures. Which tier should you use?

A.Hot

B.Cool

C.Archive

D.Premium

AnswerA

The Hot tier is specifically designed for frequently accessed data that requires low latency and high throughput, making it the optimal choice for user profile pictures. These images are typically retrieved every time a user logs in or views a profile, demanding immediate access. While its storage costs are higher than Cool or Archive, the Hot tier offers the lowest access costs and ensures a responsive user experience for dynamic content like profile pictures.

Why this answer

The Hot tier is the correct initial access tier because the profile pictures are frequently accessed immediately after upload (e.g., displayed on profile pages). The Hot tier is optimized for high-frequency read/write operations with the lowest latency, making it cost-effective for data that is accessed often. After 30 days of inactivity, the system moves the picture to cold storage, so the initial tier should prioritize performance for active data, not long-term archival cost savings.

Exam trap

The trap here is that candidates often choose Cool or Archive thinking they are 'cost-saving' upfront, but they overlook that the Hot tier is actually the most cost-effective for frequently accessed data because it avoids per-access fees and latency penalties, while lifecycle management handles the eventual move to cheaper storage.

How to eliminate wrong answers

Option B (Cool) is wrong because the Cool tier is designed for data that is infrequently accessed (e.g., once a month or less) and has higher access costs and latency compared to Hot, making it suboptimal for frequently accessed profile pictures. Option C (Archive) is wrong because the Archive tier is for data that is rarely accessed (e.g., once a year) and has the highest retrieval latency (up to 15 hours for rehydration), which is unacceptable for immediate display on a profile page. Option D (Premium) is wrong because the Premium tier is for block blobs with low-latency requirements (e.g., for Azure Virtual Desktop or high-performance computing) and incurs significantly higher storage costs, making it overkill and cost-inefficient for standard user-uploaded profile pictures.

Practice this question →

Drag & Dropmedium

Arrange the steps to implement Azure AD authentication in an ASP.NET Core web app in the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First register the app in Azure AD, then configure settings, add NuGet, configure middleware, and secure endpoints.

Practice this question →

Multi-Selectmedium

Which FOUR are valid ways to authenticate to Azure Blob Storage from an application? (Choose four.)

Select 4 answers

A.Use the storage account access key.

B.Use an OAuth2 token obtained from Microsoft Entra ID for a user.

C.Use a shared access signature (SAS) token.

D.Use a client certificate.

E.Use a managed identity assigned to an Azure resource.

AnswersA, B, C, E

The storage account access key is a shared secret granting full access to the account's blob data, and applications can pass it via connection string or SharedKey authorisation. It is a valid authentication method, though less granular than Microsoft Entra ID.

Why this answer

Option A is correct because the storage account access key (key1/key2) is a shared secret that authorizes full access to the account's data plane and is a standard authentication method for Blob Storage. Option B is correct because OAuth2 bearer tokens issued by Microsoft Entra ID (for a user principal) can be presented to the Blob service and validated via Azure RBAC roles such as Storage Blob Data Reader/Contributor. Option C is correct because a shared access signature is a signed URL/token delegating scoped, time-limited permissions to blob resources, and it is a supported authentication mechanism.

Option E is correct because a managed identity assigned to an Azure resource (system- or user-assigned) obtains an Entra ID token that the Blob SDK can use without storing credentials. Option D is not a valid Blob Storage authentication method; client certificates are used for other services (for example, service principals with certificate credentials authenticate to Entra ID, not directly to Blob Storage).

Exam trap

Common mistake: Candidates often assume that only one of OAuth2 user token (B) and managed identity (E) is valid, but both are supported methods. Also, client certificates (D) are not directly supported for Blob Storage authentication.

Practice this question →

MCQeasy

You are building a web application that stores user-uploaded images in Azure Blob Storage. The application requires that images be accessible only via a time-limited URL. Which security mechanism should you use?

A.Use storage account access keys in the application code.

B.Generate a shared access signature (SAS) token for each blob.

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

D.Use Azure Key Vault to store and retrieve the storage account key.

AnswerB

Generating a Shared Access Signature (SAS) token for each blob is the most appropriate solution for providing secure, time-limited access to specific storage resources. A SAS token is a URI that grants restricted permissions to Azure Storage resources for a specified interval or with specific permissions, such as read or write. This allows the application to provide users with temporary, granular access to upload or retrieve individual blobs without exposing the storage account's primary keys, aligning perfectly with the need for controlled, temporary access.

Why this answer

A shared access signature (SAS) token provides delegated, time-limited access to a specific blob without exposing the storage account key. By generating a SAS token with an expiration time, you can enforce that the image URL is only valid for a limited period, meeting the requirement exactly. This is the standard Azure mechanism for granting granular, time-bound access to blob storage resources.

Exam trap

The trap here is that candidates often confuse persistent access control methods (like RBAC roles or account keys) with the time-limited, delegated access that only a SAS token provides, leading them to pick options that secure the key but do not enforce an expiration on the URL.

How to eliminate wrong answers

Option A is wrong because embedding storage account access keys in application code grants full, unrestricted access to the entire storage account and never expires, violating the time-limited requirement. Option C is wrong because assigning the 'Storage Blob Data Reader' role via managed identity provides persistent, role-based access without any built-in time limitation, so it cannot enforce a time-bound URL. Option D is wrong because storing the storage account key in Azure Key Vault secures the key but does not create a time-limited URL; you would still need to generate a SAS token from that key to achieve the time-bound requirement.

Practice this question →

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?

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 is signed with the account key but delegates only scoped permissions, so the application receives a time-limited token rather than the key itself. Scoping to the container with read permission and a two-hour expiry satisfies both the least-privilege and no-account-key constraints.

Why this answer

A service SAS scoped to a container with read permission and an expiry of two hours is the correct approach because it provides delegated, time-limited access to specific blobs under that container without exposing the storage account key. The SAS token is generated using the account key but the application only receives the token, not the key itself, ensuring the key remains secure. This meets the requirement for read-only access to a single container for a limited duration.

Exam trap

The trap here is that candidates often confuse a service SAS with a public access level or account key, failing to recognize that a SAS provides granular, time-bound delegation without exposing the account key, while public access is permanent and account keys grant full control.

How to eliminate wrong answers

Option A is wrong because setting a public access level on the container grants anonymous read access to all blobs in that container indefinitely, with no time restriction and no way to revoke access without changing the container's ACL, which violates the two-hour limit and the requirement to avoid exposing the account key. Option C is wrong because a management group assignment controls access at the Azure subscription or management group level for administrative operations, not at the blob or container level for data operations, and it cannot grant time-limited read access to blobs. Option D is wrong because providing the storage account access key grants full administrative access to all storage account operations (read, write, delete) across all containers and services, with no time restriction, which is excessive and insecure for the stated requirement.

Practice this question →

MCQmedium

You need to securely transfer an on-premises database backup to Azure Blob Storage. The backup file is 500 GB. You have limited bandwidth (10 Mbps) and need the transfer to complete within 24 hours. What is the best solution?

A.Use Azure File Sync to replicate the backup to Azure Files.

B.Use Azure Data Box to physically ship the data to Azure.

C.Use AzCopy to copy the backup file directly to Blob Storage.

D.Set up an ExpressRoute connection and use AzCopy.

AnswerB

Azure Data Box is a robust, secure physical appliance specifically engineered for offline data transfer of terabytes to petabytes of data into Azure Blob Storage or Azure Files. When on-premises network bandwidth is insufficient or unreliable for large datasets, physically shipping the encrypted device directly to an Azure datacenter completely bypasses network limitations, making it the most efficient and secure method for initial bulk data ingestion within a tight time requirement.

Why this answer

Given the 500 GB backup file and a 10 Mbps bandwidth limit, the theoretical maximum transfer time over the internet is approximately 500 GB * 8 bits/byte / (10 Mbps) = 400,000 seconds ≈ 111 hours, far exceeding the 24-hour requirement. Azure Data Box is the best solution because it allows you to physically ship the data on a secure, ruggedized device, bypassing network constraints entirely and ensuring the transfer completes within the required timeframe.

Exam trap

The trap here is that candidates may overlook the bandwidth calculation and assume AzCopy or ExpressRoute can handle the transfer within 24 hours, failing to recognize that even with a dedicated connection, the raw throughput is insufficient for 500 GB at 10 Mbps.

How to eliminate wrong answers

Option A is wrong because Azure File Sync is designed for synchronizing file shares over a network, not for bulk data transfer of a single large backup file; it would still be constrained by the 10 Mbps bandwidth and would not meet the 24-hour deadline. Option C is wrong because AzCopy relies on network bandwidth; at 10 Mbps, transferring 500 GB would take over 111 hours, far exceeding the 24-hour limit. Option D is wrong because ExpressRoute provides a dedicated private connection but does not increase bandwidth beyond the 10 Mbps limit; the transfer would still take over 111 hours, failing the time constraint.

Practice this question →

MCQmedium

An application stores sensor readings in Azure Table Storage. Each sensor produces thousands of readings per hour. Queries always filter by sensor ID and time range. A developer needs to choose the partition key and row key. Which design best balances query performance and write throughput?

A.Partition key: sensor ID; row key: ISO timestamp of the reading

B.Partition key: a single constant ('all-sensors'); row key: sensor ID + timestamp

C.Partition key: timestamp (rounded to the hour); row key: sensor ID

D.Partition key: random GUID per reading; row key: timestamp

AnswerA

This design effectively leverages Azure Table Storage's partitioning strategy. Grouping all readings for a specific sensor ID within a single partition ensures efficient retrieval of all data related to that sensor, as queries can target a specific partition. Using an ISO timestamp as the row key provides natural chronological ordering within the partition, enabling highly performant time-range queries for a given sensor without scanning unrelated data. This combination optimizes both data locality and query efficiency for typical IoT sensor data access patterns.

Why this answer

It uses sensor ID as the partition key, which ensures all readings for a given sensor are stored in the same partition, enabling efficient range queries by row key (timestamp). This design avoids hot partitions by distributing writes across different sensors, while the row key allows fast point lookups and range scans within a time window, balancing query performance and write throughput.

Exam trap

The trap here is that candidates often choose a partition key that groups data by time (Option C) to optimize time-range queries, but they overlook that this creates a hot partition for all sensors in that time window, severely limiting write throughput.

How to eliminate wrong answers

Option B is wrong because using a single constant partition key ('all-sensors') forces all writes and queries into one partition, creating a hot partition that throttles throughput and degrades performance. Option C is wrong because using timestamp rounded to the hour as the partition key can cause all sensors' data for the same hour to land in the same partition, leading to write contention and poor query performance when filtering by sensor ID (which requires a full partition scan). Option D is wrong because using a random GUID as the partition key scatters each reading across partitions, making queries that filter by sensor ID and time range inefficient (they must scan all partitions) and defeating the purpose of partition key design.

Practice this question →

Multi-Selecthard

Which THREE of the following are true about Azure Storage queues? (Choose three.)

Select 3 answers

A.Messages are processed in strict FIFO order.

B.The maximum time-to-live for a message is 7 days.

C.Messages can be up to 1 MB in size.

D.Messages can be up to 64 KB in size.

E.The visibility timeout allows a consumer to hide a message from other consumers while processing it.

AnswersB, D, E

Azure Storage Queue messages have a configurable time-to-live (TTL) property, which dictates how long a message will remain in the queue before it is automatically removed if not processed. The maximum allowable value for this time-to-live is indeed 7 days, or 604,800 seconds. If a message is enqueued without specifying a TTL, it defaults to this 7-day maximum, ensuring messages do not persist indefinitely and preventing queue bloat.

Why this answer

Option B is correct because an Azure Storage queue message can have a time-to-live of at most 7 days (the default is also 7 days, and it can be set to any value up to that maximum, or -1 for no expiry). Option D is correct because the maximum size of a single Azure Storage queue message is 64 KB; larger payloads must be split or stored elsewhere (e.g., in a blob) with only a reference placed on the queue. Option E is correct because the visibility timeout is exactly the mechanism that makes a dequeued message invisible to other consumers for a specified period while the consumer processes it, after which it becomes visible again if not deleted.

Option A is not correct because Azure Storage queues guarantee at-least-once delivery and generally approximate FIFO ordering, but they do not guarantee strict FIFO order. Option C is not correct because 1 MB is not the queue message limit; 64 KB is the actual maximum for Azure Storage queue messages.

Exam trap

The trap here is that candidates often confuse Azure Storage queues with Azure Service Bus queues, leading them to select the 1 MB message size limit (which applies to Service Bus) instead of the correct 64 KB limit for Storage queues.

Practice this question →

MCQmedium

You are designing a solution that requires atomic operations on a counter stored in Azure Blob Storage. The counter must be updated by multiple instances without conflicts. Which approach should you use?

A.Store the counter in Azure Cosmos DB and use stored procedures to increment atomically.

B.Use Azure Queue Storage to queue increment messages.

C.Store the counter in Azure Table Storage and use optimistic concurrency with ETags.

D.Use Append Blob to append each increment as a new block and sum them later.

AnswerA

Azure Cosmos DB stored procedures execute as a single, ACID-compliant transaction within a logical partition. When a stored procedure increments a counter, all operations within that procedure—reading the current value, incrementing it, and writing the new value—are guaranteed to either fully succeed or fully fail. This transactional boundary ensures that concurrent attempts to update the counter will not result in lost updates, making the increment operation truly atomic.

Why this answer

Azure Cosmos DB stored procedures execute within the database engine's transactional scope, providing ACID-compliant atomic operations. This ensures that concurrent increments from multiple instances are serialized without conflicts, which is not natively supported by Azure Blob Storage's eventual consistency model.

Exam trap

The trap here is that candidates assume Azure Blob Storage's lease or append features can provide atomicity, but Blob Storage lacks server-side atomic read-modify-write operations, making Cosmos DB the only Azure service among the options that natively supports atomic counter updates with stored procedures.

How to eliminate wrong answers

Option B is wrong because Azure Queue Storage decouples message processing but does not guarantee atomic updates to a counter; multiple workers can process messages concurrently, leading to race conditions unless additional locking is implemented. Option C is wrong because Azure Table Storage's optimistic concurrency with ETags only detects conflicts after the fact (via HTTP 412 Precondition Failed), requiring retry logic and still allowing lost updates under high contention. Option D is wrong because Append Blob appends data sequentially but does not provide atomic read-modify-write semantics; summing blocks later is an offline batch operation that cannot ensure real-time atomicity.

Practice this question →

MCQmedium

Your application stores sensitive data in Azure Table Storage. You need to encrypt the data at rest. What should you do?

A.Implement client-side encryption using Azure Key Vault.

B.Enable server-side encryption with customer-managed keys in Azure Key Vault.

C.No action needed; Azure Storage Service Encryption (SSE) is enabled by default.

D.Enable Azure Disk Encryption on the virtual machines accessing the storage.

AnswerC

No action is needed because Azure Storage Service Encryption (SSE) is automatically enabled for all Azure Storage accounts, including Table Storage, by default. This means that all data written to Azure Table Storage is encrypted at rest using Microsoft-managed keys without any explicit configuration required from the user. This built-in encryption ensures that sensitive data is protected according to industry standards as soon as it is stored, satisfying the core security requirement.

Why this answer

Azure Storage Service Encryption (SSE) automatically encrypts all data at rest in Azure Table Storage using 256-bit AES encryption, and it is enabled by default for all new and existing storage accounts. Since the question asks about encrypting data at rest and does not specify a need for customer-managed keys or client-side control, the default SSE meets the requirement without any additional configuration.

Exam trap

The trap here is that candidates often overthink and assume they need to take explicit action (like client-side encryption or customer-managed keys) to encrypt data at rest, when in fact Azure Storage Service Encryption is enabled by default and requires no configuration.

How to eliminate wrong answers

Option A is wrong because client-side encryption is an additional layer that encrypts data before it is sent to Azure Storage, but it is not required for data at rest encryption since SSE already provides that; implementing it would add unnecessary complexity and is not the default or simplest solution. Option B is wrong because server-side encryption with customer-managed keys (CMK) is an optional feature that allows you to use your own key in Azure Key Vault, but it is not needed when the default SSE (which uses Microsoft-managed keys) already encrypts data at rest; enabling CMK is an extra step for specific compliance requirements, not the default action. Option D is wrong because Azure Disk Encryption encrypts the OS and data disks of virtual machines using BitLocker or DM-Crypt, but it does not encrypt the data stored in Azure Table Storage, which is a PaaS service separate from VM disks.

Practice this question →

MCQmedium

A queue-processing application stores work items in Azure Queue Storage. A worker crashes after receiving a message. What determines when the message becomes available for another worker?

A.Blob lease duration

B.Visibility timeout

C.Message TTL only

D.Poison queue threshold only

AnswerB

When a worker dequeues a message, it becomes invisible for the visibility timeout period. If the worker crashes without deleting it, the message reappears automatically once that interval expires, making it available to another worker without manual intervention.

Why this answer

When a worker receives a message from Azure Queue Storage, the message becomes invisible to other workers for a period defined by the visibility timeout. If the worker crashes without deleting or updating the message, the visibility timeout expires and the message reappears in the queue, making it available for another worker to process. This mechanism ensures at-least-once processing and prevents message loss on worker failure.

Exam trap

The trap here is confusing the visibility timeout with message TTL or poison queue handling, leading candidates to overlook the specific mechanism that controls message reavailability after a worker crash.

How to eliminate wrong answers

Option A is wrong because blob lease duration applies to Azure Blob Storage leases for exclusive write access, not to queue messages. Option C is wrong because Message TTL (Time-to-Live) only sets the maximum time a message stays in the queue before being deleted, not when it becomes visible after a worker crash. Option D is wrong because the poison queue threshold defines how many times a message can be dequeued before being moved to a poison queue, not when it becomes available after a crash.

Practice this question →

MCQeasy

You need to store and retrieve large binary files (up to 100 GB each) with low latency. The files will be accessed by multiple geographic regions. Which Azure storage solution should you recommend?

A.Azure Queue Storage with messages.

B.Azure Files with Azure File Sync.

C.Azure Blob Storage with geo-redundant storage (GRS).

D.Azure SQL Database with file tables.

AnswerC

Azure Blob Storage is purpose-built for storing massive amounts of unstructured data, including large binary files, images, videos, and backups, making it the ideal choice for objects up to 100 GB. It offers unparalleled scalability, cost-effectiveness across various access tiers, and robust APIs for object management. Implementing Geo-Redundant Storage (GRS) further enhances data durability and availability by asynchronously replicating data to a secondary Azure region hundreds of miles away, providing comprehensive protection against regional outages.

Why this answer

Azure Blob Storage is designed for storing large binary objects (up to 4.7 TB per blob) and offers low-latency access via HTTP/HTTPS. Geo-redundant storage (GRS) replicates data to a paired secondary region, providing durability and availability for multi-region access. This combination meets the requirements for large files (up to 100 GB) and low-latency retrieval from multiple geographic regions.

Exam trap

The trap here is that candidates may confuse Azure Files (SMB shares) with Blob Storage for large binary files, not realizing that Azure Files has a 1 TB file size limit and is optimized for shared file access, not for high-throughput blob storage with geo-replication.

How to eliminate wrong answers

Option A is wrong because Azure Queue Storage is a messaging service for decoupling application components, not for storing or retrieving large binary files; messages are limited to 64 KB each. Option B is wrong because Azure Files provides SMB file shares with a maximum file size of 1 TB (not 100 GB per file) and Azure File Sync is for caching on-premises, not optimized for low-latency multi-region blob access. Option D is wrong because Azure SQL Database with file tables stores file metadata in a relational database, but the actual binary data is stored in Azure Blob Storage behind the scenes, and SQL Database is not designed for direct high-throughput binary access with low latency for files up to 100 GB.

Practice this question →

Multi-Selecteasy

Which TWO of the following are valid authentication options for accessing Azure Storage from an application? (Choose TWO.)

Select 2 answers

A.Storage account key (Shared Key).

B.Microsoft Entra ID (formerly Azure AD) authentication.

C.Certificate-based authentication.

D.Managed Service Identity (MSI).

E.Shared access signature (SAS) token.

AnswersA, B

A storage account key, also known as a Shared Key, provides full administrative access to all data within an Azure storage account. When using Shared Key authentication, every request to Azure Storage is cryptographically signed with this key, allowing the storage service to verify the request's authenticity. This method grants comprehensive control over blobs, files, queues, and tables, making it a powerful but sensitive authentication mechanism that should be protected diligently.

Why this answer

The storage account key (Shared Key) provides full administrative access to the storage account, allowing the application to authenticate requests via the Authorization header using HMAC-SHA256. Option B is correct because Microsoft Entra ID (formerly Azure AD) supports role-based access control (RBAC) for Azure Storage, enabling applications to authenticate using OAuth 2.0 tokens for fine-grained access without exposing account keys.

Exam trap

The trap here is that candidates often confuse Managed Service Identity (MSI) as a standalone authentication method, when in reality it is an identity provider that relies on Entra ID tokens, and they may also mistake SAS tokens as an authentication option rather than a delegated authorization mechanism.

Practice this question →

MCQhard

You are designing a solution that requires storing millions of small (1-5 KB) messages from IoT devices. Each message has a unique device ID and timestamp. You need to support efficient point queries by device ID and time range, and also support aggregation queries (e.g., count of messages per device per hour). Which Azure storage solution should you use?

A.Azure Cosmos DB for NoSQL

B.Azure Table Storage

C.Azure Queue Storage

D.Azure Blob Storage with JSON files

AnswerB

Azure Table Storage is a NoSQL key-value store highly optimized for storing massive amounts of structured, non-relational data, making it exceptionally cost-effective for small entities like IoT sensor readings. It provides highly efficient point queries using a composite PartitionKey and RowKey, which is ideal for retrieving specific device data by ID and timestamp. Its schema-less nature and scalability perfectly support millions of records for time-series data.

Why this answer

Azure Table Storage is the correct choice because it is a NoSQL key-value store optimized for storing large volumes of structured, non-relational data. It supports efficient point queries using the PartitionKey (device ID) and RowKey (timestamp), enabling fast retrieval by device ID and time range. Additionally, it allows aggregation queries like counting messages per device per hour via partition-scanned queries or client-side aggregation, and it is cost-effective for storing millions of small (1-5 KB) messages.

Exam trap

The trap here is that candidates often choose Azure Cosmos DB for NoSQL because of its query flexibility and indexing, overlooking the cost implications and the fact that Azure Table Storage provides sufficient query capabilities for simple key-value and range queries at a fraction of the cost.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB for NoSQL, while capable of similar queries, is significantly more expensive and over-provisioned for storing millions of small messages; its throughput-based pricing model makes it cost-prohibitive for high-volume, low-value IoT data. Option C is wrong because Azure Queue Storage is a message queuing service for asynchronous communication, not a durable storage solution for point queries or aggregation; it does not support querying by device ID or time range. Option D is wrong because Azure Blob Storage with JSON files is designed for unstructured blob data and lacks native indexing for efficient point queries by device ID and timestamp; querying millions of small JSON files would require scanning all blobs or using external indexing, which is inefficient and costly.

Practice this question →

100

MCQeasy

You are designing a solution to store large amounts of unstructured data that is accessed infrequently (once a quarter). You need to minimize storage costs. Which Azure storage tier should you use?

A.Cold

B.Hot

C.Archive

D.Cool

AnswerD

The Cool access tier is ideal for infrequently accessed data that still requires quick retrieval, typically accessed every 30 days or more. It offers a balance between storage costs and access costs, being cheaper to store than Hot but more expensive to access. This tier is well-suited for scenarios like short-term backups, older media content, or data that is not actively used but may be needed on demand, aligning with the requirement for infrequently accessed data.

Why this answer

The Cool tier is designed for data that is accessed infrequently (about once a quarter) and stored for at least 30 days, offering lower storage costs than Hot while still providing low-latency access. Since the data is unstructured and accessed only quarterly, Cool balances cost and availability without the long retrieval time or minimum storage duration of Archive.

Exam trap

The trap here is that candidates confuse 'Cold' with 'Cool' or assume 'Archive' is always the cheapest option without considering retrieval latency and minimum storage duration penalties.

How to eliminate wrong answers

Option A (Cold) is wrong because Azure Storage does not have a 'Cold' tier; the correct tiers are Hot, Cool, and Archive. Option B (Hot) is wrong because it is optimized for frequent access (multiple times per day) and has the highest storage cost, making it unsuitable for infrequently accessed data. Option C (Archive) is wrong because while it has the lowest storage cost, it requires a retrieval time of up to 15 hours and a minimum storage duration of 180 days, which is excessive for quarterly access and would increase total cost due to early deletion fees.

Practice this question →

101

MCQeasy

You are building a serverless application that needs to store user profile data. The data includes simple fields like name, email, and preferences. The data is frequently accessed by user ID. You need a schema-less, low-latency storage solution that is cost-effective for millions of small records. Which Azure Storage solution should you use?

A.Azure Blob Storage

B.Azure Queue Storage

C.Azure Table Storage

D.Azure File Storage

AnswerC

Azure Table Storage is a NoSQL key-value store optimized for storing large amounts of structured, non-relational data with a flexible schema. It provides highly scalable and low-latency access to data, making it ideal for user profiles where a unique identifier, like a user ID, can serve as the RowKey or PartitionKey. This design allows for efficient retrieval of individual entities, perfectly aligning with the requirements for storing and quickly accessing user data in a serverless application.

Why this answer

Azure Table Storage is a NoSQL key-value store that is schema-less, making it ideal for storing user profile data with varying fields like name, email, and preferences. It offers low-latency access by user ID via the PartitionKey and RowKey, and it is cost-effective for millions of small records because you pay only for the storage consumed, with no minimum charge per record.

Exam trap

The trap here is that candidates often confuse Azure Table Storage with Azure Cosmos DB for Table API, but the question specifically asks for a cost-effective solution for millions of small records, and Azure Table Storage (part of Azure Storage account) is the cheaper, schema-less option without the premium features and higher cost of Cosmos DB.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is designed for unstructured binary or text data (e.g., images, videos, documents) and does not provide native key-value querying by user ID; it requires a separate index or metadata system for such lookups. Option B is wrong because Azure Queue Storage is a messaging service for asynchronous communication between application components, not a persistent storage solution for user profile data. Option D is wrong because Azure File Storage provides fully managed file shares accessible via SMB protocol, which is overkill for simple key-value records and incurs higher costs due to per-GB pricing and minimum share size requirements.

Practice this question →

102

MCQhard

You have a blob as shown in the exhibit. You need to read the content of this blob. What must you do first?

A.Convert the blob to an AppendBlob type.

B.Use the Get-AzStorageBlobContent cmdlet to download the blob directly.

C.Set the access tier of the blob to Hot or Cool using Set-AzStorageBlobTier.

D.Use the storage account key to access the blob.

AnswerC

Setting the access tier of the blob to Hot or Cool using Set-AzStorageBlobTier is the correct approach because blobs in the Archive tier are offline and not directly readable. This operation initiates a "rehydration" process, moving the blob's data from the low-cost, high-latency Archive tier to a more accessible tier. Once rehydration completes, which can take several hours depending on priority, the blob becomes online and its content can be read.

Why this answer

The blob in the exhibit is an archived blob, which is offline and cannot be read directly. You must first rehydrate it by setting its access tier to Hot or Cool using Set-AzStorageBlobTier, which initiates an asynchronous copy from the archive tier to an online tier. Only after rehydration completes can you read the blob content.

Exam trap

The trap here is that candidates assume a storage account key or a direct download cmdlet can access any blob, but Azure enforces the archive tier's offline state, requiring explicit rehydration before any read operation.

How to eliminate wrong answers

Option A is wrong because converting the blob to an AppendBlob type does not change its offline archive state; AppendBlob is a blob type for append operations, not a tier change, and the blob remains inaccessible. Option B is wrong because Get-AzStorageBlobContent attempts to download the blob directly, but an archived blob is offline and returns a 409 error (BlobArchived) until rehydrated. Option D is wrong because using the storage account key provides authentication but does not bypass the archive tier restriction; the blob is still offline and cannot be accessed regardless of credentials.

Practice this question →

103

MCQmedium

You are developing an Azure Web App that needs to access an Azure Storage account. The app must authenticate without storing credentials in code or configuration. You need to implement the solution using the latest Azure Identity library. What should you do?

A.Enable managed identity for the Web App and use DefaultAzureCredential in the application code.

B.Use the storage account's primary key and store it in the Web App's application settings.

C.Generate a shared access signature (SAS) token and include it in the application configuration.

D.Create a service principal and store its client secret in Azure Key Vault, then retrieve it at runtime.

AnswerA

Enabling a system-assigned or user-assigned managed identity for the Azure Web App allows the app to authenticate to Azure Storage without any credentials in code or configuration. The DefaultAzureCredential class from the Azure Identity library automatically detects the managed identity when running in Azure and uses it to obtain a token. You then grant the managed identity the appropriate role (e.g., Storage Blob Data Contributor) on the storage account. This approach is secure, requires no secret management, and is the recommended practice for Azure-hosted applications.

Why this answer

Managed identity provides an identity for the Azure Web App in Azure AD, and DefaultAzureCredential automatically uses it to authenticate to Azure Storage. This eliminates the need to store any secrets in code or configuration. The other options involve storing or managing credentials, which does not meet the requirement.

Using managed identity is the most secure and recommended approach for Azure-to-Azure authentication.

Exam trap

The trap here is thinking that storing a secret in Key Vault or using a SAS token is sufficient to avoid credentials in configuration, but those still involve managing a secret.

Practice this question →

104

Multi-Selectmedium

Which THREE of the following are true about Azure Blob Storage lifecycle management?

Select 3 answers

A.It can be defined at the container level.

B.It can automatically move blobs to the Cool tier after a specified number of days.

C.It can be applied to general-purpose v2 and Blob Storage accounts.

D.It can delete blob snapshots after a specified number of days.

E.It can change the replication type of the storage account.

AnswersB, C, D

Azure Blob Storage lifecycle management policies are specifically designed to automate the movement of blobs between different access tiers. A common rule dictates that blobs can be automatically transitioned from the Hot tier to the Cool tier after a user-defined number of days since their last modification or creation. This capability is crucial for optimizing storage costs by moving less frequently accessed data to more economical tiers.

Why this answer

Option B is correct because lifecycle management policies support tiering rules that transition blobs from Hot to Cool (or Cool to Archive) based on a daysAfterModificationGreaterThan or daysAfterCreationGreaterThan condition. Option C is correct because lifecycle management is supported on general-purpose v2 and Blob Storage accounts (and premium block blob accounts), but not on general-purpose v1 or classic accounts. Option D is correct because lifecycle rules include a delete action that can remove blob snapshots (and versions) after a specified number of days, using baseBlob, snapshot, and version rule filters.

Option A is not correct because lifecycle management policies are defined at the storage account level (scoped via rule filters such as prefix or blob index tags), not at the container level. Option E is not correct because replication type (LRS, ZRS, GRS, RA-GRS) is a storage account redundancy setting changed via account configuration, not an action available in lifecycle management policies.

Exam trap

The trap here is that candidates may think lifecycle policies can be applied at the container level (Option A) because they often use container-scoped filters, but the policy definition itself is always at the storage account level.

Practice this question →

105

MCQeasy

You need to grant access to a blob stored in Azure Blob Storage for 30 minutes to a user who does not have an Azure account. Which security mechanism should you use?

A.Azure RBAC roles

B.Storage account access keys

C.Managed identity

D.Shared Access Signature (SAS) token

AnswerD

A Shared Access Signature (SAS) token is a URI that grants delegated access to specific Azure Storage resources with granular permissions and a defined validity period. It allows clients to access resources like a single blob, a container, or even an entire storage account, without sharing the storage account key or requiring an Azure AD identity. SAS tokens are ideal for securely providing time-limited, restricted access to external users or applications, ensuring the principle of least privilege.

Why this answer

A Shared Access Signature (SAS) token is the correct choice because it provides delegated, time-limited access to a specific blob resource without requiring the user to have an Azure account. You can set the token's expiry to 30 minutes, granting temporary access via a URI that includes the necessary authentication parameters. This mechanism is designed for scenarios where you need to grant granular, time-bound access to external users or clients.

Exam trap

The trap here is that candidates often confuse SAS tokens with storage account access keys, mistakenly thinking keys can be scoped or time-limited, or they assume RBAC can be used for external users without understanding the Azure AD dependency.

How to eliminate wrong answers

Option A is wrong because Azure RBAC roles require the user to have an Azure Active Directory identity and an Azure subscription, which is not the case here. Option B is wrong because storage account access keys grant full administrative access to the entire storage account and cannot be scoped to a single blob or time-limited; sharing keys also exposes the account to security risks. Option C is wrong because managed identity is intended for Azure resources (e.g., VMs, App Services) to authenticate to Azure services without storing credentials, not for granting access to external users without an Azure account.

Practice this question →

106

MCQmedium

You are building a solution that uploads large files (up to 100 GB) to Azure Blob Storage. Users frequently experience timeout errors when uploading files over slow network connections. Which approach should you use to maximize reliability?

A.Upload the file as a page blob in 512-byte chunks.

B.Use the Azure Storage SDK to upload the file as a block blob with multiple parallel blocks and implement retry logic with exponential backoff.

C.Increase the client-side timeout value to 10 minutes.

D.Use AzCopy with the /Z parameter to enable checkpointing.

AnswerB

This is the correct approach for uploading large files to Azure Storage. Block blobs are optimized for large, sequential data uploads, allowing files to be broken into independent blocks that can be uploaded in parallel, significantly improving throughput and reducing total upload time. The Azure Storage SDK inherently supports this parallelization and provides robust, configurable retry logic with exponential backoff, which is crucial for handling transient network issues and service throttling, ensuring reliable delivery of the entire file even under adverse conditions.

Why this answer

Uploading a large file as a block blob with multiple parallel blocks maximizes throughput and reliability over slow networks. The Azure Storage SDK automatically splits the file into blocks (up to 100 MB each), uploads them concurrently, and implements retry logic with exponential backoff to handle transient failures. This approach is specifically designed for large file uploads and mitigates timeout errors by keeping individual block transfers small and resumable.

Exam trap

The trap here is that candidates may confuse AzCopy's checkpointing (Option D) as the only reliable method for large uploads, but the question specifies building a solution (SDK-based), not using a standalone tool, and AzCopy cannot be programmatically embedded in an application.

How to eliminate wrong answers

Option A is wrong because page blobs are optimized for random read/write access (e.g., VHDs), not for large file uploads; they require 512-byte alignment and do not support parallel upload with retry logic for slow networks. Option C is wrong because simply increasing the client-side timeout to 10 minutes does not address the root cause of timeouts over slow connections; it only delays the failure and does not provide resumability or parallelism. Option D is wrong because AzCopy with the /Z parameter enables checkpointing for resuming interrupted transfers, but it is a command-line tool, not a programmatic SDK approach; the question asks for a solution you are building, implying code-level integration, and AzCopy is not suitable for embedding in an application.

Practice this question →

107

Drag & Dropmedium

Arrange the steps to secure an Azure API Management API using OAuth 2.0 with Azure AD in the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First register app in Azure AD, configure API Management with OAuth, add validate-jwt policy, configure product, test.

Practice this question →

108

MCQhard

You need to store billions of small log entries (each ~200 bytes) written in chronological order from multiple producers. The logs are read sequentially in bulk once per day. You need to maximize write throughput and minimize storage costs. Which Azure Storage solution should you choose?

A.Append Blob in Blob Storage

B.Block Blob in Blob Storage with high block count

C.Azure Data Lake Storage Gen2 with hierarchical namespace

D.Azure Files with SMB protocol

AnswerA

Append Blobs are specifically designed for append operations, making them ideal for logging scenarios where new data is continuously added to the end of a blob. Each 200-byte log entry can be atomically appended, ensuring data integrity and high write throughput for billions of sequential entries. This specialized blob type efficiently handles the scale and frequency of small, incremental writes without incurring significant overhead, providing a cost-effective and performant solution for continuous logging.

Why this answer

Append Blob in Blob Storage is optimized for append operations, making it ideal for writing small log entries in chronological order from multiple producers. It provides high write throughput because each append operation is atomic and can be performed concurrently, and it minimizes storage costs by storing data in a cost-effective blob tier without the overhead of indexing or metadata management required by other solutions.

Exam trap

The trap here is that candidates often confuse Append Blob with Block Blob, assuming high block count can achieve similar append performance, but Block Blob requires explicit block management and cannot guarantee atomic append operations, making Append Blob the only correct choice for this workload.

How to eliminate wrong answers

Option B is wrong because Block Blob with high block count is designed for uploading large files in parallel, not for frequent small appends; each block must be committed in a final block list, which adds overhead and does not support true append semantics. Option C is wrong because Azure Data Lake Storage Gen2 with hierarchical namespace is optimized for big data analytics workloads with directory-level operations and POSIX permissions, which adds unnecessary complexity and cost for simple sequential log storage. Option D is wrong because Azure Files with SMB protocol is a fully managed file share designed for shared access and SMB-based applications, not for high-throughput append-only log ingestion, and it incurs higher costs per GB compared to blob storage.

Practice this question →

109

MCQeasy

You need to store a large number of small files (each < 100 KB) that will be accessed frequently from a web application. The files are static assets (CSS, JavaScript, images). Which Azure storage option provides the best performance for serving these files directly to users?

A.Azure Queue Storage

B.Azure Blob Storage with Azure CDN

C.Azure Table Storage

D.Azure Files

AnswerB

Azure Blob Storage is the optimal choice for storing large numbers of small, static files, such as images, CSS, or JavaScript, due to its cost-effectiveness and scalability for unstructured data. Integrating with Azure CDN significantly enhances performance by caching these files at edge locations globally. This reduces latency for end-users worldwide and offloads traffic from the origin storage account.

Why this answer

Azure Blob Storage is optimized for storing large volumes of unstructured data, including small static files. By integrating Azure CDN, you cache these files at edge nodes closer to users, drastically reducing latency and offloading origin requests. This combination provides the best performance for frequently accessed static assets served directly to a web application's users.

Exam trap

The trap here is that candidates may choose Azure Files (Option D) because it resembles a traditional file server, but it lacks the global caching and low-latency edge delivery that CDN provides for static web assets.

How to eliminate wrong answers

Option A is wrong because Azure Queue Storage is a messaging service for asynchronous communication between application components, not designed for serving static files to users. Option C is wrong because Azure Table Storage is a NoSQL key-value store for structured data, not optimized for storing or serving binary files like CSS, JavaScript, or images. Option D is wrong because Azure Files provides SMB file shares primarily for lift-and-shift scenarios or shared file access, not for high-performance, direct-to-user serving of static web assets.

Practice this question →

110

MCQhard

You are developing a real-time analytics application that ingests IoT sensor data every second. The data is written to Azure Blob Storage as small JSON files (each ~1 KB). The application also needs to query the data based on device ID and timestamp. You need to design a storage solution that allows efficient querying without writing custom code for indexing. You have decided to use Azure Data Lake Storage Gen2. What should you do to optimize query performance?

A.Use Append Blobs to combine small writes into larger blobs.

B.Use a folder structure like /deviceid/yyyy/mm/dd/hh/ and set the device ID as the partition key.

C.Store all JSON files in a single folder and use Azure Data Lake Analytics to query.

D.Store the data in Azure SQL Database instead of Blob Storage.

AnswerB

This hierarchical folder structure, combined with setting the device ID as a partition key, is highly effective for real-time analytics. It enables query engines to perform partition pruning, skipping entire folders of data that do not match the query's criteria (e.g., specific device or time range). This significantly reduces the amount of data scanned, leading to faster query execution, lower computational costs, and improved performance for analytical workloads.

Why this answer

Azure Data Lake Storage Gen2 supports hierarchical namespaces, which allow you to organize data into folders and subfolders. By structuring the path as /deviceid/yyyy/mm/dd/hh/, you effectively partition the data by device ID and time, enabling efficient querying with tools like Azure Synapse or PolyBase without custom indexing. This leverages the directory structure as a natural partition key, minimizing the data scanned during queries.

Exam trap

The trap here is that candidates may confuse the need for efficient querying with data ingestion optimization (e.g., Append Blobs) or assume that a relational database is always required for querying, overlooking that Data Lake Storage Gen2's hierarchical namespace provides built-in partition elimination without custom indexing.

How to eliminate wrong answers

Option A is wrong because Append Blobs are designed for append-only operations (e.g., logging) and do not improve query performance; they still require scanning all blobs. Option C is wrong because storing all files in a single folder eliminates the benefits of partition elimination, forcing full scans even with Azure Data Lake Analytics. Option D is wrong because Azure SQL Database is a relational store that requires schema definition and indexing, contradicting the requirement to avoid custom indexing and to use Azure Data Lake Storage Gen2 as the chosen solution.

Practice this question →

111

MCQhard

A Blob-triggered function processing audit documents fires multiple times for the same blob after retries. What should the function design include?

A.Disable all logging

B.Idempotent processing based on blob name/version or metadata

C.Assume each event is delivered exactly once

D.Use public blob access

AnswerB

Implementing idempotent processing is crucial for blob-triggered functions, as it ensures that processing the same blob multiple times yields the same result without causing unintended side effects. By using the blob's unique name, ETag (version), or custom metadata as a key, the function can check if the document has already been processed successfully before performing any state-changing operations. This pattern effectively handles the "at-least-once" delivery guarantee inherent in many event-driven systems, preventing data corruption or redundant actions.

Why this answer

Azure Blob Storage triggers can cause multiple function invocations for the same blob due to retries, internal queue processing, or event-driven architecture guarantees. Designing the function to be idempotent—using the blob name, version, or metadata as a unique identifier—ensures that duplicate processing does not produce side effects like duplicate audit records or data corruption. This aligns with the at-least-once delivery semantics of Azure Blob Storage triggers.

Exam trap

The trap here is that candidates assume Azure Blob Storage triggers guarantee exactly-once delivery, similar to some queue-based triggers, but they actually follow at-least-once semantics, making idempotency essential for correct processing.

How to eliminate wrong answers

Option A is wrong because disabling logging does not prevent duplicate invocations; it only hides the evidence of retries, violating observability and debugging best practices. Option C is wrong because Azure Blob Storage triggers do not guarantee exactly-once delivery; they operate with at-least-once semantics, meaning the same blob can trigger the function multiple times due to retries or internal queue delays. Option D is wrong because public blob access does not affect invocation behavior; it only controls anonymous read access and introduces security risks without addressing duplicate processing.

Practice this question →

112

MCQhard

You are using Azure File Sync to sync on-premises file shares to Azure. You need to ensure that files are cached locally on the on-premises server for fast access, but only the most frequently accessed files should be cached. What should you configure?

A.Configure a caching rule using Azure File Sync's built-in cache size limit.

B.Configure a sync group with a custom server endpoint that filters files by last access time.

C.Enable cloud tiering on the server endpoint and set a volume free space policy.

D.Use the Invoke-AzStorageSyncFileRecall cmdlet to recall files on demand.

AnswerC

Enabling cloud tiering on the server endpoint and configuring a volume free space policy is the correct method to automatically manage the local cache. Cloud tiering intelligently moves infrequently accessed files to Azure Files, replacing them with reparse points (tiering stubs) locally. The volume free space policy ensures that a specified percentage of the local volume remains free, automatically recalling files as needed and tiering others to maintain the desired free space, effectively managing the local cache based on disk capacity and access patterns.

Why this answer

Cloud tiering on an Azure File Sync server endpoint allows you to keep only frequently accessed files cached locally while infrequently accessed files are tiered to Azure. By setting a volume free space policy, you control how much local disk space is reserved for frequently accessed files, ensuring that only the most accessed files remain cached. This directly meets the requirement of caching only the most frequently accessed files locally.

Exam trap

The trap here is that candidates often confuse cloud tiering with manual recall or think they can filter files by access time via sync group settings, but Azure File Sync's cloud tiering is the only built-in mechanism that automatically manages local caching based on access frequency.

How to eliminate wrong answers

Option A is wrong because Azure File Sync does not have a built-in 'caching rule' with a cache size limit; the correct mechanism is cloud tiering with a volume free space policy or date policy. Option B is wrong because sync groups and server endpoints do not filter files by last access time; cloud tiering uses last access time to determine which files to tier, but you cannot configure a custom filter on the server endpoint itself. Option D is wrong because Invoke-AzStorageSyncFileRecall is used to manually recall all tiered files to local storage, which would cache all files, not just the most frequently accessed ones, and is not a configuration for ongoing caching behavior.

Practice this question →

113

Multi-Selecthard

Which FOUR of the following are features of Azure Storage replication that provide high availability?

Select 4 answers

A.Locally redundant storage (LRS)

B.Geo-zone-redundant storage (GZRS)

C.Geo-redundant storage (GRS)

D.Zone-redundant storage (ZRS)

E.Azure Content Delivery Network (CDN)

AnswersA, B, C, D

Locally redundant storage (LRS) is the most fundamental and cost-effective replication strategy, maintaining three synchronous copies of your data within a single physical location or datacenter in the primary Azure region. This approach provides durability against common hardware failures, such as disk or rack outages, but offers no protection against a datacenter-wide disaster. It is suitable for applications that can tolerate data loss in the event of a major regional outage or that can easily reconstruct data.

Why this answer

LRS (A) is correct because it replicates data three times synchronously within a single Azure region, protecting against hardware failures and providing high availability within that region. GZRS (B) is correct because it combines ZRS replication across availability zones in the primary region with asynchronous replication to a secondary region, delivering both zone-level and regional high availability. GRS (C) is correct because it replicates data three times synchronously in the primary region and asynchronously to a paired secondary region, providing durability and availability if the primary region fails.

ZRS (D) is correct because it replicates data synchronously across three availability zones within a region, keeping data available even if one zone goes down. Azure CDN (E) is not a storage replication feature; it is a content delivery service that caches content at edge locations to reduce latency, not a replication mechanism for high availability of storage data.

Exam trap

Microsoft often tests the misconception that CDN is a storage replication feature, but it is a separate service for content delivery and caching, not a redundancy mechanism for Azure Storage accounts.

Practice this question →

114

MCQhard

You have an Azure Storage account with hierarchical namespace enabled (Azure Data Lake Storage Gen2). You need to provide an application with delegated access to a specific directory and its contents, with the ability to list, read, and write files. The access must be scoped to the directory and not allow access to other parts of the storage account. Which approach should you use?

A.Generate a shared access signature (SAS) token for the directory.

B.Assign the 'Storage Blob Data Contributor' RBAC role to the application at the storage account level.

C.Configure access control lists (ACLs) on the directory and assign the application's managed identity.

D.Use the storage account access key in the application.

AnswerC

ACLs allow granular permissions scoped to the directory, and managed identities can be used for authentication.

Why this answer

Azure Data Lake Storage Gen2 supports POSIX-like access control lists (ACLs) that can grant granular permissions to a specific directory and its contents. By configuring ACLs on the target directory and assigning the application's managed identity, you can precisely scope list, read, and write access to that directory without affecting other parts of the storage account. This approach avoids the need for account-level keys or RBAC roles, which would grant broader permissions.

Exam trap

The trap here is that candidates often confuse RBAC roles (which are coarse-grained and account/container-wide) with ACLs (which are fine-grained and directory/file-specific), leading them to choose Option B or A when the requirement is strict directory-level scoping.

How to eliminate wrong answers

Option A is wrong because a shared access signature (SAS) token for a directory can only delegate access at the container or directory level, but it cannot enforce fine-grained POSIX-style permissions (e.g., separate read/write/execute) and is typically scoped to the entire container or a path prefix, not a specific directory with ACL-level control. Option B is wrong because assigning the 'Storage Blob Data Contributor' RBAC role at the storage account level grants permissions to all containers and directories in the account, violating the requirement to scope access to a single directory. Option D is wrong because using the storage account access key provides full administrative access to the entire storage account, including all data and management operations, which is far too broad and insecure for delegated directory-level access.

Practice this question →

115

MCQmedium

An application needs to upload large thumbnail metadata to Blob Storage reliably over unstable networks. Which upload approach should be used?

A.Block blob staged block upload with commit

B.Page blob only

C.Append blob only

D.Table Storage batch operation

AnswerA

Block blobs are the standard for storing general-purpose large binary objects, and their staged block upload mechanism is specifically designed for reliable and efficient handling of large files. This process involves uploading individual blocks of data independently using 'Put Block', which can be done in parallel and retried if necessary, before finally committing the entire blob using 'Put Block List'. This method ensures data integrity, supports resumable uploads, and optimizes performance for large file transfers like thumbnail metadata, making it the most suitable choice.

Why this answer

Block blob staged block upload with commit is the correct approach because it allows uploading large thumbnails in smaller, independent blocks that can be retried individually if a network failure occurs. This method uses the Put Block and Put Block List REST APIs, enabling reliable uploads over unstable networks by committing only successfully uploaded blocks. It is specifically designed for large files and provides fine-grained control over upload progress and error recovery.

Exam trap

The trap here is that candidates may confuse blob types (block, page, append) and choose page blobs due to their 'reliability' reputation for VHDs, but fail to recognize that block blobs are the correct choice for large file uploads with retry logic over unstable networks.

How to eliminate wrong answers

Option B (Page blob only) is wrong because page blobs are optimized for random read/write operations (like VHD disks), not for uploading large sequential data like thumbnails, and they lack the staged block upload mechanism for reliable transfer over unstable networks. Option C (Append blob only) is wrong because append blobs are designed for append-only operations (e.g., logging), not for uploading large files with retry capability; they do not support staged block uploads. Option D (Table Storage batch operation) is wrong because Table Storage is for structured NoSQL data (entities), not for binary large objects like thumbnails, and batch operations are for transactional entity updates, not file uploads.

Practice this question →

116

MCQmedium

You are developing an Azure Function that processes images uploaded to a storage account. The function must generate thumbnails and write them to a separate container. You need to configure the function to trigger when a new blob is created, and you want to use the latest SDK with minimal code. Which trigger binding should you use?

A.HttpTrigger with a webhook registered to the storage account.

B.EventGridTrigger with an event subscription to the storage account's BlobCreated event.

C.BlobTrigger with the path parameter set to the source container.

D.QueueTrigger with a message added to a queue when a blob is uploaded.

AnswerB

EventGridTrigger is the recommended approach for reacting to blob creation events in Azure Storage. It provides near real-time processing by leveraging Azure Event Grid, which pushes events to the function. This eliminates the need for polling and reduces latency. The latest Azure Functions SDKs have first-class support for Event Grid triggers, and you can easily filter events to only BlobCreated. This approach is more scalable and efficient for image processing workloads, making it the best fit for the scenario.

Why this answer

The EventGridTrigger leverages Azure Event Grid to deliver blob creation events to the function in near real-time, eliminating polling and reducing code. It is the recommended trigger for reactive blob processing with the latest SDKs. BlobTrigger, QueueTrigger, and HttpTrigger either rely on polling, require additional components, or are not event-driven for storage, making them less efficient or more complex for this scenario.

Exam trap

The trap here is assuming BlobTrigger is always the simplest and most direct way to react to blob uploads, when in fact it uses polling and may introduce delays.

Practice this question →

117

MCQeasy

You are developing a solution that requires multiple Azure virtual machines to access the same set of files concurrently. The files are updated frequently and must be accessible with low latency. You need to choose a shared storage solution that integrates with Microsoft Entra ID (Microsoft Entra ID) for authentication. Which Azure storage solution should you use?

A.Azure Blob Storage with a private container.

B.Azure NetApp Files.

C.Azure Files shares.

D.Azure Disk Storage with shared disks.

AnswerC

Azure Files shares provide fully managed cloud file shares that support industry-standard SMB and NFS protocols, enabling multiple Azure Virtual Machines to access the same files concurrently. This service integrates directly with Microsoft Entra ID for authentication and authorization, allowing for granular access control based on user identities. Its native file system capabilities, including file locking and consistent access, make it the ideal solution for shared file storage requirements across multiple VMs.

Why this answer

Azure Files shares provide fully managed SMB and NFS file shares that can be accessed concurrently by multiple Azure VMs with low latency. They support identity-based authentication using Microsoft Entra ID (formerly Azure AD) over SMB, enabling granular access control via RBAC and NTFS ACLs. This makes Azure Files the correct choice for a shared, frequently updated file store requiring Entra ID integration.

Exam trap

The trap here is that candidates often confuse Azure NetApp Files (which supports SMB/NFS but not native Entra ID auth) with Azure Files (which does support Entra ID auth), or they mistakenly think Blob Storage can serve as a file share with low-latency concurrent access.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage with a private container is an object storage solution, not a file system; it does not support SMB/NFS protocols for concurrent VM file access and lacks native Microsoft Entra ID authentication for file-level operations. Option B is wrong because Azure NetApp Files, while providing high-performance shared file storage, does not natively integrate with Microsoft Entra ID for authentication; it relies on Active Directory Domain Services (AD DS) or LDAP, not Entra ID. Option D is wrong because Azure Disk Storage with shared disks is a block-level storage solution that requires cluster-aware file systems (e.g., Scale-out File Server) and does not support Microsoft Entra ID authentication; it is designed for SAN-like scenarios, not direct file sharing with identity-based access.

Practice this question →

118

MCQmedium

Audit logs are written daily as block blobs to an Azure Storage account. Logs older than 90 days must move to Cool tier automatically; logs older than 365 days must be deleted. The developer wants to implement this with no custom code and no recurring jobs. What is the correct solution?

A.Create a lifecycle management policy with two rules: tier to Cool after 90 days and delete after 365 days

B.Write an Azure Function with a Timer trigger that lists all blobs, checks last-modified dates, and tiers or deletes them via the SDK

C.Enable Blob versioning and set a version retention policy of 365 days

D.Configure a Logic App with a Recurrence trigger to enumerate and process blobs weekly

AnswerA

Lifecycle management policies are evaluated nightly by Azure. The two rules (tier after 90 days, delete after 365 days) are declared in JSON and applied to blobs matching the prefix filter. No code is required — the storage service acts on them automatically.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automate tier transitions and deletions based on blob age, without any custom code or recurring jobs. By defining a rule to tier blobs to Cool after 90 days and another rule to delete blobs after 365 days, the developer meets all requirements with a fully managed, no-code solution.

Exam trap

The trap here is that candidates may overlook the 'no custom code and no recurring jobs' constraint and choose a serverless compute option (Azure Function or Logic App) instead of the built-in lifecycle management policy, which is the only fully managed, no-code solution.

How to eliminate wrong answers

Option B is wrong because it requires custom code (Azure Function with Timer trigger) and a recurring job, violating the 'no custom code and no recurring jobs' constraint. Option C is wrong because Blob versioning with a retention policy only manages versions, not the base blobs, and it does not support tiering to Cool; it only retains or deletes versions, not the original blobs. Option D is wrong because a Logic App with a Recurrence trigger is a recurring job that requires custom logic to enumerate and process blobs, again violating the no-code and no-recurring-jobs requirement.

Practice this question →

119

MCQhard

You are developing an application that uses Azure Queue Storage. The application processes messages and must ensure that a message is not lost if the processing fails. Which visibility timeout setting should you use?

A.Set a short visibility timeout like 30 seconds

B.Set visibility timeout to 1 hour

C.Set visibility timeout to infinite

D.Set visibility timeout to 0 seconds

AnswerA

Setting a short visibility timeout, such as 30 seconds, is optimal because it provides sufficient time for a message consumer to process the message under normal operating conditions. If the consumer fails or crashes before completing processing and deleting the message, the message quickly becomes visible again in the queue. This allows another available worker to pick up and reprocess the message with minimal delay, ensuring high availability and fault tolerance for transient processing issues.

Why this answer

Setting a short visibility timeout (e.g., 30 seconds) ensures that if message processing fails, the message becomes visible again quickly for retry, preventing permanent loss. Azure Queue Storage uses a visibility timeout to hide a dequeued message from other consumers; if the processing fails and the message is not deleted, it reappears after the timeout expires. A short timeout balances retry speed with processing time, avoiding indefinite hiding that could lead to message loss if the consumer crashes.

Exam trap

The trap here is that candidates may think a longer visibility timeout provides more safety, but it actually risks message loss by hiding the message indefinitely if the consumer fails, whereas a short timeout ensures quick retries and eventual processing.

How to eliminate wrong answers

Option B is wrong because a 1-hour visibility timeout would hide the message for too long, delaying retries and potentially causing message loss if the consumer crashes without deleting the message. Option C is wrong because an infinite visibility timeout (maximum 7 days) would permanently hide the message, effectively losing it if processing fails and the message is never deleted. Option D is wrong because a visibility timeout of 0 seconds makes the message immediately visible to other consumers, defeating the purpose of ensuring processing without loss and risking duplicate processing.

Practice this question →

120

MCQeasy

You need to upload a large file (500 MB) to Azure Blob Storage from a .NET application with high throughput and resilience to network interruptions. Which approach should you use?

A.Use the Azure Storage SDK for .NET with the UploadAsync method that automatically splits the file into blocks

B.Use HTTP PUT with the entire file in a single request

C.Use the Azure Portal to upload the file

D.Use AzCopy with a single command

AnswerA

The Azure Storage SDK for .NET's UploadAsync method is specifically designed for efficient and resilient large file uploads to block blobs. It automatically divides the 500 MB file into smaller blocks, uploads them in parallel, and manages retries for transient failures. This approach significantly enhances throughput and ensures data integrity, making it the recommended programmatic solution for substantial data transfers within a .NET application.

Why this answer

The Azure Storage SDK's UploadAsync method automatically uses block blob staging, splitting the 500 MB file into multiple blocks that are uploaded in parallel. This provides high throughput and resilience: if a network interruption occurs, only the failed blocks need to be retried, not the entire file. The SDK handles block management and final commit, making it ideal for large file uploads.

Exam trap

The trap here is that candidates may choose AzCopy (Option D) because it is a well-known high-performance tool, but the question explicitly requires a .NET application approach, making the SDK's UploadAsync the correct integrated solution.

How to eliminate wrong answers

Option B is wrong because HTTP PUT with the entire file in a single request is limited to 256 MB (or 64 MB for older API versions) and offers no retry granularity; a network interruption would require re-uploading the entire file. Option C is wrong because the Azure Portal upload is designed for small files (typically under 256 MB) and lacks programmatic control, parallelization, or resilience to interruptions. Option D is wrong because while AzCopy is a robust tool for bulk transfers, it is a command-line utility, not a .NET SDK approach; the question specifies using a .NET application, making AzCopy an external dependency rather than an integrated solution.

Practice this question →

121

MCQmedium

You are developing a C# application that stores sensitive documents in Azure Blob Storage. The application needs 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 the BlobServiceClient and BlobContainerClient are properly initialized.)

A.var sasBuilder = new BlobSasBuilder { BlobContainerName = container.Name, Permissions = "rl", ExpiresOn = DateTimeOffset.UtcNow.AddHours(1) }; var sasUri = container.GenerateSasUri(sasBuilder);

B.var sasBuilder = new BlobSasBuilder { Permissions = "r", ExpiresOn = DateTimeOffset.UtcNow.AddHours(1) }; var sasUri = container.GenerateSasUri(sasBuilder);

C.var sasToken = container.GetSasToken(permissions: "rl", duration: TimeSpan.FromHours(1));

D.var sasBuilder = new BlobSasBuilder { Permissions = "rl", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1) }; var sasUri = container.GenerateSasUri(sasBuilder);

AnswerA

This code correctly instantiates a BlobSasBuilder and sets the essential BlobContainerName property to scope the SAS to the target container. It grants both read ('r') and list ('l') permissions, which are appropriate for accessing and enumerating documents, and defines a valid expiry time of one hour. Finally, the GenerateSasUri method on the BlobContainerClient correctly produces the full URI including the generated Shared Access Signature.

Why this answer

It creates a `BlobSasBuilder` with the container name, permissions set to "rl" (read and list), and an expiration time of exactly 1 hour from the current UTC time. The `GenerateSasUri` method then produces a SAS URI that grants the specified permissions for the container. This matches the requirement for a time-limited SAS that allows only read and list operations on blobs in the container.

Exam trap

The trap here is that candidates often think they must set `StartsOn` to the current time to make the SAS valid immediately, but Azure Storage automatically treats the SAS as valid from the time of generation if `StartsOn` is omitted, and including it can cause failures due to clock skew.

How to eliminate wrong answers

Option B is wrong because it sets permissions to "r" (read only) instead of "rl" (read and list), so it does not grant the required list permission. Option C is wrong because `GetSasToken` is not a valid method on `BlobContainerClient`; the correct approach is to use `BlobSasBuilder` and `GenerateSasUri`. Option D is wrong because it includes a `StartsOn` property set to the current time, which is unnecessary and can cause issues with clock skew; the SAS should start immediately without an explicit start time to avoid potential time synchronization problems.

Practice this question →

122

MCQhard

Your company, Contoso Ltd., operates a global e-commerce platform. The platform stores product images in Azure Blob Storage. Currently, the images are stored in a single storage account in the West US region. The application uses HTTP to download images. Users in Europe report slow load times. You need to reduce latency for European users. The solution must minimize costs and administrative overhead. You also need to ensure that images are served over HTTPS. You have the following requirements: 1) Users in Europe must have low-latency access. 2) The solution must be cost-effective. 3) The solution must not require changes to the application code. 4) Images must be served over HTTPS. Which course of action should you recommend?

A.Use Azure Front Door with the storage account as a backend.

B.Create an Azure CDN profile and add a CDN endpoint that points to the storage account. Enable HTTPS on the CDN endpoint.

C.Create a secondary storage account in Europe and use asynchronous replication. Update the application to use the secondary endpoint for European users.

D.Enable geo-redundant storage (GRS) on the storage account.

AnswerB

Creating an Azure CDN profile and endpoint pointing to the storage account is the most effective solution for globally distributing static content. CDN caches content at geographically distributed edge locations, significantly reducing latency for users worldwide by serving data from the nearest point of presence. Enabling HTTPS on the CDN endpoint ensures secure communication, encrypting data in transit and maintaining user trust, which is crucial for an e-commerce platform.

Why this answer

Azure CDN provides a global, distributed network of edge servers that cache content closer to users, reducing latency for European users without requiring application code changes. Enabling HTTPS on the CDN endpoint ensures images are served securely over HTTPS, meeting the requirement. This solution is cost-effective as it uses a pay-as-you-go model and minimizes administrative overhead by leveraging a managed service.

Exam trap

The trap here is confusing Azure CDN with Azure Front Door or geo-replication, where candidates might think a global load balancer or storage replication is needed for latency reduction, but Azure CDN is the simplest and most cost-effective solution for static content caching without code changes.

How to eliminate wrong answers

Option A is wrong because Azure Front Door is primarily a global load balancer and application delivery controller optimized for HTTP/HTTPS traffic with advanced routing and WAF capabilities, but it is more expensive than Azure CDN for simple static content delivery and introduces unnecessary complexity for this use case. Option C is wrong because it requires application code changes to redirect European users to the secondary endpoint, violating the 'no changes to application code' requirement, and asynchronous replication adds cost and administrative overhead. Option D is wrong because geo-redundant storage (GRS) replicates data to a paired region for disaster recovery, not for low-latency content delivery; it does not serve content from the secondary region and does not provide HTTPS termination at the edge.

Practice this question →

123

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? The design must avoid adding custom operational scripts.

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 hot partition arises when a single logical partition key value receives an excessive volume of requests, exhausting its allocated throughput and causing throttling. Choosing a partition key with higher cardinality ensures a greater number of distinct logical partitions, while ensuring even request distribution across these keys prevents any single partition from becoming a bottleneck. This strategy effectively spreads both data storage and request throughput across multiple physical partitions, resolving the hot partition issue and improving scalability.

Why this answer

Hot-partition throttling occurs when a partition key has low cardinality (few distinct values), causing uneven request distribution and exceeding the physical partition's throughput limits. Choosing a partition key with higher cardinality and even request distribution spreads operations across more physical partitions, eliminating throttling without custom scripts.

Exam trap

The trap here is that candidates confuse throughput scaling mechanisms (TTL, analytical store, stored procedures) with partition key design, which is the only way to resolve hot-partition throttling without custom scripts.

How to eliminate wrong answers

Option A is wrong because increasing the default TTL only affects document expiration and deletion, not partition-level throughput or request distribution. Option B is wrong because enabling analytical store only adds a columnar store for analytical queries; it does not affect transactional request routing or partition key design. Option D is wrong because using a stored procedure for every write does not change the partition key or distribution; it still writes to the same logical partition, so throttling persists.

Practice this question →

124

Multi-Selectmedium

You are designing a data archiving solution for compliance. Data must be stored for 7 years, with immediate deletion prohibited until the retention period expires. The solution must minimize storage costs while ensuring data is not modifiable. Which THREE Azure features should you combine?

Select 3 answers

A.Azure Blob Storage

B.Immutable storage with time-based retention policy

C.Azure Files

D.Cool or Archive access tier

E.Azure Backup

AnswersA, B, D

Azure Blob Storage is the foundational, highly scalable, and durable object storage service in Azure, making it the primary choice for storing large volumes of unstructured data like archives. Its inherent design supports massive scale, high availability, and cost-effectiveness, providing the essential platform upon which advanced archiving features like immutability and tiered storage are built for compliance solutions.

Why this answer

Azure Blob Storage is the correct foundational service because it supports immutable storage, which enforces a WORM (Write Once, Read Many) policy. This ensures data cannot be modified or deleted during the retention period, meeting compliance requirements. Combined with time-based retention policies and cool/archive tiers, it provides a cost-effective, unmodifiable archive solution.

Exam trap

The trap here is that candidates often confuse Azure Files or Azure Backup as viable archiving solutions, overlooking that only Blob Storage with immutable policies provides the WORM guarantee required for compliance-driven data retention.

Practice this question →

125

MCQeasy

You want to ensure that data in an Azure Storage account is replicated across multiple Azure regions to protect against regional outages. Which replication option should you choose?

A.Geo-redundant storage (GRS)

B.Locally-redundant storage (LRS)

C.Read-access geo-redundant storage (RA-GRS)

D.Zone-redundant storage (ZRS)

AnswerA

Geo-redundant storage (GRS) is the correct choice because it ensures data durability by asynchronously replicating data from the primary region to a secondary region hundreds of miles away. This strategy protects against regional outages or major disasters affecting the entire primary datacenter location. With GRS, Azure maintains three copies of your data within the primary region and three additional copies in the paired secondary region, offering 11 nines (99.999999999%) of durability over a given year. This robust replication guarantees that your data remains available even if the primary region becomes completely unavailable.

Why this answer

Geo-redundant storage (GRS) replicates your data synchronously three times within a primary region using LRS, then asynchronously replicates to a secondary region hundreds of miles away. This ensures data survives a complete regional outage because the secondary copy is available for read or write access after a failover, meeting the requirement for cross-region protection.

Exam trap

The trap here is that candidates often choose RA-GRS because they think read access is required for disaster recovery, but the question only asks for replication to protect against regional outages, making GRS the correct choice without the extra read-access feature.

How to eliminate wrong answers

Option B (LRS) is wrong because it replicates data only within a single datacenter in one region, providing no protection against a regional outage. Option C (RA-GRS) is wrong because while it does replicate across regions like GRS, it additionally provides read access to the secondary region during normal operations, which is not required by the question—the question only asks for replication to protect against regional outages, not read access. Option D (ZRS) is wrong because it replicates data synchronously across three availability zones within a single region, protecting against zone-level failures but not against a full regional outage.

Practice this question →

126

MCQmedium

Your company stores backup files in an Azure Blob Storage account. These files are written once and then need to be retained for 7 years. During the first year, the files are accessed weekly. After the first year, they are accessed rarely (once per month). You want to minimize storage costs. Which combination of access tiers and lifecycle management should you apply?

A.Store in Hot tier and move to Cool after 1 year, then to Archive after 7 years.

B.Store in Cool tier and move to Archive after 1 year.

C.Store directly in Archive tier and rehydrate to Cool when needed for access.

D.Store in Hot tier and move to Archive after 90 days.

AnswerA

Moving to Cool after 1 year is too late; the data is already rarely accessed. Also moving to Archive after 7 years is unnecessary because the retention period ends. The data should be in Archive for most of the retention.

Why this answer

For data accessed weekly during the first year, the Hot tier is appropriate, or the Cool tier if storage cost savings significantly outweigh transaction costs. For data accessed monthly after the first year, the Cool tier is the most cost-effective choice, balancing lower storage costs with reasonable access costs without incurring rehydration fees or significant latency. The Archive tier is suitable only for data that is rarely accessed (e.g., less than once a year) and can tolerate significant retrieval latency and cost.

Therefore, the optimal strategy among the given options is to store in Hot for the first year, move to Cool for the subsequent years of monthly access, and then to Archive only after the 7-year retention period if access truly ceases.

Exam trap

The trap here is that candidates assume the Hot tier is always the best starting point for any access pattern, ignoring that Cool tier is cheaper for data accessed less than once a month, and that Archive tier is not suitable for data that requires regular access within the first year due to its high rehydration latency and cost.

How to eliminate wrong answers

Option A is wrong because moving files to the Archive tier after 7 years is unnecessary—the files are retained for exactly 7 years, so moving them to Archive at the end of retention provides no cost benefit and may incur deletion charges if deleted immediately. Option C is wrong because storing directly in the Archive tier would require rehydration (which can take up to 15 hours) for the weekly accesses during the first year, causing unacceptable latency and additional read/retrieval costs. Option D is wrong because moving files to the Archive tier after only 90 days ignores the first-year weekly access pattern, leading to frequent rehydration costs and latency; also, the Hot tier is more expensive than Cool for the initial storage.

Practice this question →

127

MCQhard

Your company uses Azure File Sync to sync on-premises file shares to Azure Files. You notice that some files are not syncing to Azure. You need to diagnose the issue with minimal administrative effort. Which Azure service should you use?

A.Microsoft Sentinel

B.Azure Storage Insights

C.Azure Monitor

D.Azure Log Analytics

AnswerC

Azure Monitor is the comprehensive solution for collecting, analyzing, and acting on telemetry data from Azure and on-premises environments. For Azure File Sync, it offers built-in metrics, logs, and alerts specifically designed to monitor sync health, server endpoint status, cloud tiering activity, and common sync errors. Its integration provides a centralized platform for diagnosing and troubleshooting File Sync replication issues effectively through pre-built workbooks and diagnostic views.

Why this answer

Azure Monitor provides the Azure File Sync monitoring blade, which offers pre-built metrics and alerts for sync health, file-level errors, and sync session status. This allows you to diagnose sync failures with minimal administrative effort by directly viewing sync group health, per-server sync status, and error codes without needing to configure additional log queries or workbooks.

Exam trap

The trap here is that candidates confuse Azure Monitor (the overarching monitoring platform) with Azure Log Analytics (a component of Azure Monitor that requires manual query authoring), leading them to choose Log Analytics because they think they need to write custom queries, when in fact the pre-built Azure File Sync monitoring blade in Azure Monitor provides the quickest diagnosis path.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel is a SIEM (Security Information and Event Management) tool focused on security threat detection and response, not on diagnosing Azure File Sync sync issues. Option B is wrong because Azure Storage Insights provides monitoring for Azure Storage accounts (blobs, tables, queues) but does not include the Azure File Sync monitoring blade or sync-specific metrics. Option D is wrong because Azure Log Analytics is a log query and analysis service that requires you to write custom KQL queries to extract sync data, which involves more administrative effort than using the pre-built Azure Monitor sync monitoring blade.

Practice this question →

128

MCQmedium

You are developing a solution that must encrypt data before it is sent to Azure Blob Storage. You need to manage encryption keys yourself using Azure Key Vault. Which approach should you use?

A.Use Azure Information Protection to encrypt the files.

B.Use Azure Disk Encryption for the storage account.

C.Implement client-side encryption using the Azure Storage SDK and store the encryption keys in Azure Key Vault.

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

AnswerC

Implementing client-side encryption using the Azure Storage SDK ensures that data is encrypted by the application on the client machine *before* it is transmitted over the network and stored in Azure Storage. This approach provides the highest level of control over the encryption process and keys, directly addressing the requirement to encrypt data *before* storage. Storing the encryption keys securely in Azure Key Vault is a best practice, centralizing key management and enhancing security posture.

Why this answer

Client-side encryption with the Azure Storage SDK allows you to encrypt data before it leaves your application, ensuring it is never transmitted or stored in plaintext. By storing the encryption keys in Azure Key Vault, you maintain full control over key management, which aligns with the requirement to manage encryption keys yourself.

Exam trap

The trap here is that candidates often confuse server-side encryption (SSE) with client-side encryption, assuming that SSE with customer-managed keys satisfies the requirement to encrypt data before sending, when in fact SSE only encrypts data at rest after it arrives at Azure.

How to eliminate wrong answers

Option A is wrong because Azure Information Protection is a classification and labeling solution for documents and emails, not a mechanism for encrypting data before sending to Blob Storage. Option B is wrong because Azure Disk Encryption is used to encrypt virtual machine disks, not data being uploaded to Blob Storage. Option D is wrong because Azure Storage Service Encryption (SSE) with customer-managed keys encrypts data at rest on the server side, but the data is still transmitted in plaintext to Azure; it does not meet the requirement to encrypt data before it is sent.

Practice this question →

129

Multi-Selectmedium

Which TWO of the following are valid approaches to secure access to Azure Blob Storage?

Select 2 answers

A.Use a Shared Access Signature (SAS) token

B.Use Azure Front Door to restrict access

C.Assign RBAC roles like Storage Blob Data Contributor

D.Embed storage account keys in client code

E.Enable public blob access

AnswersA, C

Shared Access Signatures (SAS) tokens provide a secure, delegated way to grant time-limited access to specific Azure Storage resources, such as blobs or containers. They allow you to define granular permissions (read, write, delete, list) and a validity period, ensuring that clients only have the necessary access for a defined duration without exposing your storage account keys. This approach is highly effective for distributing access to external clients or web applications.

Why this answer

Option A is correct because a Shared Access Signature (SAS) is a signed URI token that grants time-limited, scoped, and permission-specific delegated access to Blob Storage resources (containers, blobs, or specific operations like read/write) without exposing the storage account keys. Option C is correct because Azure RBAC roles such as Storage Blob Data Contributor (and Storage Blob Data Reader/Owner) grant Microsoft Entra ID identities fine-grained, least-privilege access to blob data at the management and data-plane level, which is the recommended modern approach for securing Blob Storage. Option B is not a valid access-control mechanism for Blob Storage itself — Azure Front Door is a global HTTP load balancer/CDN that can front a storage endpoint but does not authenticate or authorize blob access.

Option D is incorrect because embedding storage account keys in client code exposes full administrative credentials to anyone who obtains the code, violating security best practices. Option E is incorrect because enabling public blob access allows anonymous unauthenticated reads of blobs, which directly weakens rather than secures access.

Exam trap

The trap here is that candidates often confuse Azure Front Door's traffic routing and WAF capabilities with actual blob-level authentication, or they mistakenly believe embedding storage account keys is acceptable for client-side applications, ignoring the severe security implications.

Practice this question →

130

MCQeasy

You need to store millions of small log entries (each <1 KB) per day from an IoT device. The logs are rarely read. Which storage solution is most cost-effective?

A.Azure Blob Storage Block Blob

B.Azure SQL Database

C.Azure Table Storage

D.Azure Files

AnswerA

Azure Blob Storage Block Blobs are the ideal choice for storing millions of small, unstructured log entries due to their massive scalability, cost-effectiveness, and support for tiered storage. They are optimized for handling billions of objects, allowing for efficient ingestion and retrieval of 1KB log files. Lifecycle management policies can automatically move older logs to cooler tiers (Cool or Archive), significantly reducing long-term storage costs while maintaining data availability.

Why this answer

Azure Blob Storage Block Blob is the most cost-effective solution for storing millions of small log entries (<1 KB) that are rarely read because it offers extremely low storage costs per GB, supports high-throughput ingestion, and is optimized for large-scale, append-oriented workloads. Block blobs can be stored in the 'Cool' or 'Archive' access tier to further reduce costs, and they can be efficiently batched into larger blocks (up to 100 MB per block) to minimize transaction costs.

Exam trap

The trap here is that candidates often choose Azure Table Storage because they think it is designed for small, structured log entries, but they overlook that Blob Storage's Cool/Archive tiers provide dramatically lower storage costs for rarely accessed data, making it the more cost-effective choice despite Table Storage's lower per-entity transaction cost.

How to eliminate wrong answers

Option B (Azure SQL Database) is wrong because it is a relational database designed for transactional workloads with high query performance, not for high-volume, low-cost storage of small log entries; its per-GB storage cost is significantly higher than Blob Storage, and it incurs additional costs for compute and IO. Option C (Azure Table Storage) is wrong because while it can store small entries, its cost per GB is higher than Blob Storage, and it is optimized for key-value lookups rather than bulk append-only logs; it also has a 1 MB entity size limit, which is not a problem here, but the overall cost for millions of entries is less efficient than block blobs in Cool/Archive tiers. Option D (Azure Files) is wrong because it is a fully managed file share for SMB protocol access, designed for shared file storage with low-latency access, not for high-volume, low-cost log archiving; its per-GB cost is higher than Blob Storage, and it lacks the tiering options (Cool/Archive) that make Blob Storage cost-effective for rarely accessed data.

Practice this question →

131

MCQhard

A .NET app performs point reads from Cosmos DB by id and partition key. The team wants the lowest latency and best throughput efficiency. Which API call pattern should be used?

A.ReadItemAsync with id and partition key

B.Stored procedure scanning all items

C.Change feed processor

D.SELECT * query without partition key

AnswerA

The ReadItemAsync method, when provided with both the item's unique identifier (id) and its partition key, represents the most efficient point-read operation in Azure Cosmos DB. This combination allows the Cosmos DB gateway to route the request directly to the specific physical partition containing the item, bypassing the need for index lookups or cross-partition fan-out. It minimizes Request Units (RUs) consumed and latency, making it ideal for single-item retrieval.

Why this answer

ReadItemAsync with id and partition key is the most efficient API call pattern for point reads in Cosmos DB because it directly accesses the document using the partition key and item ID, requiring only a single request to the exact partition and replica. This avoids the overhead of querying multiple partitions or scanning all items, resulting in the lowest latency and best throughput efficiency, as it consumes the minimum request units (RUs) possible for a read operation.

Exam trap

The trap here is that candidates may confuse efficient point reads with query-based approaches or event-driven patterns, mistakenly believing that stored procedures or change feed processors can achieve lower latency, when in reality they introduce unnecessary overhead for simple single-item lookups.

How to eliminate wrong answers

Option B is wrong because stored procedures are designed for transactional operations across multiple items within the same partition, not for efficient point reads; they incur higher RU costs and latency due to script execution and potential full partition scans. Option C is wrong because the Change feed processor is used for capturing and processing incremental changes (events) to items, not for performing point reads; it introduces additional latency and resource overhead for real-time read scenarios. Option D is wrong because a SELECT * query without partition key results in a cross-partition query that scans all physical partitions, dramatically increasing RU consumption and latency compared to a direct point read.

Practice this question →

132

MCQmedium

You are using Azure File Storage to share configuration files across multiple virtual machines running a legacy application. The application requires SMB 3.0 protocol with encryption. You need to ensure the file share is accessible from all VMs without exposing it to the internet. Which configuration should you use?

A.Create a storage account with a shared access signature (SAS) token and mount using the SAS URL

B.Create a storage account with a public endpoint and use a VPN gateway to connect the VMs

C.Create a storage account with a public endpoint and configure the firewall to allow only the VNet

D.Create a storage account with a private endpoint and mount the file share using the private IP

AnswerD

Creating a storage account with a private endpoint establishes a network interface for the storage account directly within a specified virtual network subnet. This assigns a private IP address from the VNet's address space to the storage account, making it accessible only from within that VNet or peered networks. All traffic to the file share then flows entirely within the Azure backbone network, bypassing the public internet and ensuring secure, private connectivity using the private IP.

Why this answer

A private endpoint assigns the storage account a private IP address from your virtual network, allowing VMs to access the file share over SMB 3.0 with encryption without exposing the storage account to the public internet. This meets the requirement for secure, private connectivity while supporting the legacy application's SMB 3.0 protocol needs.

Exam trap

The trap here is that candidates often confuse network-level access controls (like firewalls or VPNs) with true private connectivity, mistakenly believing that restricting access via firewall rules or VPN gateways eliminates public endpoint exposure, when only a private endpoint achieves that.

How to eliminate wrong answers

Option A is wrong because a shared access signature (SAS) token provides time-limited delegated access but still uses the public endpoint, exposing the storage account to the internet; it does not eliminate public exposure. Option B is wrong because using a VPN gateway with a public endpoint still leaves the storage account's public endpoint accessible from the internet, and the VPN only secures the connection between the VMs and the gateway, not the storage endpoint itself. Option C is wrong because configuring the firewall to allow only the VNet still requires the storage account to have a public endpoint, which is inherently internet-facing; firewall rules restrict access but do not remove the public endpoint, leaving the storage account potentially discoverable and violating the 'not exposing it to the internet' requirement.

Practice this question →

133

Multi-Selecteasy

You need to implement a solution for storing and retrieving large amounts of unstructured data (e.g., images, videos, backups) in Azure, with high durability and availability. The solution must allow access from anywhere via HTTP/HTTPS and support both public and private access. Which TWO Azure storage services should you consider?

Select 2 answers

A.Azure Table Storage

B.Azure Data Lake Storage Gen2

C.Azure Queue Storage

D.Azure Blob Storage

E.Azure Files

AnswersB, D

Azure Data Lake Storage Gen2 is the optimal choice for storing and retrieving large unstructured data, especially in big data analytics scenarios. Built upon Azure Blob Storage, it adds a hierarchical namespace and HDFS-compatible access, enabling petabyte-scale data lakes with high throughput and low latency. This makes it ideal for analytical workloads requiring POSIX-compliant file system semantics and integration with services like Azure Synapse Analytics and Azure Databricks.

Why this answer

Azure Blob Storage is purpose-built for storing large amounts of unstructured data such as images, videos, and backups, offering high durability (99.9999999999% with RA-GRS) and availability. It supports access via HTTP/HTTPS from anywhere, and provides both public (anonymous) and private (SAS tokens, RBAC) access controls, making it the primary choice for this scenario.

Exam trap

The trap here is that candidates may confuse Azure Data Lake Storage Gen2 as a separate service, but it is actually built on top of Blob Storage, so both B and D are correct because they represent the same underlying technology for unstructured data.

Practice this question →

134

MCQmedium

You are designing a solution to store and serve large media files (500 MB to 2 GB) to a global audience. The files must be accessible via HTTPS with low latency. Which Azure Storage option should you use?

A.Azure Blob Storage with Azure CDN

B.Azure Queue Storage

C.Azure Files with SMB protocol

D.Azure Table Storage

AnswerA

Azure Blob Storage is highly optimized for storing massive amounts of unstructured data, including large media files, offering excellent scalability, durability, and cost-effectiveness. When combined with Azure CDN, it provides a robust solution for serving content globally by caching media at edge locations closer to users. This significantly reduces latency and improves throughput, ensuring a superior user experience for media consumption worldwide by minimizing the distance data travels.

Why this answer

Azure Blob Storage is optimized for storing large, unstructured data like media files, and integrating it with Azure CDN caches content at edge nodes worldwide, reducing latency for global users. HTTPS access is natively supported, and CDN ensures low-latency delivery by serving files from the nearest point of presence (PoP).

Exam trap

The trap here is that candidates may confuse Azure Files (which supports SMB and REST) as a viable option for global media delivery, but it lacks built-in CDN integration and is not designed for low-latency HTTPS serving to a global audience.

How to eliminate wrong answers

Option B is wrong because Azure Queue Storage is designed for asynchronous message passing between application components, not for storing or serving large files. Option C is wrong because Azure Files with SMB protocol is intended for file shares accessed via SMB (port 445) from virtual machines or on-premises systems, not optimized for global HTTPS delivery of large media files. Option D is wrong because Azure Table Storage is a NoSQL key-value store for structured data, not suitable for large binary objects like media files.

Practice this question →

135

MCQmedium

You are designing a solution to store large amounts of structured data that is accessed frequently and requires low-latency reads. The data must be globally distributed and support automatic failover. Which Azure storage solution should you recommend?

A.Azure Table Storage with geo-replication.

B.Azure Cosmos DB with multi-region writes and automatic failover.

C.Azure SQL Database with active geo-replication and failover groups.

D.Azure Blob Storage with read-access geo-redundant storage (RA-GRS).

AnswerB

Azure Cosmos DB is a globally distributed, multi-model database service designed for high availability and low-latency access worldwide. Its multi-region write capability allows applications to write data to any configured region, with Cosmos DB handling data replication and consistency across all regions. Combined with automatic failover, this ensures continuous availability and resilience against regional outages, making it ideal for globally distributed structured data solutions requiring stringent SLAs.

Why this answer

Azure Cosmos DB with multi-region writes and automatic failover is the correct choice because it provides globally distributed, low-latency reads and writes with automatic failover at the database level. It supports multiple consistency models and guarantees single-digit millisecond read latencies, making it ideal for frequently accessed structured data that requires global distribution and high availability.

Exam trap

The trap here is that candidates often confuse Azure Table Storage (which is a NoSQL key-value store) with Cosmos DB's Table API, but Table Storage lacks the global distribution, automatic failover, and low-latency guarantees that Cosmos DB provides, leading them to choose Option A incorrectly.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage with geo-replication offers only eventual consistency and higher latency compared to Cosmos DB, and it does not support automatic failover or multi-region writes natively. Option C is wrong because Azure SQL Database with active geo-replication and failover groups is designed for relational data and provides strong consistency, but it does not offer the same low-latency global distribution and multi-region write capabilities as Cosmos DB; it also requires manual failover configuration in some scenarios. Option D is wrong because Azure Blob Storage with read-access geo-redundant storage (RA-GRS) is optimized for unstructured blob data, not structured data, and it only supports read access in the secondary region during failover, not automatic failover for writes.

Practice this question →

136

MCQmedium

An application stores customer invoices in Azure Blob Storage. Deleted blobs must be recoverable for 14 days. What should be enabled? The design must avoid adding custom operational scripts.

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

B.Archive access tier

C.Static website hosting

D.Immutable blob legal hold

AnswerA

Blob soft delete retains deleted blobs for a specified retention period, letting them be restored natively without scripts. Setting 14 days matches the recoverability requirement exactly, satisfying the constraint that no custom operational tooling be introduced. Microsoft Entra ID permissions govern restore operations.

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 allows recovery of deleted invoices within that window without custom scripts, meeting the requirement exactly.

Exam trap

The trap here is that candidates might confuse soft delete with versioning or immutable storage, but soft delete is the only option that provides a configurable retention period for recovering deleted blobs without custom code.

How to eliminate wrong answers

Option B is wrong because the Archive access tier is for cost-effective storage of infrequently accessed data, not for recovering deleted blobs. Option C is wrong because static website hosting enables serving static content from a container, not blob deletion recovery. 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 →

137

MCQeasy

You need to provide temporary access to a file in Azure Blob Storage for a duration of one hour. The solution must not require authentication. What should you generate?

A.Storage account key.

B.Enable anonymous public read access on the container.

C.A user delegation key.

D.A shared access signature (SAS) with read permission and an expiration time of one hour.

AnswerD

A Shared Access Signature (SAS) is the ideal solution for providing temporary, delegated access to specific Azure Storage resources, such as a single blob. By configuring it with read permission and a one-hour expiration time, you grant precisely the required access without exposing your storage account key or making the resource permanently public. The SAS token provides a secure, time-limited URI that can be shared with the intended recipient, fulfilling all requirements.

Why this answer

A shared access signature (SAS) with read permission and a one-hour expiration provides time-limited, delegated access to a specific blob without requiring authentication. The SAS token is appended to the URL and grants the specified permissions for the defined duration, meeting the requirement of temporary access without authentication.

Exam trap

The trap here is that candidates often confuse a SAS with a storage account key or user delegation key, mistakenly thinking those provide temporary access without authentication, when in fact they are secrets used to generate SAS tokens or require authentication themselves.

How to eliminate wrong answers

Option A is wrong because a storage account key provides full administrative access to the entire storage account and never expires, which violates the requirement for temporary access and no authentication. Option B is wrong because enabling anonymous public read access on the container makes the blob permanently accessible to anyone without any time limit, failing the one-hour duration requirement. Option C is wrong because a user delegation key is used to sign a SAS with Azure AD credentials, but it still requires authentication to obtain and does not directly provide access without authentication.

Practice this question →

138

MCQmedium

You need to upload a large file (10 GB) to Azure Blob Storage with the ability to pause and resume the upload. Which approach should you use?

A.Use a single Put Blob operation

B.Use the Azure Portal to upload the file

C.Use AzCopy with the /SyncCopy parameter

D.Use the Azure Storage SDK to upload block blobs in parallel

AnswerD

The Azure Storage SDK provides the most robust and efficient method for uploading large files like 10 GB to block blobs. It automatically handles breaking the large file into smaller blocks, uploading these blocks in parallel using Put Block operations, and then committing them with a Put Block List operation. This approach enables resumable uploads, significantly improves performance by utilizing available bandwidth, and ensures reliability for very large files by managing individual block transfers.

Why this answer

Uploading a large file (10 GB) to Azure Blob Storage with pause/resume capability requires breaking the file into blocks and uploading them in parallel using the Azure Storage SDK. The SDK supports block blob operations, allowing you to track progress, retry failed blocks, and resume from the last committed block. A single Put Blob operation cannot handle files larger than 5 GB, and neither the Azure Portal nor AzCopy with /SyncCopy provides programmatic pause/resume control.

Exam trap

The trap here is that candidates often confuse AzCopy's resume capability with the need for programmatic control, but the question specifically requires the ability to pause and resume programmatically, which only the SDK provides through block-level management.

How to eliminate wrong answers

Option A is wrong because a single Put Blob operation has a maximum size limit of 5 GB for a single upload, so it cannot handle a 10 GB file. Option B is wrong because the Azure Portal has a file size limit of approximately 1 GB for direct uploads and does not support pause/resume functionality. Option C is wrong because AzCopy's /SyncCopy parameter is used for copying blobs between storage locations, not for uploading files with pause/resume; AzCopy does support resume for uploads via its own mechanism, but /SyncCopy is specifically for incremental copy, not upload control.

Practice this question →

139

MCQmedium

You need to grant a user the ability to read and write blobs in a specific container for 24 hours. The solution must use delegated access without exposing the storage account key. What should you use?

A.Storage account access key

B.Account shared access signature (SAS)

C.Service shared access signature (SAS)

D.User delegation shared access signature (SAS)

AnswerD

A User delegation SAS is the most secure and recommended method for granting delegated access to Azure Storage resources, as it is signed with an Azure AD credential. This SAS token allows permissions to be granted based on Azure RBAC roles assigned to the user or service principal, ensuring adherence to the principle of least privilege. It eliminates the need to distribute or manage storage account keys, significantly enhancing security for user-specific access to blobs.

Why this answer

A user delegation SAS is secured with Azure AD credentials and is the only SAS type that uses delegated authorization without exposing the storage account key. It allows you to grant granular, time-limited access (e.g., 24 hours) to a specific container for read and write operations, meeting the requirement exactly.

Exam trap

The trap here is that candidates often confuse a service SAS (which is scoped to a single service like Blob) with a user delegation SAS, but the key differentiator is that a user delegation SAS uses Azure AD for signing, not the account key.

How to eliminate wrong answers

Option A is wrong because using the storage account access key directly exposes the key, violating the requirement to avoid exposing it. Option B is wrong because an account SAS is signed with the storage account key, which also exposes the key and is not delegated. Option C is wrong because a service SAS is also signed with the storage account key, not with Azure AD credentials, and thus does not provide delegated access.

Practice this question →

140

MCQeasy

A background worker retrieves a message from Azure Queue Storage and begins processing. The processing logic takes longer than the configured visibility timeout. Before the worker finishes, the timeout expires. What happens to the message?

A.The message becomes visible again in the queue and another worker can dequeue it

B.The message is permanently deleted because the worker already dequeued it

C.The message moves to a dead-letter queue after the visibility timeout expires

D.Processing continues uninterrupted; the visibility timeout applies only to the initial retrieval window

AnswerA

This is the core at-least-once delivery guarantee. The visibility timeout is a lease, not a lock. When the lease expires, the queue re-exposes the message. To prevent double-processing, the worker should call UpdateMessage to extend the timeout, or ensure processing is idempotent.

Why this answer

When the visibility timeout expires, the message becomes visible again in the queue because Azure Queue Storage uses a lease-based mechanism. The worker that dequeued the message loses its exclusive visibility lease, allowing another worker to dequeue and process the same message. This ensures at-least-once delivery semantics, preventing message loss if a worker fails or takes too long.

Exam trap

The trap here is that candidates assume the dequeue operation permanently locks or deletes the message, but Azure Queue Storage only hides it temporarily, and the worker must explicitly delete it to prevent reprocessing.

How to eliminate wrong answers

Option B is wrong because Azure Queue Storage does not permanently delete a message after dequeue; it only hides it for the visibility timeout period, and the message must be explicitly deleted by the worker after successful processing. Option C is wrong because messages are moved to a dead-letter queue only when they exceed the maximum dequeue count (e.g., after being dequeued but not deleted multiple times), not simply upon visibility timeout expiry. Option D is wrong because the visibility timeout applies to the entire processing window; if the worker does not update or delete the message before the timeout, the message becomes visible again, and processing can be interrupted by another worker dequeuing it.

Practice this question →

141

MCQhard

Your application uses Azure Blob Storage to store images. You need to automatically move blobs older than 30 days to the Cool tier and delete blobs older than 365 days. What should you implement?

A.Azure Automation runbook on a schedule

B.Azure Logic Apps with recurrence trigger

C.Azure Blob Storage lifecycle management policy

D.Azure Event Grid subscription with blob created event

AnswerC

Azure Blob Storage lifecycle management policies provide a native, declarative, and cost-effective way to automatically transition blobs to cooler access tiers (e.g., Hot to Cool, Cool to Archive) or delete them after a specified period. These policies are configured directly on the storage account and apply rules based on blob age, last modified time, or other conditions, eliminating the need for custom code or external services. This ensures optimal storage costs by moving less frequently accessed data to cheaper tiers.

Why this answer

Azure Blob Storage lifecycle management policies allow you to define rules that automatically transition blobs to cooler tiers (e.g., Cool) after a specified number of days and delete them after a different number of days. This is the native, cost-effective, and fully managed solution for automating tier transitions and deletions based on blob age, without requiring external compute or orchestration services.

Exam trap

The trap here is that candidates often over-engineer the solution by choosing Azure Automation or Logic Apps for scheduled tasks, not realizing that Azure Blob Storage has a built-in, serverless lifecycle management feature that directly handles age-based tiering and deletion without any external compute or orchestration.

How to eliminate wrong answers

Option A is wrong because Azure Automation runbooks require a dedicated Azure Automation account, incur additional costs, and introduce unnecessary complexity and latency for a task that is natively supported by Blob Storage lifecycle management. Option B is wrong because Azure Logic Apps with a recurrence trigger would need custom code to enumerate blobs, check their age, and perform tier changes or deletions, which is inefficient, error-prone, and not the recommended approach for storage-level automation. Option D is wrong because an Event Grid subscription with a blob created event only triggers on new blob creation, not on the passage of time, and cannot enforce age-based lifecycle rules for existing blobs.

Practice this question →

142

MCQhard

You have an Azure Storage account configured as shown in the exhibit. You need to ensure that all traffic to the storage account uses HTTPS. Which Azure CLI command should you run next?

A.az storage account create --name mystorageaccount --resource-group myResourceGroup --https-only true

B.az storage account update --name mystorageaccount --resource-group myResourceGroup --secure-transfer-required true

C.az storage account update --name mystorageaccount --resource-group myResourceGroup --enable-https-traffic-only true

D.az storage account update --name mystorageaccount --resource-group myResourceGroup --https-only true

AnswerD

This command is correct because `az storage account update` is the appropriate command to modify an existing Azure Storage account. The `--https-only true` parameter is the precise and officially recognized flag in the Azure CLI for enforcing that all requests to the storage account must use HTTPS. This action successfully disables unencrypted HTTP access, ensuring all data in transit to and from the storage account is encrypted, aligning with robust security practices.

Why this answer

The `az storage account update` command with the `--https-only true` parameter enforces HTTPS for all traffic to the storage account by setting the `supportsHttpsTrafficOnly` property to true. This is the specific Azure CLI parameter that controls this setting, and it must be applied after account creation. The command directly meets the requirement to ensure all traffic uses HTTPS.

Exam trap

The trap here is that candidates often confuse the `--https-only` parameter with `--secure-transfer-required` or `--enable-https-traffic-only`, which are not valid Azure CLI parameters for the `az storage account update` command, leading them to choose incorrect options that sound plausible but do not exist in the CLI syntax.

How to eliminate wrong answers

Option A is wrong because `az storage account create` is used to create a new storage account, not to update an existing one, and the `--https-only` parameter is not valid for the create command (the correct create parameter is `--https-only` but it's not supported; the create command uses `--enable-https-traffic-only`). Option B is wrong because `--secure-transfer-required` is not a valid parameter for `az storage account update`; this property is set via the Azure portal or ARM template but not directly via this CLI parameter. Option C is wrong because `--enable-https-traffic-only` is not a valid parameter for `az storage account update`; the correct parameter is `--https-only`.

Practice this question →

143

MCQhard

You need to upload large files (up to 100 GB) to Azure Blob Storage from a web application. The upload must be resilient to network failures and support pausing/resuming. Which approach should you use?

A.Upload the blob as a single PUT operation.

B.Use block blob with multiple blocks and parallel upload.

C.Use append blob.

D.Use AzCopy from the server.

AnswerB

Using block blobs with multiple blocks and parallel upload is the correct and recommended approach for uploading large files like 100 GB. This method involves breaking the large file into smaller, manageable blocks, which are then uploaded independently and potentially in parallel using `Put Block` operations. Once all blocks are successfully uploaded, a `Put Block List` operation commits them in the correct sequence to form the complete blob, providing robust resumability, retry capabilities, and significantly improved upload performance for very large files.

Why this answer

Block blobs support uploading large files (up to ~4.75 TB) by splitting the file into multiple blocks, uploading them in parallel for speed, and committing the block list atomically. This approach provides resilience to network failures (individual blocks can be retried) and supports pausing/resuming by tracking which blocks have been uploaded.

Exam trap

The trap here is that candidates confuse append blobs with block blobs, thinking append blobs support arbitrary uploads, but append blobs only allow data to be added to the end and cannot be used for random-access or parallel uploads.

How to eliminate wrong answers

Option A is wrong because a single PUT operation is limited to 5 GB (or 256 MB for page blobs), cannot handle 100 GB files, and provides no resilience or pause/resume capability. Option C is wrong because append blobs are designed for append-only operations (e.g., logging), not for uploading large files; they do not support parallel uploads or efficient pause/resume. Option D is wrong because AzCopy is a command-line tool meant for server-side or scripted transfers, not for direct use from a web application; it cannot be integrated into a web app's client-side upload flow.

Practice this question →

144

Multi-Selectmedium

Which TWO of the following are valid ways to authenticate to Azure Blob Storage from an application? (Choose two.)

Select 2 answers

A.Microsoft account (personal) OAuth token

B.SQL Server authentication

C.Storage account access key

D.Shared access signature (SAS) token

E.Azure Cosmos DB primary key

AnswersC, D

A storage account access key is a symmetric key that grants full administrative access to all data within the storage account. There are two such keys (key1 and key2) per account, allowing for key rotation without service interruption. When used, the key is included in the request header to sign the request, and the storage service validates this signature, granting complete control over blobs, files, queues, and tables.

Why this answer

Option C (Storage account access key) is correct because Azure Blob Storage supports authorization using the storage account's access keys, which are shared secrets that grant full access to the storage account and can be used by an application to sign requests. Option D (Shared access signature (SAS) token) is also correct because a SAS is a URI that grants restricted, time-limited access rights to Blob Storage resources, and applications can authenticate by presenting this token. Option A is not valid because personal Microsoft account OAuth tokens are not an authentication mechanism for Blob Storage data-plane access; Azure AD (work/school) identities are used instead.

Option B is incorrect because SQL Server authentication applies to Azure SQL Database, not Blob Storage. Option E is incorrect because Azure Cosmos DB primary keys authenticate to Cosmos DB, not Blob Storage.

Exam trap

The trap here is that candidates may confuse Azure AD authentication (which uses OAuth 2.0 tokens) with personal Microsoft account OAuth tokens, or mistakenly think Cosmos DB keys or SQL Server credentials can be reused across Azure services, when each service has its own distinct authentication mechanism.

Practice this question →

145

MCQmedium

An application stores large media files (up to 5 GB) that are frequently appended to but rarely read sequentially. Which Azure Blob Storage type should be used to optimize writes and cost?

A.Block blob

B.Append blob

C.Page blob

D.Archive blob

AnswerB

Append blobs are specifically engineered for scenarios that require efficient, sequential write operations, making them ideal for logging, auditing, or, in this case, frequently appended media files. Each new write operation adds data to the end of the blob in an atomic manner, ensuring data integrity without modifying existing blocks. This design provides high performance for continuous data streams and supports files up to 195 GB, easily accommodating the 5 GB requirement.

Why this answer

Append blobs are optimized for append operations, making them ideal for scenarios like logging or storing media files that are frequently appended to. They support high-throughput writes without the overhead of managing block lists, and they are cost-effective for sequential append workloads compared to block blobs, which require explicit block management and are better suited for random read/write patterns.

Exam trap

The trap here is that candidates often choose block blobs because they are the default and most familiar type for large files, overlooking that append blobs are specifically designed for frequent append operations and offer better write performance and cost efficiency for that pattern.

How to eliminate wrong answers

Option A is wrong because block blobs are designed for efficient upload of large files by splitting them into blocks, but they are not optimized for frequent append operations; each append requires managing block IDs and committing a block list, which adds overhead and is less efficient than append blobs. Option C is wrong because page blobs are optimized for random read/write operations on fixed-size pages (512 bytes), typically used for virtual machine disks (VHDs), not for append-heavy workloads with large media files. Option D is wrong because archive blob is a tier (not a blob type) for infrequently accessed data with retrieval latency of hours, and it does not support frequent append operations; it is meant for cold storage, not active writes.

Practice this question →

146

Multi-Selectmedium

You are developing an application that uses Azure Table Storage to store customer data. You need to query the table to retrieve all entities where the PartitionKey is 'Customers' and the RowKey starts with 'A'. You also want to minimize the amount of data transferred. Which two actions should you perform? (Choose two.)

Select 2 answers

A.Use a query filter that specifies both PartitionKey eq 'Customers' and RowKey ge 'A' and RowKey lt 'B'.

B.Use a continuation token to paginate through the results.

C.Retrieve all entities in the 'Customers' partition and filter on the client side.

D.Project only the properties you need by using the Select clause in the query.

E.Set the table's access tier to Cool to reduce storage costs.

AnswersA, D

Azure Table Storage supports filtering on PartitionKey and RowKey. To retrieve entities where RowKey starts with 'A', you can use a range query: RowKey ge 'A' and RowKey lt 'B'. This is efficient because it leverages the sorted index on RowKey within a partition. Combining with PartitionKey eq 'Customers' restricts the query to a single partition, which is the fastest way to query Table Storage. This approach minimizes data transfer by filtering at the service side and only returning matching entities.

Why this answer

To minimize data transfer when querying Table Storage, you should filter on both PartitionKey and RowKey using a range query for the prefix, and project only the needed properties. This reduces the number of entities returned and the size of each entity. Client-side filtering and pagination do not reduce total data transfer, and access tiers are not applicable to Table Storage.

Exam trap

The trap here is assuming that Table Storage supports access tiers like Blob Storage, or that client-side filtering is acceptable for minimizing data transfer.

Practice this question →

147

MCQmedium

You are developing a .NET 8 application that stores customer data in Azure Blob Storage. The application uses the Azure.Storage.Blobs SDK. You need to ensure that the blob containers are created only if they do not already exist. Which method should you call?

A.ExistsAsync

B.DeleteIfExistsAsync

C.CreateIfNotExistsAsync

D.CreateAsync

AnswerC

The `CreateIfNotExistsAsync` method provides an idempotent and robust mechanism for ensuring an Azure Blob Storage container is available. It intelligently first checks if a container with the specified name already exists in the storage account. If the container is not found, it then proceeds to create it. This approach prevents `RequestFailedException` errors that would occur if attempting to create an already existing container, making it ideal for reliably provisioning resources without complex conditional logic.

Why this answer

The `CreateIfNotExistsAsync` method is the correct choice because it atomically checks for the existence of the blob container and creates it only if it does not already exist, returning a Boolean indicating whether creation occurred. This aligns with the requirement to avoid errors when the container already exists, without requiring a separate existence check.

Exam trap

The trap here is that candidates often confuse `CreateIfNotExistsAsync` with `CreateAsync`, assuming that `CreateAsync` will silently succeed if the container exists, when in fact it throws an exception on conflict, leading to unhandled errors in production code.

How to eliminate wrong answers

Option A is wrong because `ExistsAsync` only checks whether the container exists and returns a Boolean; it does not create the container, so it fails to meet the creation requirement. Option B is wrong because `DeleteIfExistsAsync` deletes the container if it exists, which is the opposite of what is needed and would remove existing data. Option D is wrong because `CreateAsync` throws a `StorageRequestFailedException` (HTTP 409 Conflict) if the container already exists, requiring additional error handling to avoid failures.

Practice this question →

148

MCQmedium

You are designing a solution to ingest billions of small IoT sensor messages (each ~500 bytes). Messages arrive at high velocity and must be retained for 90 days. You need to query the data efficiently by device ID and timestamp. You want to minimize storage cost and write latency. Which Azure Storage solution should you use?

A.Azure Blob Storage with JSON logs

B.Azure Queue Storage

C.Azure Table Storage

D.Azure File Storage

AnswerC

Table Storage is optimized for storing large numbers of structured entities. Using device ID as partition key and timestamp as row key allows efficient point queries and range queries, with low write latency and cost.

Why this answer

Azure Table Storage is ideal for this scenario because it provides a cost-effective, schema-less NoSQL store that supports high-volume ingestion of billions of small messages with low write latency. Its partition key (device ID) and row key (timestamp) design enables efficient point queries by device and time range, while the 90-day retention aligns with Table Storage's lifecycle management capabilities.

Exam trap

The trap here is that candidates often choose Azure Blob Storage (Option A) because it's commonly used for log storage, but they overlook that querying billions of small blobs by device ID and timestamp is inefficient without additional indexing services like Azure Data Lake or Cosmos DB, whereas Table Storage provides native, low-latency querying via its composite key structure.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage with JSON logs incurs higher storage costs per GB compared to Table Storage, and querying billions of small JSON blobs by device ID and timestamp would require expensive full-scan operations or external indexing (e.g., Azure Data Lake), not efficient native querying. Option B is wrong because Azure Queue Storage is a message queuing service for decoupling components, not a persistent storage solution for querying historical data; messages are typically deleted after processing and cannot be efficiently queried by device ID and timestamp. Option D is wrong because Azure File Storage provides SMB file shares for shared file access, not a queryable data store; it lacks native indexing for device ID and timestamp queries and is not optimized for high-velocity ingestion of billions of small messages.

Practice this question →

149

Multi-Selectmedium

Which TWO of the following are valid use cases for Azure Queue Storage? (Choose TWO.)

Select 2 answers

A.Building a reliable messaging layer between microservices.

B.Broadcasting messages to multiple subscribers.

C.Storing large JSON documents for later retrieval.

D.Streaming high-volume telemetry data for real-time analytics.

E.Decoupling components of a distributed application for asynchronous processing.

AnswersA, E

Azure Queue Storage offers a robust, asynchronous messaging solution critical for microservice communication. Messages are durable and persist until processed and deleted, ensuring "at-least-once" delivery semantics. This reliability prevents data loss even if a consuming microservice temporarily fails or becomes unavailable, making it ideal for inter-service communication where message integrity is paramount.

Why this answer

Azure Queue Storage provides a reliable, persistent message queue that enables asynchronous communication between microservices. It guarantees at-least-once delivery and supports message visibility timeouts, making it ideal for decoupling components in a distributed architecture.

Exam trap

The trap here is that candidates confuse Azure Queue Storage with pub/sub messaging patterns (like Service Bus Topics) or assume it can handle large payloads or real-time streaming, when it is strictly a point-to-point, durable queue with size and throughput limitations.

Practice this question →

150

MCQhard

You are designing a solution that uses Azure File Shares. The application requires low-latency access to files from multiple Azure virtual machines in the same region. The files are accessed frequently and must support SMB protocol. Which storage account type and tier should you recommend?

A.Standard general-purpose v2 with cool tier.

B.Standard general-purpose v2 with transaction-optimized tier.

C.BlobStorage with hot tier.

D.FileStorage (premium file shares).

AnswerD

FileStorage accounts are specifically designed to host premium Azure file shares, which are backed by solid-state drives (SSDs). This dedicated storage account type provides consistently low latency and high performance, making it ideal for demanding enterprise workloads that require high IOPS and throughput. Premium file shares allow for provisioning a specific amount of storage, which directly correlates to guaranteed IOPS and throughput, ensuring predictable performance for critical applications.

Why this answer

Azure premium file shares (FileStorage) provide low-latency, high-performance access using the SMB protocol, which is required for frequently accessed files from multiple VMs in the same region. Standard tiers (cool or transaction-optimized) do not meet the low-latency requirement, and BlobStorage does not support SMB protocol natively.

Exam trap

The trap here is that candidates often confuse the transaction-optimized tier with performance optimization, but it only optimizes for cost per transaction, not latency, while BlobStorage is mistakenly thought to support SMB via NFS or other protocols, which it does not natively.

How to eliminate wrong answers

Option A is wrong because Standard general-purpose v2 with cool tier is designed for infrequently accessed data with higher latency, not for low-latency, frequently accessed files. Option B is wrong because Standard general-purpose v2 with transaction-optimized tier is optimized for high transaction costs, not for low-latency performance, and still uses standard HDD-based storage. Option C is wrong because BlobStorage does not support the SMB protocol; it uses REST APIs or SDKs for access, not SMB, and is not suitable for file share scenarios requiring SMB.

Practice this question →