CCNA Azure Storage Questions — Page 3 of 3

151

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 is incremented by Azure Queue Storage each time a message is successfully retrieved using the GetMessages operation. This count directly reflects the number of times a message has been made visible to a consumer, even if it's subsequently put back into the queue due to processing failure or timeout. It is the primary mechanism for identifying 'poison messages' that repeatedly fail to process, enabling robust error handling strategies like moving them to a dead-letter queue after a predefined threshold.

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 →

152

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.

AnswerA

Correct. This option includes the condition 'daysAfterLastAccessTimeGreaterThan' which tracks when the blob was last read, and also enables blob access tracking, which is required for that condition to work. This aligns with the requirement to move blobs that have not been accessed.

Why this answer

The requirement specifies 'if they have not been accessed', which requires tracking last access time. Lifecycle management rules support the 'daysAfterLastAccessTimeGreaterThan' condition, but blob access tracking must be enabled for this condition to work. Option A includes both the condition and enabling access tracking, making it the correct choice.

Option D uses 'daysAfterModificationGreaterThan', which tracks last modification time, not access time, so it does not meet the requirement.

Exam trap

The trap is that 'daysAfterModificationGreaterThan' is a common condition, but for access-based rules, you must use 'daysAfterLastAccessTimeGreaterThan' and explicitly enable blob access tracking on the storage account.

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 →

153

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 is the lowest-cost blob tier, designed for data rarely accessed with retrieval latency measured in hours. The stated few-times-per-year access and tolerance of up to 15 hours retrieval match its rehydration model exactly.

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 →

154

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

Cool tier retains millisecond access while costing less than Hot, so immediate retrieval during the first week is preserved. The lifecycle policy automatically transitions blobs after seven days, directly satisfying the requirement to minimise cost once access becomes infrequent.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automatically transition blobs to a cooler tier (Cool) after a specified number of days, minimizing storage costs while maintaining immediate access for the first week. This policy is applied at the storage account level and requires no manual intervention or scheduled jobs, ensuring that blobs remain in the Hot tier for the first 7 days (frequent access) and then move to Cool tier (lower cost, still immediate access).

Exam trap

The trap here is that candidates often confuse 'default access tier' (which applies to all new blobs immediately) with 'lifecycle management' (which applies rules after creation), leading them to incorrectly choose Option B or A, while overlooking the automated, policy-driven approach in Option D.

How to eliminate wrong answers

Option A is wrong because manually changing the blob tier using a scheduled job introduces operational overhead and potential for errors, whereas Azure provides a built-in, automated lifecycle management feature that is more reliable and cost-effective. Option B is wrong because setting the default access tier of the storage account to Cool would place all new blobs in the Cool tier immediately, violating the requirement for immediate access during the first week (Cool tier has slightly higher latency and lower throughput compared to Hot tier). Option C is wrong because storing blobs in the Archive tier requires rehydration (which can take up to 15 hours) to access them, making it unsuitable for the requirement of immediate access within the first week; Archive is intended for rarely accessed data with flexible retrieval times.

Practice this question →

155

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

Read-access geo-redundant storage (RA-GRS) asynchronously replicates your data to a secondary region hundreds of miles away, maintaining three copies in each region. Crucially, RA-GRS provides a separate read-only endpoint to the secondary region, allowing applications to directly read data from the secondary location even if the primary region becomes unavailable. This capability ensures high availability for read operations with minimal latency during a primary region outage, without requiring a manual failover.

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 →

156

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

The Azure Storage SDK, when used with Block blobs, provides the most suitable mechanism for uploading large media files with pause/resume functionality. Block blobs allow files to be broken into smaller, independently uploaded blocks, each identified by a unique block ID. The SDK enables uploading these blocks concurrently, and by tracking which blocks have been successfully committed, an application can pause an upload and later resume by only re-uploading the uncommitted or missing blocks, ensuring data integrity and efficiency.

Why this answer

Azure Blob Storage supports block blobs, which allow you to upload large files in independent blocks. By using the Azure Storage SDK, you can assign unique block IDs to each block, enabling pause/resume by tracking which block IDs have been committed. This approach also provides fine-grained progress reporting per block and efficient network bandwidth usage through parallel uploads.

Exam trap

The trap here is that candidates confuse AzCopy's resume capability with programmatic pause/resume, or assume Append blobs are suitable for large file uploads because they support chunking, but they lack the block-level control needed for concurrent uploads and progress tracking.

How to eliminate wrong answers

Option A is wrong because AzCopy is a command-line tool for bulk data transfer, not designed for programmatic pause/resume within an application; the --resume parameter works for interrupted AzCopy jobs, not for concurrent uploads with custom progress reporting. Option B is wrong because Page blobs are optimized for random read/write access (e.g., VHDs) with 512-byte pages, not for large media files requiring concurrent uploads and pause/resume; they lack block-level management. Option D is wrong because Append blobs are designed for append-only operations (e.g., logging), not for uploading large files with pause/resume; they do not support block-level parallelism or independent block IDs.

Practice this question →

157

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

Enabling Azure Storage Service Encryption (SSE) ensures that all data written to Azure Storage is automatically encrypted at rest using Microsoft-managed keys or customer-managed keys via Azure Key Vault. Coupled with Microsoft Entra ID for authentication, this provides robust identity-based access control (RBAC) to the storage account and its contents. This combination offers a secure, scalable, and fully managed solution for protecting sensitive user data.

Why this answer

Azure Storage Service Encryption (SSE) automatically encrypts data at rest for Azure Table Storage using 256-bit AES encryption. By combining SSE with Microsoft Entra ID (formerly Azure AD) for authentication, you ensure both encryption at rest and role-based access control, meeting the requirement for authorized access without managing keys or encryption logic client-side.

Exam trap

The trap here is that candidates often confuse client-side encryption (Option C) as the only way to achieve encryption at rest, overlooking that Azure Storage Service Encryption (SSE) provides automatic, transparent server-side encryption without any code changes or key management burden.

How to eliminate wrong answers

Option A is wrong because Azure Information Protection is a classification and labeling service for documents and emails, not a mechanism for encrypting Azure Storage data at rest or controlling access to storage tables. Option C is wrong because client-side encryption, while valid for encrypting data before storage, introduces key management overhead and is not the simplest or most recommended approach for at-rest encryption in Azure Table Storage; SSE handles this automatically. Option D is wrong because shared access signatures (SAS) provide delegated access to storage resources but do not encrypt data at rest; they only control access at the request level and do not enforce encryption.

Practice this question →

158

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

Azure Event Grid is a highly scalable event routing service capable of subscribing to various event sources, including Azure Blob Storage. It can detect specific events like "Microsoft.Storage.BlobCreated" and reliably deliver them to an Azure Function endpoint. This makes Event Grid an excellent choice for triggering functions in response to new blob creations, offering robust event delivery and filtering capabilities.

Why this answer

Option C (Azure Event Grid trigger) is correct because Azure Storage integrates with Event Grid to publish blob-created events (Microsoft.Storage.BlobCreated), and an Azure Function can subscribe to that event via an Event Grid trigger to react to new blobs. Option D (Azure Blob Storage trigger) is correct because it is the native Azure Functions binding that polls/uses the Blob storage extension to invoke a function when a new or updated blob is detected in a container. Option A (Azure Cosmos DB trigger) is incorrect because it responds to changes in a Cosmos DB container's change feed, not to blob creation.

Option B (Azure Queue Storage trigger) is incorrect because it fires on messages placed in a queue, not on blob creation events. Option E (Azure Service Bus trigger) is incorrect because it responds to messages on Service Bus queues or topics, which are unrelated to blob creation.

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 →

159

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 →

160

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

Lifecycle management policies are the correct solution because they automate the transition of blobs between different storage tiers (Hot, Cool, Archive) based on rules defined by age, last access time, or other criteria. This automation is crucial for optimizing storage costs for large media files, as it ensures less frequently accessed data is moved to cheaper tiers without manual intervention. By automatically moving older or less-accessed media to Cool or Archive storage, significant cost savings can be achieved.

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 →

161

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

AnswerD

Azure RBAC conditions support specifying source IP address ranges to restrict access, and the provided syntax for `ipAddress` is indeed correctly formatted. Conditions leverage attribute-based access control (ABAC) to add additional checks beyond role assignments, such as network location or specific blob index tags. The use of `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/sourceIp` with a CIDR range is a valid and common way to enforce network-based access restrictions within an RBAC assignment.

Why this answer

The current explanation is technically incorrect. Azure RBAC conditions are designed to add restrictions to role assignments and are evaluated for every request by any principal covered by that assignment, regardless of whether the assignment target is a specific user, group, or a broader scope like the tenant. Assigning a role to the tenant does not bypass conditions; the condition should still be enforced for all principals covered by that assignment.

A more plausible reason for the observed behavior (user can list blobs from any IP) would be that the condition for the IP address is incorrectly formatted (Option D), causing it to always evaluate to true or be ignored, or that another role assignment without the condition exists for the user.

Exam trap

The current exam trap note reinforces the incorrect premise that assigning a role to the tenant bypasses conditions. This is not how Azure RBAC conditions function. A more accurate trap might focus on common pitfalls like incorrect condition syntax, or the existence of other, unconditional role assignments that grant the same permissions.

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 →

162

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 uses the change feed to react to inserts and updates across partitions, satisfying the requirement to fire on both operations. It is configured declaratively through function bindings, so no leases container scripting or custom operational scripts are needed, unlike manual change feed polling.

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 →

163

Multi-Selecteasy

Which Azure Blob Storage access tier is optimized for infrequently accessed data with a minimum storage duration of 30 days?

Select 1 answer

A.Transactional

B.Archive

C.Premium

D.Cool

E.Hot

AnswersD

Cool tier targets infrequently accessed data and enforces a 30-day minimum storage duration, unlike Hot (no minimum) and Archive (180 days). It satisfies the stem's constraint by matching low-access frequency with lower storage cost while retaining immediate availability.

Why this answer

The Cool tier is optimized for infrequently accessed data and has a minimum storage duration of 30 days, matching both requirements. The Archive tier is for infrequently accessed data but requires a minimum storage duration of 180 days, so it does not meet the 30-day requirement. The Hot tier is for frequently accessed data.

The Premium tier is for high-performance, frequently accessed data. 'Transactional' is not a standard Azure Blob Storage access tier. Therefore, among the given options, only Cool satisfies all criteria.

Exam trap

Candidates often assume that Archive qualifies because it is for rarely accessed data, but they overlook the 180-day minimum storage duration required by Archive.

Practice this question →

164

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 the optimal choice for writing millions of small log records because they are specifically engineered for sequential append operations. Each log entry can be written as an individual append block, efficiently adding data to the end of the blob without modifying existing content. This design ensures high throughput, low latency, and cost-effectiveness for continuous data streams like application logs, making them ideal for this workload.

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. Data is written in append blocks. For millions of small log entries, these entries would typically be buffered and written together as larger append blocks (up to 4 MB each) to optimize performance and and stay within the append blob's 50,000 block limit.

This provides high throughput for append-heavy workloads and minimizes storage costs by storing data in a single blob.

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 →

165

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 throughput dynamically adjusts the provisioned Request Units per second (RU/s) for a Cosmos DB container or database within a user-defined minimum and maximum range. This feature is ideal for telemetry workloads with predictable peaks and troughs, as it automatically scales up during high demand to ensure performance and scales down during idle periods to optimize costs. It effectively eliminates the need for manual throughput adjustments, ensuring efficient resource utilization.

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 →

166

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

Azure Blob Storage lifecycle management rules require specific operators for defining age-based conditions. For instance, to specify a condition based on the age of a blob since its last modification, the correct operator is `daysAfterModificationGreaterThan` (or `daysAfterCreationGreaterThan`, `daysAfterLastAccessTimeGreaterThan`). Using a generic operator like `greaterThan` directly on an age property is syntactically invalid within the lifecycle rule JSON definition, leading to a rule that fails to execute as intended.

Why this answer

The lifecycle management rule uses the condition 'age > 30' which is an incorrect operator. Azure lifecycle management rules require the operator 'daysElapsedSinceModificationGreaterThan' or similar, not a generic 'age >' syntax. This invalid operator causes the rule to fail to evaluate correctly, so blobs tagged with project=temp are not moved to Archive tier.

Exam trap

The trap here is that candidates may overlook the exact operator syntax required in lifecycle management rules and assume any comparison operator like '>' is valid, when Azure requires specific predefined operators like 'daysElapsedSinceModificationGreaterThan'.

How to eliminate wrong answers

Option A is wrong because the rule does include a filter for blob index tags (project=temp), so the absence of a filter is not the issue. Option C is wrong because the Archive tier is supported on general-purpose v2 and BlobStorage accounts, and the question does not indicate an unsupported account type. Option D is wrong because block blobs can be moved to the Archive tier; only append blobs and page blobs are excluded from tiering to Archive.

Practice this question →

167

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

The Azure Storage client-side encryption library, when integrated with Azure Key Vault, provides the exact functionality required: encrypting data on the client application *before* it is uploaded to Azure Storage. This ensures that the data is encrypted in transit and remains encrypted at rest, with Azure Storage only ever receiving the ciphertext. Azure Key Vault securely stores and manages the encryption keys, allowing the client application to retrieve and use them for encryption and decryption, thereby giving customers full control over their data's encryption lifecycle and ensuring maximum confidentiality.

Why this answer

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 →

168

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

The 'r' (Read) and 'l' (List) permissions are precisely what is required for scenarios where users need to view the contents of storage resources and enumerate items within a container or directory. 'r' enables downloading blob content and accessing metadata, while 'l' allows for browsing and discovering available resources. Together, these permissions provide comprehensive read-only access without granting any modification or deletion capabilities, adhering to the principle of least privilege.

Why this answer

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 →

169

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

A system-assigned managed identity provides an automatically managed identity for the Azure App Service within Azure Active Directory. This identity can then be granted specific Azure Role-Based Access Control (RBAC) roles, such as 'Storage Queue Data Contributor', directly on the target Azure Storage Queue. This approach eliminates the need for developers to manage or store any connection strings or secrets in the application code or configuration, as Azure AD handles the authentication and authorization securely.

Why this answer

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 →

170

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

This design is optimal for IoT data. The PartitionKey, `DeviceId`, groups all temperature readings from a specific device into a single partition, enabling highly efficient point queries or range queries for that device without scanning unrelated data. Within this partition, the `RowKey`, `Timestamp`, ensures that readings are stored in chronological order, which is crucial for performing fast and cost-effective time-based range queries (e.g., retrieving all readings for a device within a specific hour or day).

Why this answer

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 →