Make a private storage account, move blobs between tiers and set a lifecycle rule

Steps

1. Check that your account name is free across all of Azure, then create the lab's resource group:

az storage account check-name --name az900lab0948213 --query nameAvailable -o json
az group create --name az900-lab09-rg --location eastus

The first command prints true. If it prints false, someone somewhere already has that name: choose other digits. 2. Create the storage account: standard general-purpose v2, locally redundant, hot by default, with anonymous blob access off and old TLS versions refused:

az storage account create --name az900lab0948213 --resource-group az900-lab09-rg --location eastus --sku Standard_LRS --kind StorageV2 --access-tier Hot --allow-blob-public-access false --min-tls-version TLS1_2
az storage account show --name az900lab0948213 --resource-group az900-lab09-rg --query primaryEndpoints -o json

The endpoints read https://az900lab0948213.blob.core.windows.net/, then .file., .queue., .table. and others: one name, one address per data service. Data at rest in the account is already encrypted, and that cannot be turned off. 3. Make a private container and three tiny blobs from a file you write in Cloud Shell. The --auth-mode key option has the CLI fetch the account key for you; lesson 11's capstone shows how to work without keys:

echo "lab 09 test file, no real data" > notes.txt
az storage container create --account-name az900lab0948213 --name lab09 --auth-mode key
az storage blob upload --account-name az900lab0948213 --container-name lab09 --name hot-notes.txt --file notes.txt --auth-mode key
az storage blob upload --account-name az900lab0948213 --container-name lab09 --name cool-notes.txt --file notes.txt --tier Cool --auth-mode key
az storage blob upload --account-name az900lab0948213 --container-name lab09 --name archive-me.txt --file notes.txt --auth-mode key
az storage blob set-tier --account-name az900lab0948213 --container-name lab09 --name archive-me.txt --tier Archive --auth-mode key

The container is private because a new container allows no anonymous reads, and the account forbids them anyway. 4. List the blobs with their tiers, then try to read the archived one:

az storage blob list --account-name az900lab0948213 --container-name lab09 --auth-mode key --query '[].{name:name, tier:properties.blobTier}' -o table
az storage blob download --account-name az900lab0948213 --container-name lab09 --name archive-me.txt --file /tmp/archive-me.txt --auth-mode key

The download fails with an error saying the operation is not permitted on an archived blob. Archive is offline: the blob must be rehydrated to hot, cool or cold first, which can take hours, and no role changes that. The account's own default tier stays Hot, because archive can be set only on individual blobs. 5. Add a lifecycle management policy that moves blobs under lab09/logs/ to cool after 30 days, to archive after 180, and deletes them after 365. Write the rule to a file, then apply it:

cat > policy.json << 'EOF'
{
  "rules": [
    {
      "enabled": true,
      "name": "age-out-logs",
      "type": "Lifecycle",
      "definition": {
        "filters": {"blobTypes": ["blockBlob"], "prefixMatch": ["lab09/logs/"]},
        "actions": {
          "baseBlob": {
            "tierToCool": {"daysAfterModificationGreaterThan": 30},
            "tierToArchive": {"daysAfterModificationGreaterThan": 180},
            "delete": {"daysAfterModificationGreaterThan": 365}
          }
        }
      }
    }
  ]
}
EOF
az storage account management-policy create --account-name az900lab0948213 --resource-group az900-lab09-rg --policy @policy.json

None of your three blobs is under logs/, so the policy changes nothing here. It shows the idea: tiering by age, with nobody doing it by hand. This is not Azure Policy, which governs how resources are configured. 6. Read the account's redundancy, then the region a geo-redundant copy would use, and confirm the copy tool is installed:

az storage account show --name az900lab0948213 --resource-group az900-lab09-rg --query '{sku:sku.name, primary:primaryLocation, secondary:secondaryLocation}' -o table
az account list-locations --query '[?name==`"eastus"`].metadata.pairedRegion[0].name' -o tsv
azcopy --version

Standard_LRS keeps three copies in one datacenter, so secondary is empty. With GRS or GZRS the secondary would be the paired region the second command prints, westus. AzCopy is already part of Cloud Shell; Azure Storage Explorer uses the same engine behind its mouse-driven interface. 7. Choose the service, tier, redundancy or tool for each case, then check the Notes: (a) a mapped network drive replacing an on-premises file server; (b) compliance records an auditor may ask for without warning, and that are rarely read; (c) data that must survive the loss of one availability zone and must never leave the region; (d) a nightly script that copies a folder into a container; (e) a one-time move of hundreds of terabytes over a slow link; (f) branch offices that keep a fast local cache of one Azure file share on their Windows Servers.