Skip to main content

Technical Lab: Configure blob lifecycle management

Questions​

Question 1 — Multiple Choice​

A data team stores log files in Azure Blob Storage with the Hot access tier. Logs older than 30 days are rarely accessed but need to be retained for 1 year due to regulatory requirements. After 1 year, they should be automatically deleted.

Which set of actions in a lifecycle policy meets this requirement with the lowest possible cost?

A) Move to Cool after 30 days, move to Archive after 365 days, delete after 395 days.

B) Move to Cool after 30 days, delete after 365 days.

C) Move to Archive after 30 days, delete after 365 days.

D) Move to Cold after 30 days, move to Archive after 180 days, delete after 365 days.

Question 2 — Technical Scenario​

An administrator configured the following lifecycle policy:

{
  "rules": [
    {
      "name": "moverParaArchive",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/2023"]
        },
        "actions": {
          "baseBlob": {
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}

After 95 days, the administrator verifies that the blobs in logs/2023/ have not been moved to Archive. What is the most likely cause?

A) The daysAfterModificationGreaterThan property is not supported for the Archive tier; the correct one would be daysAfterCreationGreaterThan.

B) The storage account is configured with GRS replication, which blocks automatic tier movement.

C) The blobs in question are of type appendBlob, not blockBlob, and the rule doesn't apply to this type.

D) The lifecycle policy is only evaluated once per week, and the 95-day period has not been processed yet.

Question 3 — Multiple Choice​

When defining lifecycle rules, the administrator needs to choose the correct time condition for each scenario. Consider the four available conditions:

ConditionCalculation basis
daysAfterModificationGreaterThanLast modification of the blob
daysAfterCreationGreaterThanCreation date of the blob
daysAfterLastAccessTimeGreaterThanLast registered access
daysAfterLastTierChangeGreaterThanLast tier change

A pipeline deposits files that are never modified after creation. The goal is to delete files that haven't been accessed in the last 60 days. Which condition is most appropriate?

A) daysAfterModificationGreaterThan, because files are never modified and the date remains stable.

B) daysAfterCreationGreaterThan, because it reflects the real lifetime of the file in storage.

C) daysAfterLastAccessTimeGreaterThan, because it directly captures the absence of recent access.

D) daysAfterLastTierChangeGreaterThan, because all files go through an initial tier when created.

Question 4 — Technical Scenario​

An organization uses blob versioning enabled on their storage account. The team notices costs are high due to accumulation of old versions. The administrator wants previous versions to be moved to the Cool tier after 14 days and deleted after 90 days.

Which of the configurations below correctly meets this objective?

A)

"actions": {
  "baseBlob": {
    "tierToCool": { "daysAfterModificationGreaterThan": 14 },
    "delete": { "daysAfterModificationGreaterThan": 90 }
  }
}

B)

"actions": {
  "version": {
    "tierToCool": { "daysAfterCreationGreaterThan": 14 },
    "delete": { "daysAfterCreationGreaterThan": 90 }
  }
}

C)

"actions": {
  "snapshot": {
    "tierToCool": { "daysAfterCreationGreaterThan": 14 },
    "delete": { "daysAfterCreationGreaterThan": 90 }
  }
}

D)

"actions": {
  "baseBlob": {
    "tierToCool": { "daysAfterCreationGreaterThan": 14 }
  },
  "version": {
    "delete": { "daysAfterCreationGreaterThan": 90 }
  }
}

Question 5 — True or False​

Statement: A lifecycle policy that contains a tierToArchive action can be applied to a General Purpose v1 (GPv1) storage account, as long as the blob is of type blockBlob.

True or False?

Answer Key and Explanations​

Answer Key — Question 1​

Answer: A

Alternative A is the only one that meets all requirements: reduces cost by moving to Cool after 30 days (rare access), further minimizes cost by archiving after 365 days and then deletes after 395 days (1 year + 30 days of Cool + Archive). The Archive tier requires a minimum storage period of 180 days; deleting before this incurs an early deletion penalty.

The main error in the distractors is ignoring the 1-year regulatory retention: alternative B deletes at the 365-day mark without going through Archive; alternative C archives too early and deletes before completing 1 year in the correct tier. Alternative D uses Cold, which has a 90-day minimum requirement, and archives at 180 days, deletes at 365, not achieving 1 full year of retention.

Answer Key — Question 2​

Answer: C

The filter blobTypes: ["blockBlob"] restricts the rule exclusively to blobs of type blockBlob. If the log files were generated by a service that uses appendBlob (like diagnostics or streaming pipelines), the rule simply doesn't apply to them, and the blobs remain untouched.

The other distractors represent common misconceptions: daysAfterModificationGreaterThan is indeed supported for Archive (A is wrong); GRS replication doesn't block lifecycle policies (B is wrong); the policy is executed once per day, not weekly (D is wrong and is a frequent misconception about evaluation frequency).

Answer Key — Question 3​

Answer: C

The condition daysAfterLastAccessTimeGreaterThan is the only one that directly measures absence of access, which is exactly the business criterion described. For this condition to work, last access tracking must be enabled on the storage account.

Alternative A seems reasonable because the modification date is stable, but it doesn't reflect access; a file can be accessed repeatedly without ever being modified. Alternative B is based on creation, completely ignoring the access pattern. Alternative D is technically incoherent: tier changes have no relation to user access.

Answer Key — Question 4​

Answer: B

When blob versioning is enabled, previous versions are distinct objects from the current blob. To manage them, the policy must use the version object within actions, not baseBlob. The correct condition for versions is daysAfterCreationGreaterThan, which counts from the moment that version was created.

Alternative A applies actions to baseBlob (current blob), not to old versions. Alternative C uses snapshot, which is a different manual versioning mechanism. Alternative D is partially correct but divides actions incompletely: moves to Cool via baseBlob (wrong) and deletes via version (correct), which would result in versions being deleted without ever having been moved to Cool.

Answer Key — Question 5​

Answer: False

Blob Storage lifecycle management, including the tierToArchive action, is not supported on General Purpose v1 (GPv1) accounts. This feature is only available on General Purpose v2 (GPv2) accounts and dedicated Blob Storage accounts. Migrating a GPv1 account to GPv2 is a prerequisite for using lifecycle policies with tier movement. The blob type (blockBlob) is a necessary condition, but not sufficient; the storage account type is the determining constraint here.