CCNA Azure Storage Questions — Page 3 of 3

151

MCQhard

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

A.Upload the blob as a single PUT operation.

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

C.Use append blob.

D.Use AzCopy from the server.

AnswerB

Correct. Block blobs support chunked upload with retry and resume capability.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

152

Multi-Selectmedium

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

Select 2 answers

A.Microsoft account (personal) OAuth token

B.SQL Server authentication

C.Storage account access key

D.Shared access signature (SAS) token

E.Azure Cosmos DB primary key

AnswersC, D

Access key provides full access to the storage account.

Why this answer

Option C is correct because a storage account access key provides full administrative access to the storage account, including Blob Storage. Applications can authenticate by including the key in the Authorization header using the SharedKey scheme, which HMAC-SHA256 signs the request. This is a standard, documented method for authenticating to Azure Blob Storage.

Exam trap

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

Practice this question →

153

MCQmedium

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

A.Block blob

B.Append blob

C.Page blob

D.Archive blob

AnswerB

Append blobs are specifically designed for efficient append operations and support up to 195 GB, making them suitable for frequently appended media files.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

154

MCQmedium

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

A.ExistsAsync

B.DeleteIfExistsAsync

C.CreateIfNotExistsAsync

D.CreateAsync

AnswerC

Creates only if not exists; no exception.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

155

MCQmedium

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

A.Azure Blob Storage with JSON logs

B.Azure Queue Storage

C.Azure Table Storage

D.Azure File Storage

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

156

Multi-Selectmedium

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

Select 2 answers

A.Building a reliable messaging layer between microservices.

B.Broadcasting messages to multiple subscribers.

C.Storing large JSON documents for later retrieval.

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

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

AnswersA, E

Queue storage provides reliable message delivery.

Why this answer

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

Exam trap

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

Practice this question →

157

MCQhard

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

A.Standard general-purpose v2 with cool tier.

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

C.BlobStorage with hot tier.

D.FileStorage (premium file shares).

AnswerD

FileStorage provides premium file shares with low latency and high performance.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

158

MCQeasy

You are processing messages from an Azure Storage queue in a worker role. To handle messages that repeatedly fail, you want to move them to a separate 'poison' queue after 5 delivery attempts. Which property of the received message should you check to determine the number of attempts?

A.MessageId

B.DequeueCount

C.ExpirationTime

D.PopReceipt

AnswerB

The DequeueCount property shows how many times the message has been dequeued, which is ideal for detecting poison messages.

Why this answer

The DequeueCount property tracks how many times a message has been dequeued from the queue. Each time a worker role retrieves the message but fails to process it (and does not delete it), the message becomes visible again after the visibility timeout expires, incrementing DequeueCount. By checking this property, you can implement a retry policy that moves the message to a poison queue after a threshold (e.g., 5 attempts).

Exam trap

The trap here is that candidates confuse PopReceipt (which changes with each dequeue and is used for deletion) with DequeueCount, assuming a new PopReceipt indicates a new attempt, but PopReceipt does not provide a cumulative count of attempts.

How to eliminate wrong answers

Option A is wrong because MessageId is a unique identifier for the message within the queue and does not change with retries; it cannot indicate delivery attempts. Option C is wrong because ExpirationTime defines when the message will be automatically deleted from the queue, not how many times it has been dequeued. Option D is wrong because PopReceipt is a receipt required to delete or update the message after a successful dequeue; it changes with each dequeue operation but does not track the count of attempts.

Practice this question →

159

MCQhard

You have an Azure Storage account with cool tier blobs. You need to implement lifecycle management to move blobs to the archive tier after 30 days if they have not been accessed, and delete them after 365 days. Which lifecycle management rule action should you configure?

A.Use a rule with condition 'daysAfterLastAccessTimeGreaterThan' to tier and delete, and enable blob access tracking.

B.Use a rule with condition 'daysAfterLastAccessTimeGreaterThan' to tier and delete.

C.Use a rule with condition 'daysAfterSnapshotCreationGreaterThan' to tier and delete.

D.Use a rule with condition 'daysAfterModificationGreaterThan' to tier after 30 days and delete after 365 days.

AnswerD

The default condition uses last modification time, which is suitable for this scenario.

Why this answer

Option D is correct because lifecycle management rules in Azure Storage use the 'daysAfterModificationGreaterThan' condition to trigger actions based on the last modification time of a blob. This allows you to tier blobs to archive after 30 days and delete them after 365 days, which aligns with the requirement to manage blobs based on age when access tracking is not enabled.

Exam trap

The trap here is that candidates often confuse 'daysAfterModificationGreaterThan' with 'daysAfterLastAccessTimeGreaterThan', assuming the latter is the default for access-based rules, but it requires explicit enabling of blob access tracking.

How to eliminate wrong answers

Option A is wrong because it requires enabling blob access tracking, which is an additional feature that must be explicitly enabled and incurs extra cost; the question does not specify enabling access tracking. Option B is wrong because 'daysAfterLastAccessTimeGreaterThan' also requires blob access tracking to be enabled, and without it, the condition cannot be evaluated. Option C is wrong because 'daysAfterSnapshotCreationGreaterThan' applies only to blob snapshots, not to base blobs, and the requirement is about base blobs, not snapshots.

Practice this question →

160

Matchingmedium

Match each Azure Storage access tier to its description.

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

Concepts

Matches

Optimized for frequent access, higher storage cost

Optimized for infrequent access, lower storage cost

Optimized for rarely accessed data, even lower cost

Lowest cost, offline storage for backup/compliance

Why these pairings

Azure Blob Storage offers these access tiers to optimize cost based on data usage patterns.

Practice this question →

161

MCQeasy

A company stores archival data in Azure Blob Storage. The data is accessed only a few times per year, and retrieval can take up to 15 hours. Which blob access tier minimizes storage costs while meeting these requirements?

A.Hot tier

B.Cool tier

C.Archive tier

D.Premium tier

AnswerC

Archive tier offers the lowest storage cost and supports retrieval within 1-15 hours, fitting the scenario.

Why this answer

The Archive tier is the correct choice because it is designed for data that is rarely accessed (a few times per year) and has a retrieval latency of up to 15 hours, which matches the requirement. It offers the lowest storage cost among Azure Blob Storage tiers, making it optimal for long-term archival data where infrequent access and delayed retrieval are acceptable.

Exam trap

The trap here is that candidates often confuse the Cool tier's 'infrequent access' with 'archival access,' failing to recognize that Cool tier still provides millisecond retrieval and higher storage costs, while the Archive tier alone meets the 15-hour retrieval requirement and minimizes storage costs.

How to eliminate wrong answers

Option A is wrong because the Hot tier is optimized for frequent access (multiple times per day) and has higher storage costs, making it unsuitable for archival data accessed only a few times per year. Option B is wrong because the Cool tier is intended for data accessed infrequently (about once per month) and has a retrieval latency of milliseconds, not up to 15 hours, and its storage cost is higher than the Archive tier. Option D is wrong because the Premium tier is designed for low-latency, high-performance scenarios (e.g., sub-10ms access) and has the highest storage cost, which is inappropriate for archival data with a 15-hour retrieval tolerance.

Practice this question →

162

MCQmedium

You are developing a .NET Core application that stores user profile images in Azure Blob Storage. The images are accessed frequently in the first week after upload, then rarely afterwards. You need to minimize storage costs while maintaining immediate access for the first week. What should you do?

A.Manually change the blob tier to Cool after 7 days using a scheduled job.

B.Set the default access tier of the storage account to Cool.

C.Store blobs in Archive tier and use rehydration when needed.

D.Implement a lifecycle management policy to move blobs to Cool tier 7 days after creation.

AnswerD

Automates tier transition after the frequent access period, balancing cost and performance.

Why this answer

Option B is correct because moving blobs from Hot to Cool tier after 7 days using a lifecycle management policy automatically transitions the blobs to a lower-cost storage tier for infrequently accessed data, meeting the access pattern. Option A is incorrect because changing the default access tier to Cool would increase latency during the first week. Option C is incorrect because manually changing the tier is not cost-effective or scalable.

Option D is incorrect because Archive tier has retrieval latency and is not suitable for immediate access within a week.

Practice this question →

163

MCQhard

You are designing a disaster recovery plan for a storage account containing critical data. The storage account is in the West US region. You need to ensure that if West US becomes unavailable, read access to the data is still possible with minimal latency. The data must be replicated asynchronously. Which replication strategy should you choose?

A.Read-access geo-zone-redundant storage (RA-GZRS)

B.Locally redundant storage (LRS)

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

D.Geo-redundant storage (GRS)

AnswerC

RA-GRS allows asynchronous replication and read access to the secondary region.

Why this answer

RA-GRS (Read-access geo-redundant storage) is the correct choice because it provides asynchronous replication to a secondary region (paired region) and enables read access to the secondary endpoint even if the primary region fails. This meets the requirement for minimal latency read access during a West US outage, as RA-GRS allows reading from the secondary region while data is asynchronously replicated.

Exam trap

The trap here is that candidates often confuse GRS with RA-GRS, overlooking that GRS does not provide read access to the secondary region until a failover is initiated, which fails the 'read access with minimal latency' requirement.

How to eliminate wrong answers

Option A (RA-GZRS) is wrong because it uses zone-redundant storage within the primary region, which does not provide a secondary region for failover; it only protects against zone failures, not regional outages. Option B (LRS) is wrong because it replicates data only within a single data center, offering no protection against a regional disaster like West US becoming unavailable. Option D (GRS) is wrong because while it replicates asynchronously to a secondary region, it does not enable read access to the secondary endpoint during a primary region outage; read access is only available after a failover, which introduces latency and manual intervention.

Practice this question →

164

MCQhard

You are designing a solution that stores large media files (up to 5 GB each) in Azure Blob Storage. The application must support concurrent uploads with the ability to pause and resume. You need to ensure efficient use of network bandwidth and provide progress reporting. Which approach should you use?

A.Use AzCopy with the --resume parameter.

B.Use Page blobs with 512-byte pages.

C.Use the Azure Storage SDK to upload blobs in blocks, and implement pause/resume logic using block IDs.

D.Use Append blobs and append data in chunks.

AnswerC

Block blobs support chunked upload, concurrency, and progress tracking; block IDs enable resume.

Why this answer

Option A is correct because the Azure Storage client library's block blob upload methods automatically use chunked upload with retry, and the Put Block and Put Block List operations allow manual control for pause/resume. The block blob API supports concurrent uploads and progress tracking. Option B is incorrect because Append blobs are for append operations, not for large file uploads.

Option C is incorrect because Page blobs are for random access and are not optimized for uploads. Option D is incorrect because AzCopy is a command-line tool, not suitable for an application embedding.

Practice this question →

165

MCQhard

You are developing an application that stores sensitive user data in Azure Table Storage. You need to ensure that data is encrypted at rest and that only authorized users can access it. What should you implement?

A.Apply Azure Information Protection labels to the storage account.

B.Enable Azure Storage Service Encryption (SSE) and use Microsoft Entra ID for authentication.

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

D.Use shared access signatures (SAS) with a stored access policy to limit access to the data.

AnswerB

SSE encrypts data at rest; Entra ID provides RBAC for access control.

Why this answer

Option B is correct because Azure Storage Service Encryption (SSE) is enabled by default for all storage accounts, encrypting data at rest. Additionally, using Microsoft Entra ID (formerly Azure AD) for authentication provides fine-grained access control via RBAC. Option A is wrong because client-side encryption is possible but not required; SSE already provides at-rest encryption.

Option C is wrong because shared access signatures (SAS) provide delegated access but do not enforce RBAC. Option D is wrong because Azure Information Protection is a data classification solution, not for encryption.

Practice this question →

166

Multi-Selecteasy

Which TWO Azure services can be used to trigger an Azure Function when a new blob is created in a storage account? (Choose two.)

Select 2 answers

A.Azure Cosmos DB trigger

B.Azure Queue Storage trigger

C.Azure Event Grid trigger

D.Azure Blob Storage trigger

E.Azure Service Bus trigger

AnswersC, D

Event Grid can route blob creation events to a function.

Why this answer

Option C is correct because Azure Event Grid provides a native event-driven integration that can trigger an Azure Function when a new blob is created. By subscribing to the 'Microsoft.Storage.BlobCreated' event, Event Grid delivers low-latency, reliable HTTP-based events directly to the function, making it ideal for high-throughput, serverless workflows.

Exam trap

The trap here is that candidates often assume the Blob Storage trigger is the only native option, forgetting that Event Grid is also a first-class trigger for blob creation events and is actually the recommended approach for low-latency scenarios.

Practice this question →

167

MCQhard

An e-commerce platform writes orders to a Cosmos DB container. A downstream inventory service must process every new or updated order exactly once, even if the inventory service restarts mid-batch. The solution must scale horizontally when order volume increases. What is the recommended design?

A.Use the change feed processor library with a dedicated lease container; each worker instance claims partition leases and commits checkpoints after processing each batch

B.Poll the Cosmos DB container every 30 seconds using a _ts timestamp filter to find recently modified documents

C.Subscribe to Azure Event Grid Cosmos DB events and process them in an Azure Function

D.Enable Cosmos DB analytical store and run batch queries from an Azure Synapse Spark pool every hour

AnswerA

The lease container stores the last-processed continuation token per partition. On restart, a worker reads its leases and resumes from the checkpointed position. Adding more worker instances automatically redistributes leases across instances, providing linear horizontal scaling.

Why this answer

The change feed processor library with a dedicated lease container is the recommended design because it provides exactly-once processing semantics through checkpointing, automatic partition lease management for horizontal scaling, and resilience to worker restarts by resuming from the last committed checkpoint. This pattern is purpose-built for Cosmos DB change feed consumption in distributed systems.

Exam trap

The trap here is that candidates may choose Event Grid (Option C) because it is event-driven and seems simpler, but they overlook that Event Grid does not provide exactly-once processing or checkpoint-based restart resilience for Cosmos DB change feed scenarios.

How to eliminate wrong answers

Option B is wrong because polling with _ts timestamps cannot guarantee exactly-once processing due to clock skew, missed updates within the polling interval, and lack of checkpointing for restart resilience. Option C is wrong because Azure Event Grid provides at-least-once delivery for Cosmos DB events, not exactly-once, and does not manage partition leases or checkpoints for horizontal scaling. Option D is wrong because the analytical store and Synapse Spark pool are designed for batch analytics, not real-time event processing, and cannot guarantee exactly-once per-record processing with restart resilience.

Practice this question →

168

MCQeasy

You are developing a solution that stores large media files in Azure Blob Storage. Users access these files frequently for the first 30 days, then rarely afterwards. To optimize costs, you need to automatically move blobs to a cooler tier after 30 days of creation. Which Azure feature should you use?

A.Lifecycle management policies

B.Blob inventory

C.Change feed

D.Immutable storage

AnswerA

Correct. Lifecycle management policies automate tier transitions based on age, optimizing cost.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automatically transition blobs to cooler tiers (e.g., from Hot to Cool) based on age or last modification time. By defining a rule that moves blobs to the Cool tier 30 days after creation, you optimize storage costs for frequently accessed files that become rarely used. This feature is purpose-built for automating tier transitions without manual intervention or custom code.

Exam trap

The trap here is that candidates may confuse lifecycle management with Blob inventory or Change feed, thinking that reporting or event logging alone can automate tier transitions, but only lifecycle policies provide the native, rule-based automation without additional code.

How to eliminate wrong answers

Option B (Blob inventory) is wrong because it provides a report of blobs and their metadata but does not automate tier transitions; it is used for auditing and compliance, not cost optimization. Option C (Change feed) is wrong because it records creation and modification events for blobs but requires custom processing to act on those events; it is not a built-in mechanism for automatic tiering. Option D (Immutable storage) is wrong because it enforces write-once-read-many (WORM) policies to prevent deletion or modification, not to manage storage tiers based on age.

Practice this question →

169

MCQmedium

Refer to the exhibit. You are configuring access to an Azure Storage container using Azure RBAC via a custom role definition. You want to allow a user to list blobs in a container only if the request originates from the IP range 203.0.113.0/24. However, the user reports that they can list blobs from any IP. What is the issue?

A.The Principal is set to an Azure AD tenant instead of a specific user or group

B.The Resource should be the storage account resource ID, not the container resource ID

C.The Action should be 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'

D.The Condition for IP address is incorrectly formatted

AnswerA

RBAC assignments require a specific principal (user, group, or service principal), not a tenant.

Why this answer

Option A is correct because the custom role definition's 'AssignableScopes' property must be set to a scope that includes the user or group, but the issue here is that the role assignment's 'Principal' property is set to an Azure AD tenant instead of a specific user or group. When the principal is set to the tenant, the role assignment applies to all users in the tenant, bypassing the IP condition because the condition is evaluated per principal. To enforce the IP condition, the role must be assigned to a specific user or group, not the entire tenant.

Exam trap

Microsoft often tests the misconception that the role definition's 'AssignableScopes' or the condition syntax is the issue, when in reality the problem is that the role assignment's principal is set to the entire Azure AD tenant, which bypasses any conditions because conditions are evaluated per principal.

How to eliminate wrong answers

Option B is wrong because the 'Resource' in a custom role definition for a container-level permission should be the container resource ID (e.g., /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account}/blobServices/default/containers/{container}) to scope the role to that container; using the storage account resource ID would grant permissions across all containers, which is not the intent. Option C is wrong because the action 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read' is correct for listing blobs; the issue is not with the action but with the role assignment scope or principal. Option D is wrong because the condition for IP address is correctly formatted using the '@Resource' attribute with 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs:ipAddress' in the condition expression; the problem is that the condition is not being evaluated because the role assignment is applied to the tenant, not a specific user.

Practice this question →

170

MCQeasy

You need to store small binary blobs (average 50 KB) that are accessed very frequently for a short period, then never accessed again. The total volume is high. Which storage tier is most cost-effective for the initial upload?

A.Hot

B.Cool

C.Cold

D.Archive

AnswerA

Correct. Hot tier optimizes for frequent access with lower per-operation costs.

Why this answer

The Hot tier is the most cost-effective for the initial upload because it is optimized for frequent access and low latency, and for small blobs (average 50 KB) that are accessed very frequently for a short period, the per-GB storage cost is higher than Cool or Cold, but the access cost (per-operation charges) is significantly lower. Since the blobs are never accessed again after the short period, the high access frequency during that period makes Hot the cheapest option when considering total cost (storage + access operations), as Cool/Cold tiers would incur much higher per-read operation costs that outweigh their lower storage costs.

Exam trap

The trap here is that candidates assume lower storage cost per GB (Cool/Cold) always means lower total cost, ignoring that frequent access operations and minimum duration charges can make Hot tier cheaper for short-lived, high-access workloads.

How to eliminate wrong answers

Option B (Cool) is wrong because Cool tier has a higher per-read operation cost and a minimum storage duration charge (30 days), making it more expensive for blobs that are accessed very frequently for a short period and then never accessed again. Option C (Cold) is wrong because Cold tier has even higher per-read operation costs and a 90-day minimum storage duration, which would be wasteful for blobs that are only needed briefly. Option D (Archive) is wrong because Archive tier has the highest latency (hours to rehydrate) and is designed for long-term backup, not for blobs that need immediate, frequent access; it also incurs a 180-day minimum storage duration and high retrieval costs.

Practice this question →

171

MCQmedium

A serverless app must react whenever audit documents are inserted or updated in Cosmos DB. Which trigger should the Azure Function use? The design must avoid adding custom operational scripts.

A.Queue trigger

B.Timer trigger

C.HTTP trigger

D.Cosmos DB trigger

AnswerD

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

Why this answer

The Azure Cosmos DB trigger is the correct choice because it natively listens to the Cosmos DB change feed, which captures inserts and updates to documents. This allows the Azure Function to react automatically without any custom scripts or polling logic, aligning with the serverless and operational simplicity requirements.

Exam trap

The trap here is that candidates may confuse the Cosmos DB trigger with other triggers that require custom polling or external invocation, overlooking that the change feed provides a built-in, event-driven mechanism for reacting to data changes.

How to eliminate wrong answers

Option A is wrong because a Queue trigger processes messages from Azure Queue Storage, not changes in Cosmos DB, and would require custom code to write audit events to the queue. Option B is wrong because a Timer trigger runs on a fixed schedule, not in response to data changes, and would need custom polling logic to detect inserts/updates. Option C is wrong because an HTTP trigger requires an explicit HTTP request to invoke the function, which is not triggered automatically by Cosmos DB document changes.

Practice this question →

172

Multi-Selecteasy

Which TWO Azure Blob Storage access tiers are optimized for infrequently accessed data with a minimum storage duration of 30 days?

Select 2 answers

A.Transactional

B.Archive

C.Premium

D.Cool

E.Hot

AnswersB, D

Archive tier has a 180-day minimum but is for rarely accessed data.

Why this answer

The Cool tier is optimized for data that is infrequently accessed and stored for at least 30 days, offering lower storage costs than Hot but higher access costs. The Archive tier is optimized for rarely accessed data with a minimum storage duration of 180 days, but it also supports infrequent access patterns and is often considered for long-term retention. Both Cool and Archive tiers are designed for infrequently accessed data, with Cool having a 30-day minimum and Archive a 180-day minimum, making them the correct answers for the 30-day requirement.

Exam trap

The trap here is that candidates often confuse the Archive tier's 180-day minimum with the 30-day minimum required by the question, or they incorrectly assume that Premium (which is for high-performance scenarios) is suitable for infrequently accessed data.

Practice this question →

173

MCQhard

You are designing a solution that writes millions of small log records (each 200 bytes) to Azure Blob Storage. The logs are written every second, always appended to a single file. The file must be read periodically by a batch process that reads the entire file. You need to maximize write throughput and minimize storage costs. Which blob type and access strategy should you choose?

A.Use Block blobs and append the data to a single blob

B.Use Append blobs and write each log entry as an append block

C.Use Page blobs and write each log entry to a page

D.Use Block blobs and create a new blob for each log entry

AnswerB

Append blobs are optimized for sequential appends, providing high throughput and low cost for small append operations.

Why this answer

Append blobs are optimized for append operations, making them ideal for writing millions of small log records sequentially to a single file. Each log entry is written as an append block, which provides high throughput for append-heavy workloads. Append blobs also minimize storage costs because they store data in a single blob without the overhead of managing multiple blobs or pages.

Exam trap

The trap here is that candidates often choose Block blobs (Option A) thinking they can append data by adding new blocks, but they overlook the inefficiency of the block list management and the lack of native append support, which makes Append blobs the correct choice for sequential append workloads.

How to eliminate wrong answers

Option A is wrong because Block blobs are not designed for frequent append operations; appending to a block blob requires reading the existing blocks, adding a new block, and committing the block list, which is inefficient and does not maximize write throughput. Option C is wrong because Page blobs are optimized for random read/write operations on fixed-size pages (512 bytes) and are not suitable for small, sequential appends; they also incur higher costs due to minimum page size and premium storage tiers. Option D is wrong because creating a new blob for each log entry introduces significant overhead in blob creation, metadata management, and listing operations, which reduces write throughput and increases storage costs due to per-blob transaction charges.

Practice this question →

174

MCQhard

A Cosmos DB workload for telemetry events has predictable traffic during business hours and almost no traffic overnight. The team wants to reduce cost while keeping performance during peak hours. What should be configured?

A.Analytical store only

B.Autoscale throughput with an appropriate maximum RU/s

C.Manual throughput set permanently to peak RU/s

D.Disable indexing entirely

AnswerB

Autoscale adjusts provisioned throughput within a range, reducing manual management and matching predictable peaks.

Why this answer

Autoscale throughput (option B) is correct because it dynamically scales the provisioned RU/s between 10% of the configured maximum and the maximum itself based on actual demand. For a workload with predictable peak traffic during business hours and near-zero traffic overnight, autoscale eliminates the cost of provisioning for peak capacity 24/7 while ensuring performance is not throttled during high-demand periods. This directly addresses the cost-reduction goal without sacrificing peak-hour performance.

Exam trap

The trap here is that candidates often confuse 'autoscale' with 'manual throughput' and assume manual throughput set to peak is the safest choice, but they overlook the cost of idle capacity; Microsoft often tests the understanding that autoscale is the only option that dynamically matches cost to actual usage while preserving peak performance.

How to eliminate wrong answers

Option A is wrong because Analytical Store is a separate columnar store for analytical queries (e.g., Synapse Link) and does not affect the transactional throughput cost or scaling behavior; it adds cost for storage and processing, not reduces it. Option C is wrong because setting manual throughput permanently to peak RU/s would incur charges for that capacity 24/7, even during overnight low-traffic periods, defeating the cost-reduction goal. Option D is wrong because disabling indexing entirely would severely impact query performance and is not a valid cost-saving mechanism for throughput; it affects storage costs and write latency but does not reduce provisioned RU/s charges, and it breaks many query patterns.

Practice this question →

175

MCQhard

You are reviewing a lifecycle management rule configured on an Azure Storage account. The rule is defined as shown in the exhibit. You notice that blobs tagged with project=temp are not being moved to the Archive tier as expected. What is the most likely cause?

A.The rule does not include a filter for blob index tags.

B.The condition uses an incorrect operator for age.

C.The Archive tier is not supported for this storage account type.

D.Block blobs cannot be moved to the Archive tier.

AnswerB

'greaterThan' is not valid; should use 'daysAfterModificationGreaterThan'.

Why this answer

Option C is correct. The rule uses `"greaterThan": 90` which is not a valid operator. Lifecycle management supports `daysAfterModificationGreaterThan` or `daysAfterCreationGreaterThan`.

The invalid condition causes the rule to fail. Option A is incorrect because tags are supported. Option B is incorrect because block blobs support SetBlobTier.

Option D is incorrect because Archive tier is available for block blobs.

Practice this question →

176

MCQmedium

You need to enable client-side encryption for data stored in Azure Blob Storage. The encryption keys must be managed by your organization using Azure Key Vault. What should you use?

A.Azure Disk Encryption

B.Azure Information Protection

C.Azure Storage service-side encryption with customer-managed keys

D.Azure Storage client-side encryption library with Key Vault

AnswerD

Enables client-side encryption with customer-managed keys.

Why this answer

Option D is correct because client-side encryption requires the application to encrypt data before uploading it to Azure Blob Storage, and the Azure Storage client-side encryption library integrates with Azure Key Vault to allow your organization to manage the encryption keys. This approach ensures that the storage service never has access to the plaintext data or the keys, meeting the requirement for client-side encryption with customer-managed keys.

Exam trap

The trap here is confusing client-side encryption (where the client encrypts before sending) with service-side encryption (where the service encrypts after receiving), leading candidates to incorrectly choose service-side encryption with customer-managed keys (Option C) even though it does not meet the 'client-side' requirement.

How to eliminate wrong answers

Option A is wrong because Azure Disk Encryption uses BitLocker (Windows) or DM-Crypt (Linux) to encrypt virtual machine disks at the OS and data disk level, not client-side encryption of blob data. Option B is wrong because Azure Information Protection is a classification and labeling solution for documents and emails, not a mechanism for encrypting blob storage data at the client side. Option C is wrong because Azure Storage service-side encryption with customer-managed keys encrypts data at the storage service layer after it is received, not at the client side before transmission, so the service still handles the plaintext data.

Practice this question →

177

MCQmedium

You need to implement a shared access signature (SAS) for an Azure blob container that allows a client to list blobs and read blob contents. The SAS must be valid for one hour and should not allow write or delete operations. Which permissions should you include in the SAS token?

A.r, l, and c

B.r and l

C.r, l, and d

D.r, l, and w

AnswerB

Read and list permissions are sufficient for the requirements.

Why this answer

Option B is correct because the SAS token needs 'r' (read) to allow reading blob contents and 'l' (list) to allow listing blobs in the container. These two permissions together satisfy the requirement for read-only access without write or delete capabilities.

Exam trap

The trap here is that candidates may confuse 'l' (list) with 'r' (read) or include 'c' (create) thinking it's needed for listing, but 'l' alone enables listing blobs in a container without requiring create permissions.

How to eliminate wrong answers

Option A is wrong because it includes 'c' (create), which allows creating new blobs, violating the requirement to not allow write operations. Option C is wrong because it includes 'd' (delete), which allows deleting blobs, violating the requirement to not allow delete operations. Option D is wrong because it includes 'w' (write), which allows writing blob content, violating the requirement to not allow write operations.

Practice this question →

178

MCQeasy

Your application runs on Azure App Service and needs to access Azure Queue Storage. You want to avoid storing connection strings in configuration files. Which approach should you use?

A.Hardcode the connection string in the application code.

B.Use a system-assigned managed identity with RBAC role 'Storage Queue Data Contributor' on the queue.

C.Use an environment variable in the App Service configuration.

D.Store the connection string in Azure Key Vault and retrieve it at runtime using Key Vault references.

AnswerB

Managed identity avoids storing credentials and provides secure access.

Why this answer

Option B is correct because using a system-assigned managed identity for an Azure App Service allows it to authenticate to Azure Queue Storage without any stored secrets. By assigning the 'Storage Queue Data Contributor' RBAC role, the app gains the necessary permissions to read, write, and delete queue messages, and the identity is automatically managed by Azure AD, eliminating the need for connection strings.

Exam trap

The trap here is that candidates often choose Key Vault references (Option D) thinking it's the most secure, but fail to recognize that managed identity eliminates the need for any secret at all, which is the true 'zero-trust' approach tested in AZ-204.

How to eliminate wrong answers

Option A is wrong because hardcoding a connection string in application code violates security best practices, exposes secrets in source control, and makes rotation difficult. Option C is wrong because while environment variables in App Service configuration avoid hardcoding, they still store the connection string as plaintext in the Azure portal and are not a zero-secret solution. Option D is wrong because although Key Vault references improve security by storing the connection string in a vault, they still require a connection string to be stored and retrieved, whereas managed identity eliminates the need for any secret entirely.

Practice this question →

179

MCQmedium

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

A.PartitionKey = DeviceId, RowKey = Timestamp

B.PartitionKey = Location, RowKey = DeviceId

C.PartitionKey = Temperature, RowKey = Timestamp

D.PartitionKey = DeviceId + Timestamp, RowKey = empty

AnswerA

DeviceId as PartitionKey allows direct partition access, and Timestamp as RowKey enables efficient range scanning for the time window.

Why this answer

Option A is correct because Azure Table Storage queries are most efficient when the PartitionKey and RowKey are chosen to match the query pattern. By using DeviceId as the PartitionKey, all readings for a specific device are stored in the same partition, enabling fast partition-level scans. Using Timestamp as the RowKey allows efficient range queries within a one-hour window using RowKey comparisons, which is the optimal design for time-range queries on a single device.

Exam trap

The trap here is that candidates often choose Option D, thinking that a composite PartitionKey will improve query performance, but in Azure Table Storage, a composite key in PartitionKey actually creates unique partitions per row, which prevents efficient range queries and forces point lookups, making it worse for time-range queries.

How to eliminate wrong answers

Option B is wrong because Location as PartitionKey scatters data across partitions, requiring a full table scan to filter by DeviceId and timestamp, which is inefficient. Option C is wrong because Temperature as PartitionKey is meaningless for the query; it does not group data by device, and timestamp as RowKey still requires scanning multiple partitions for a single device. Option D is wrong because concatenating DeviceId and Timestamp into PartitionKey creates a unique partition per reading, eliminating the benefit of partition-level grouping and forcing point queries instead of efficient range scans; an empty RowKey also violates the requirement that RowKey must be unique within a partition.

Practice this question →