CCNA Azure Storage Questions — Page 2 of 3

MCQmedium

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

A.Block Blob

B.Page Blob

C.Append Blob

D.Archive Blob

AnswerA

Block Blobs allow you to upload large files in blocks and replace the entire blob by committing a new block list, providing low latency and cost efficiency.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.Block blobs with a high block size.

B.Append blobs.

C.Page blobs.

D.Block blobs with a low block size.

AnswerB

Correct. Append blobs are designed for frequent append operations and are ideal for logging.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.The blob container has a soft-delete policy that is preventing uploads

B.The storage account firewall is blocking requests from the web application's IP

C.The SAS token has expired and the application is not regenerating it before it expires

D.The SAS token was generated with an incorrect IP range restriction

AnswerC

Intermittent failures are a classic symptom of an expiring SAS token. The application should refresh the token or use a stored access policy with longer validity.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.RowKey as a constant value

B.PartitionKey as a random GUID for every record

C.PartitionKey as customer ID and RowKey based on sortable timestamp

D.PartitionKey as the full JSON payload

AnswerC

This supports efficient partition filtering and range scans by time.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

You are migrating an on-premises application to Azure. The application uses a network file share (NFS) to store files. You need to minimize code changes. Which Azure storage service should you use?

A.Azure Files

B.Azure Disk Storage

C.Azure Blob Storage

D.Azure Queue Storage

AnswerA

Fully managed file share with NFS support.

Why this answer

Azure Files provides fully managed file shares in the cloud that support the Server Message Block (SMB) protocol and the Network File System (NFS) protocol. Since your on-premises application already uses an NFS share, migrating to Azure Files with NFS support allows you to mount the share directly with minimal code changes, as the application can continue to use the same file system semantics and NFS client calls.

Exam trap

The trap here is that candidates often confuse Azure Files with Azure Blob Storage, assuming both are 'file storage' in the cloud, but Blob Storage is object storage with a flat namespace and REST-based access, not a network file share that supports NFS or SMB protocols without significant code changes.

How to eliminate wrong answers

Option B (Azure Disk Storage) is wrong because it provides block-level storage volumes attached to a single virtual machine, not a network-accessible file share; migrating to disks would require refactoring the application to use a different storage interface and managing the file system yourself. Option C (Azure Blob Storage) is wrong because it is an object storage service accessed via REST APIs or SDKs, not a POSIX-compliant file system; using it would require rewriting the application to use blob APIs instead of NFS file operations. Option D (Azure Queue Storage) is wrong because it is a messaging service for asynchronous communication between application components, not a file storage solution; it cannot store or serve files over NFS.

Practice this question →

MCQeasy

You have an application that stores user profile pictures in Azure Blob Storage. Users upload images via a web app. You need to ensure that the images are served securely over HTTPS and that only authenticated users can access them. The web app uses Azure App Service with built-in authentication. You want to avoid storing any access keys in the web app's configuration. What should you do to grant the web app access to the blobs?

A.Store the storage account access key in the web app's configuration.

B.Enable system-assigned managed identity on the App Service and assign the 'Storage Blob Data Reader' role on the blob container.

C.Enable anonymous public read access on the blob container.

D.Generate a SAS token with long expiration and store it in the web app's configuration.

AnswerB

Managed identity provides secure, keyless access.

Why this answer

Option B is correct because enabling a system-assigned managed identity on the App Service allows it to authenticate to Azure Storage without storing any credentials. By assigning the 'Storage Blob Data Reader' role on the blob container, the web app can securely access blobs using Azure AD authentication, which is the recommended approach for server-side access. This avoids storing access keys or SAS tokens in configuration, meeting the security requirement.

Exam trap

The trap here is that candidates may think a SAS token or access key is necessary for programmatic access, but Azure AD authentication via managed identity is the secure, keyless method that satisfies the 'no stored keys' requirement while still enforcing authentication.

How to eliminate wrong answers

Option A is wrong because storing the storage account access key in the web app's configuration violates the requirement to avoid storing access keys, and exposes the key to potential leakage via configuration management or logs. Option C is wrong because enabling anonymous public read access would allow any user (authenticated or not) to access the blobs, which contradicts the requirement that only authenticated users can access them. Option D is wrong because generating a SAS token with long expiration and storing it in configuration still requires managing a secret in the app settings, which violates the 'avoid storing any access keys' requirement and introduces risk of token leakage or expiration issues.

Practice this question →

Multi-Selecteasy

Which TWO of the following are features of Azure Blob Storage lifecycle management? (Choose two.)

Select 2 answers

A.Automatically delete blobs after a specified number of days.

B.Automatically move blobs to a cooler tier after a specified number of days.

C.Automatically apply legal hold to blobs.

D.Automatically replicate blobs to another region.

E.Automatically encrypt blobs at rest.

AnswersA, B

Lifecycle management can delete blobs based on age.

Why this answer

Option A is correct because Azure Blob Storage lifecycle management policies allow you to define rules that automatically delete blobs after a specified number of days. This is commonly used to enforce data retention policies or clean up temporary data without manual intervention.

Exam trap

The trap here is that candidates confuse lifecycle management with other Azure Blob Storage features like immutability policies (legal hold), replication, or encryption, which are separate capabilities with different purposes and configurations.

Practice this question →

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

Distributes data across partitions, avoiding hot partitions.

Why this answer

Option B is correct because 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 SAS can be generated for the container with read and write permissions and a 24-hour expiry.

Why this answer

Option A is correct because 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

Private Endpoint uses private IP within a VNet, no internet exposure.

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 →

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

Table Storage is a NoSQL key-value store that handles massive amounts of structured data with low cost and supports fast range queries on RowKey, making it ideal for time-series telemetry.

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

After visibility timeout, message reappears for retry.

Why this answer

Option A is correct because 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

Table Storage is a NoSQL store designed for large quantities of small entities with partition key and row key, ideal for this scenario.

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

SDK provides built-in retry with exponential backoff.

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 defines the number of times a message is tried before moving to poison queue.

Why this answer

Option A is correct because 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

Data Factory is optimized for large-scale data movement and transformation.

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

Hot tier is for frequently accessed data with low latency and is the optimal initial tier for 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 steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

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 THREE are valid ways to authenticate to Azure Blob Storage from an application? (Choose three.)

Select 3 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, C, E

Access key is a shared key authentication method.

Why this answer

Option A is correct because the storage account access key provides full administrative access to the storage account, including Blob Storage. It is a simple, shared-key authentication method using HMAC-SHA256 to sign requests, and is commonly used for development or scenarios where fine-grained access control is not required.

Exam trap

The trap here is that candidates may incorrectly assume OAuth2 tokens from Microsoft Entra ID for a user are a valid standalone method, but Azure Blob Storage requires the user to be authenticated via Azure AD first, and the token is obtained as part of that flow, not as a direct authentication mechanism like a key or SAS.

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

SAS tokens allow time-limited access to specific blobs.

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 can grant limited, time-bound permissions without exposing account keys.

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

Data Box is designed for large data transfers when network is slow.

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

Co-locating readings by sensor ID allows the storage engine to scan only that partition for time-range queries. Timestamp row keys are naturally ordered, so range queries resolve efficiently without scanning unrelated partitions.

Why this answer

Option A is correct because 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

Default TTL is 7 days, but it can be set up to 7 days maximum.

Why this answer

Option B is correct because Azure Storage queue messages have a configurable time-to-live (TTL) with a maximum value of 7 days. Once the TTL expires, the message is automatically deleted from the queue. This is a hard limit enforced by the Azure Storage service, not a default setting.

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 →

100

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

Cosmos DB supports atomic operations via stored procedures.

Why this answer

Option A is correct because 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 →

101

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

SSE encrypts data at rest automatically.

Why this answer

Option C is correct because 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 →

102

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

The visibility timeout hides a received message temporarily; it reappears if not deleted before the timeout expires.

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 →

103

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 designed for large binary objects and supports geo-replication.

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 →

104

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

Shared Key is a valid authentication method.

Why this answer

Option A is correct because 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 →

105

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

Table Storage supports efficient point queries and is cost-effective for small entities.

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 →

106

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

For infrequently accessed data (30+ days).

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 →

107

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

Table Storage is a NoSQL key-value store optimized for structured data. It supports schema-less entities and fast access by partition key and row key, making it suitable for user profiles keyed by user ID.

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 →

108

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

Rehydrating the blob makes it accessible for reading.

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 →

109

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

Lifecycle management can move blobs to Cool or Archive tiers.

Why this answer

Option B is correct because Azure Blob Storage lifecycle management policies can automatically transition blobs to the Cool tier after a specified number of days. This is achieved by defining a rule with a 'tierToCool' action and a 'daysAfterModificationGreaterThan' filter, allowing cost optimization based on data access patterns.

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 →

110

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

Time-limited access without Azure account.

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 →

111

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

SDK provides automatic retry and parallel upload for block blobs, improving reliability.

Why this answer

Option B is correct because 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 →

112

Multi-Selecthard

Which TWO actions should you take to ensure data durability for a storage account using LRS? (Choose two.)

Select 2 answers

A.Enable soft delete for blobs.

B.Assign RBAC roles to users.

C.Enable blob versioning.

D.Change replication to GRS.

E.Configure network firewall rules.

AnswersA, C

Soft delete protects data from accidental deletion.

Why this answer

Enabling soft delete for blobs protects data by retaining deleted blobs for a specified retention period, allowing recovery from accidental deletion or overwrite. This directly enhances data durability within a single data center under LRS, as it provides an additional layer of protection beyond the three synchronous replicas.

Exam trap

The trap here is that candidates often confuse replication (GRS) with data protection features like soft delete and versioning, but the question explicitly asks for actions that ensure durability while keeping LRS, not changing the replication strategy.

Practice this question →

113

Drag & Dropmedium

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

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

Steps

Order

Why this order

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

Practice this question →

114

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 Blob is optimized for append operations and can handle high write throughput for sequential logs. It supports atomic appends and has a simple programming model.

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 →

115

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

CDN caches content at edge nodes, providing fast access worldwide.

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 →

116

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

Hierarchical partitioning allows query engines to skip irrelevant data.

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 →

117

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

Idempotent logic prevents duplicate side effects when events are retried or delivered more than once.

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 →

118

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

Cloud tiering automatically manages local caching based on access frequency.

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 →

119

Multi-Selecthard

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

Select 3 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, C, D

Replicates within one datacenter.

Why this answer

Locally redundant storage (LRS) replicates data three times within a single physical location in the primary region, protecting against server rack and drive failures. This provides high availability within a single datacenter, making it the most cost-effective option for scenarios where durability within one facility is sufficient.

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 →

120

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

Option C is correct because 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 →

121

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

Staging blocks supports resumable, parallel uploads for large block blobs.

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 →

122

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 provides fully managed SMB and NFS file shares that can be accessed by multiple VMs concurrently. It supports Microsoft Entra ID-based authentication and authorization, making it ideal for shared file access.

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 →

123

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 →

124

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

Allows quick retry if processing fails.

Why this answer

Option A is correct because 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 →

125

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 SDK's UploadAsync method handles block-level parallelism and retries, providing resilience and throughput.

Why this answer

Option A is correct because 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 →

126

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 correctly creates a BlobSasBuilder with permissions 'rl' (read and list) and an expiry of 1 hour. The GenerateSasUri method returns the URI with the SAS token.

Why this answer

Option A is correct because 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 →

127

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

CDN caches content at edge locations and supports HTTPS.

Why this answer

Option B is correct because 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 →

128

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 good partition key spreads storage and throughput across logical partitions.

Why this answer

Option C is correct because 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 →

129

Multi-Selectmedium

You are designing a solution to store large amounts of log data that will be queried infrequently but must be retained for regulatory purposes for 7 years. The logs are append-only and do not need to be modified. You need to choose a cost-effective storage option. Which three Azure capabilities should you consider? (Choose three.)

Select 3 answers

A.Azure Blob Storage soft delete

B.Azure Blob Storage lifecycle management policy

C.Azure Blob Storage with Cool access tier

D.Azure Table Storage

E.Azure Blob Storage immutability policy

AnswersB, C, E

Lifecycle management can move data to Archive tier after a period to further reduce costs.

Why this answer

Azure Blob Storage with Cool or Archive access tier is cost-effective for infrequent access. Lifecycle management can automate tier transitions. Immutability policies ensure logs cannot be modified, meeting regulatory requirements.

Soft delete is for accidental deletion, not immutability.

Practice this question →

130

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

Base storage for archiving data.

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 →

131

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

GRS replicates to a secondary region.

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 →

132

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.

AnswerB

Correct. Cool tier is sufficient for weekly access in the first year, and then Archive provides the lowest cost for the remaining 6 years when access is rare. Lifecycle management can automate the transition.

Why this answer

Option B is correct because it minimizes costs by storing files in the Cool tier from the start (matching the initial weekly access pattern) and then moving them to the Archive tier after one year when access drops to monthly. The Cool tier offers lower storage cost than Hot for infrequent access, and the Archive tier provides the lowest storage cost for data that is rarely accessed and can tolerate a retrieval latency of up to 15 hours. This lifecycle policy aligns with the 7-year retention requirement without incurring unnecessary early deletion charges or rehydration costs.

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 →

133

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

Provides built-in monitoring and diagnostics for File Sync.

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 →

134

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

Client-side encryption encrypts data before transmission.

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 →

135

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

Delegated, time-limited access.

Why this answer

A Shared Access Signature (SAS) token provides delegated, time-limited access to specific Azure Blob Storage resources without exposing the storage account key. It allows you to grant granular permissions (read, write, delete) and enforce constraints like IP restrictions and allowed protocols (HTTPS only). This is a secure, recommended approach for sharing access with clients or third parties.

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 →

136

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

Correct. Block blobs support high-volume storage with low-cost tiers (Cool/Archive) and can handle billions of objects.

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 →

137

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

Point reads using id plus partition key are more efficient than SQL queries for single-item lookup.

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 →

138

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

Private endpoint provides a private IP in the VNet, ensuring traffic stays within the network.

Why this answer

Option D is correct because 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 →

139

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

Built on Blob Storage, supports hierarchical namespace for large datasets.

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 →

140

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

Blob Storage with CDN provides global low-latency access for large files.

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 →

141

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 provides global distribution, low-latency reads, and automatic failover.

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 →

142

Multi-Selecteasy

Which TWO of the following are valid methods for authenticating to Azure Blob Storage?

Select 2 answers

A.Connection string with account key

B.Shared access signature (SAS) token

C.Shared Key (storage account key)

D.Azure AD authentication (RBAC)

E.Client certificate authentication

AnswersC, D

Shared Key is a valid authentication method.

Why this answer

Option C is correct because the Shared Key (storage account key) method uses the HMAC-SHA256 algorithm to sign a request string with the storage account key, providing full administrative access to the storage account. Option D is correct because Azure AD authentication with RBAC allows fine-grained access control to blob containers and blobs without exposing account keys, using OAuth 2.0 tokens.

Exam trap

The trap here is that candidates often mistake a connection string (Option A) as a distinct authentication method, when it is simply a string that contains the account key and endpoint, making it equivalent to Shared Key authentication, not a separate valid method.

Practice this question →

143

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 the configured retention period.

Why this answer

Blob soft delete protects against accidental deletion by retaining deleted blobs for a specified retention period. Enabling it with a 14-day retention period 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 →

144

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

SAS provides time-limited access without authentication.

Why this answer

Option D is correct because 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 →

145

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

Block blobs allow resumable uploads with Put Block.

Why this answer

Option D is correct because 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 →

146

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

User delegation SAS uses Entra ID, no key exposure.

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 →

147

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 →

148

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

Lifecycle management can tier and delete blobs based on age.

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 →

149

MCQhard

You need to store billions of small log entries (each ~200 bytes) generated from multiple IoT devices. The logs are written in chronological order and are rarely updated. You need to run queries that scan large ranges of data by timestamp each day. You want to maximize write throughput and minimize storage costs. Which Azure Storage solution should you choose?

A.Azure Cosmos DB SQL API with a collection partitioned by timestamp.

B.Azure Blob Storage with append blobs and a custom index for timestamp queries.

C.Azure Table Storage with a partition key combining device ID and date, and row key as timestamp.

D.Azure SQL Database with a clustered columnstore index.

AnswerC

Correct. Table Storage provides high throughput at low cost. By designing the partition key appropriately, you can achieve efficient range queries on timestamps and handle billions of entries.

Why this answer

Azure Table Storage is ideal for this scenario because it supports high-volume, low-cost storage of structured log data with efficient range queries. By using a partition key of device ID combined with date, you distribute writes across partitions for high throughput, while the row key as timestamp enables fast, server-side range scans over chronological data without the overhead of a separate index.

Exam trap

The trap here is that candidates often choose Cosmos DB for its indexing and query capabilities, overlooking the fact that Table Storage provides native, cost-effective range queries on the row key without additional indexing costs, making it the optimal choice for high-volume, low-cost log storage with timestamp-based scans.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB SQL API is optimized for globally distributed, low-latency reads and writes with flexible schemas, but it incurs higher storage costs and RU consumption for billions of small log entries, making it less cost-effective than Table Storage for this write-heavy, rarely-updated workload. Option B is wrong because append blobs are designed for sequential writes and cannot be efficiently queried by timestamp without a custom external index; scanning billions of blobs or parsing blob content for timestamp ranges would be extremely slow and complex, defeating the query requirement. Option D is wrong because Azure SQL Database with a clustered columnstore index is optimized for analytical queries on large datasets, but it is over-provisioned and expensive for simple log storage, and its transactional overhead and cost per GB make it unsuitable for high-throughput, low-cost ingestion of billions of small entries.

Practice this question →

150

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 sets HTTPS-only traffic correctly.

Why this answer

Option D is correct because 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 →