Lab 01: Blob Lifecycle Management¶

Build a StorageV2 account, upload sample blobs into lifecycle-targeted prefixes, apply a management policy, and validate tier movement expectations.

Prerequisites¶

• Azure subscription with permission to create storage, networking, and monitoring resources.
• Azure CLI logged in with the correct tenant and subscription.
• Variables defined for $RG, $LOCATION, $STORAGE_NAME, and any lab-specific names.
• A workstation or Cloud Shell session with access to the resource group.
• Optional Log Analytics workspace if you want to capture diagnostics during the lab.

Architecture Diagram¶

mermaid flowchart TD A[Operator workstation] --> B[Azure CLI] B --> C[Resource group] C --> D[Storage account] D --> E[Data path under test] D --> F[Lifecycle, networking, or replication control] D --> G[Validation and cleanup]

Step-by-Step Instructions¶

Step 1: Create the resource group and storage account¶

az group create \
    --name $RG \
    --location $LOCATION \
    --output json

az storage account create \
    --resource-group $RG \
    --name $STORAGE_NAME \
    --location $LOCATION \
    --sku Standard_LRS \
    --kind StorageV2 \
    --access-tier Hot \
    --allow-blob-public-access false \
    --output json

After this step, confirm the returned allowBlobPublicAccess is false and record the storage account id — later steps reference this account by name.

Step 2: Create the container and upload sample data¶

az storage container create \
    --account-name $STORAGE_NAME \
    --name $CONTAINER_NAME \
    --auth-mode login \
    --output json

mkdir -p lab-data/lifecycle/logs lab-data/lifecycle/archive
cat > lab-data/lifecycle/logs/example-001.json <<'EOF'
{"dataset":"logs","retention":"hot","message":"blob used for lifecycle validation"}
EOF
cat > lab-data/lifecycle/archive/example-365.json <<'EOF'
{"dataset":"archive","retention":"long-term","message":"blob used for archive-tier policy review"}
EOF

az storage blob upload-batch \
    --account-name $STORAGE_NAME \
    --destination $CONTAINER_NAME \
    --source ./lab-data/lifecycle \
    --pattern "*.json" \
    --output table

After this step, verify both sample blobs (logs/example-001.json and archive/example-365.json) appear in the upload-batch output before you attach any lifecycle policy.

Step 3: Apply a lifecycle policy¶

cat > lifecycle-policy.json <<'EOF'
{
  "rules": [
    {
      "enabled": true,
      "name": "move-logs-through-tiers",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}
EOF

az storage account management-policy create \
    --resource-group $RG \
    --account-name $STORAGE_NAME \
    --policy @lifecycle-policy.json \
    --output json

After this step, confirm the returned policy contains the move-logs-through-tiers rule with the 30-day cool, 180-day archive, and 365-day delete transitions you defined.

Step 4: Inspect sample blobs¶

az storage blob show \
    --account-name $STORAGE_NAME \
    --container-name $CONTAINER_NAME \
    --name logs/example-001.json \
    --auth-mode login \
    --output json

Note the blob's current accessTier: freshly uploaded blobs start in Hot, so the lifecycle transitions above will not yet be reflected here — that is expected on day zero.

Validation Steps¶

1. Confirm the storage account properties match the intended SKU, kind, and access posture.
2. Validate the lab-specific feature from the consumer point of view rather than trusting only control-plane success.
3. Capture one or more JSON outputs that prove the configuration is active.
4. Record any timing behavior that matters, especially for lifecycle or replication scenarios.
5. Note the operational follow-up required before using the same pattern in production.

Example validation commands¶

az storage account show \
    --resource-group $RG \
    --name $STORAGE_NAME \
    --output json

az monitor diagnostic-settings list \
    --resource $(az storage account show --resource-group $RG --name $STORAGE_NAME --query id --output tsv) \
    --output json

Cleanup Instructions¶

• Delete lab resources when validation is complete to prevent ongoing cost.
• Preserve any JSON output or screenshots you need before deletion.
• If you created role assignments or network links used elsewhere, confirm scope before removing them.

az group delete \
    --name $RG \
    --yes \
    --no-wait

See Also¶

• Lifecycle Management Best Practices
• Manage Lifecycle Policies
• Lifecycle Policy Not Working

Sources¶

• azure/storage/blobs/lifecycle-management-overview
• azure/storage/blobs/storage-lifecycle-management-concepts