Examkin

Question

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

An order processing system uses a C# background worker running the Azure.Storage.Blobs SDK to inspect inbound XML invoices. An external partner uploads these invoices and programmatically sets a custom metadata field with the key `ApprovalStatus` and value `Pending` to flag items for review.

The background worker retrieves the blob details using the following code segment:

csharp
BlobClient client = containerClient.GetBlobClient("invoice_992.xml");
BlobProperties properties = await client.GetPropertiesAsync();

The application must check if the `ApprovalStatus` metadata key is present. However, the evaluation logic consistently fails to detect the metadata key when querying `properties.Metadata`.

Which of the following describes the correct way to check for the presence of this metadata key in the dictionary?

  1. Query the properties.Metadata dictionary using the lowercase string "approvalstatus" as the key.Answer
  2. B
    Query the properties.Metadata dictionary using the prefix-inclusive string "x-ms-meta-approvalstatus" as the key.
  3. C
    Acquire a short-term lease on the blob using BlobLeaseClient to prevent the storage engine from converting keys to lowercase.
  4. D
    Construct a Shared Access Signature (SAS) token with write permission to bypass the metadata casing normalization.

Answer

Query the properties.Metadata dictionary using the lowercase string "approvalstatus" as the key.
Querying the properties.Metadata dictionary using the lowercase string "approvalstatus" is correct because the Azure Storage REST API returns custom metadata keys as lowercase HTTP headers. When the SDK processes these headers, it removes the prefix and creates a standard C# dictionary with the lowercase keys. Since standard C# dictionaries are case-sensitive, only the lowercase key will successfully match.

Step-by-Step Solution

1
Analyze how Azure Storage stores and transmits metadata.
Metadata is stored as name-value pairs and sent over HTTP using the x-ms-meta-name prefix. The storage service processes metadata keys in a case-insensitive manner.
This explains why the casing is modified during HTTP transmission.
2
Determine the output format of the metadata headers.
The Azure Storage REST API returns all metadata headers in lowercase (e.g., x-ms-meta-approvalstatus: Pending).
This establishes that the incoming payload headers are fully lowercased.
3
Inspect how the Azure SDK for .NET populates the Metadata property.
The SDK strips the 'x-ms-meta-' prefix and puts the key-value pair into a standard case-sensitive C# Dictionary<string, string> using the lowercase key name 'approvalstatus'.
Understanding the C# Dictionary behavior highlights why the mixed-case lookup fails.
4
Identify the correct lookup key.
The lookup must use the exact lowercase string 'approvalstatus' to match the key in the case-sensitive dictionary.
This resolves the key mismatch and ensures the condition evaluates correctly.

Key Concept

Azure Blob Storage custom metadata keys are returned as lowercase HTTP headers and are parsed by the SDK into a case-sensitive dictionary using only their lowercase names.
Estimated Time:2m 0s
Rate this question

Topics

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

More questions from this topic