Examkin

Question

Difficulty: HardManage Properties, Metadata, and Access Tiers for Azure Blob Storage

A developer is writing a .NET background worker using the `Azure.Storage.Blobs` SDK (version 12) to process medical images. During the image upload process, a custom metadata key named `PatientID` was successfully set on each blob. The developer writes the following C# code to retrieve this metadata value:

csharp
BlobClient blobClient = blobContainerClient.GetBlobClient("image1.jpg");
BlobProperties properties = await blobClient.GetPropertiesAsync();
string patientId = properties.Metadata["PatientID"];

At runtime, this code throws a `KeyNotFoundException` when attempting to read the dictionary value, even though the metadata exists on the blob.

Which of the following describes the root cause of this exception and the correct resolution?

  1. A
    The SDK does not strip the REST API metadata prefix when populating the dictionary; the developer must access the key using `properties.Metadata["x-ms-meta-patientid"]`.
  2. B
    Reading metadata requires acquiring a lease on the blob to prevent concurrent modifications; the developer must acquire a lease and pass the lease ID to the request conditions.
  3. The Azure Blob Storage service returns all user-defined metadata keys in lowercase via HTTP headers, which causes the SDK to populate the dictionary with lowercase keys; the developer should access the key using `properties.Metadata["patientid"]`.Answer
  4. D
    Accessing custom metadata requires a Shared Access Signature (SAS) token configured with the Manage permission scope; the developer must generate a new SAS token with this scope.

Answer

The Azure Blob Storage service returns all user-defined metadata keys in lowercase via HTTP headers, which causes the SDK to populate the dictionary with lowercase keys; the developer should access the key using properties.Metadata["patientid"].
The correct option is correct because the Azure Blob Storage REST API returns custom metadata keys as lowercase HTTP headers. The .NET SDK parses these headers, removes the prefix, and exposes them in the Metadata dictionary exactly as received (lowercase). Consequently, a case-sensitive dictionary lookup using mixed-case keys throws a KeyNotFoundException. The developer must use lowercase keys for retrieval.

Step-by-Step Solution

1
Analyze how custom metadata is transferred from Azure Storage to the client application.
Metadata is sent via HTTP response headers prefixed with 'x-ms-meta-', such as 'x-ms-meta-patientid'.
HTTP headers are case-insensitive, and Azure Blob Storage normalizes header names to lowercase during transmission.
2
Determine how the .NET SDK (Azure.Storage.Blobs) processes these HTTP headers.
The SDK strips the 'x-ms-meta-' prefix and populates the Metadata dictionary using the lowercase keys directly from the header names.
This behavior maps the HTTP header keys to dictionary keys, preserving the casing returned by the service.
3
Identify the correct key to retrieve the metadata value from the dictionary.
The correct key is 'patientid' in all lowercase, rather than the original mixed-case 'PatientID'.
Using 'PatientID' causes a KeyNotFoundException because C# dictionary lookups are case-sensitive by default.

Key Concept

Azure Blob Storage custom metadata keys are returned in lowercase by the REST API, resulting in lowercase keys in the .NET SDK Metadata dictionary.
Rate this question

Topics

Manage Properties, Metadata, and Access Tiers for Azure Blob Storage

More questions from this topic