Develop for Azure storage →hardMultiple ChoiceObjective-mapped

AZ-204 Develop for Azure storage Practice Question

Exhibit

Refer to the exhibit.
{
  "then": {
    "action": {
      "type": "SetBlobTier",
      "tier": "Archive"
    }
  },
  "if": {
    "condition": "and",
    "allOf": [
      {
        "field": "blobType",
        "equals": "BlockBlob"
      },
      {
        "field": "lastModified",
        "greaterThan": 90
      },
      {
        "field": "tags",
        "equals": "{\"project\":\"temp\"}"
      }
    ]
  }
}

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?

⚠ Common 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'.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The condition uses an incorrect operator for age.

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.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The rule does not include a filter for blob index tags.
Why it's wrong here
Azure Blob Storage lifecycle management rules support filtering based on blob index tags, allowing granular control over which blobs are targeted for actions like tiering or deletion. If the rule in question was configured with a `blobIndexMatch` condition, specifying a tag name and value, then the assertion that it "does not include a filter for blob index tags" would be factually incorrect. This powerful feature enables dynamic management of data based on custom metadata.
✓
The condition uses an incorrect operator for age.
Why this is correct
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.
✗
The Archive tier is not supported for this storage account type.
Why it's wrong here
The Azure Blob Storage Archive tier is specifically designed for infrequently accessed data and is fully supported by General-Purpose v2 (GPv2) and Blob Storage accounts. These account types offer the full range of hot, cool, and archive tiers, allowing for cost-effective data lifecycle management. Therefore, stating that the Archive tier is not supported for a typical storage account type used with lifecycle management rules is incorrect, as most modern deployments leverage GPv2.
✗
Block blobs cannot be moved to the Archive tier.
Why it's wrong here
Azure Blob Storage lifecycle management rules are specifically designed to manage block blobs, which constitute the vast majority of objects stored in Azure Blob Storage. Block blobs, along with append blobs, are fully supported for tiering operations, including transitioning to the Archive tier. This capability is fundamental to optimizing storage costs for large datasets that become less frequently accessed over time, making the assertion that they cannot be moved incorrect.

Quick reference

Azure Blob Storage Tier Comparison

Tier	Storage Cost	Retrieval Cost	Latency	Use Case
Hot	Highest	Lowest	Immediate	Active data, frequent reads
Cool	Lower	Higher	Immediate	Data accessed < once / month
Cold	Lower still	Higher	Immediate	Data accessed < once / quarter
Archive	Lowest	Highest + rehydration delay	Hours	Long-term compliance retention

Go deeper

AZ-204 Develop for Azure storage Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Azure Blob Storage Tier Comparison

Related to this question