Bird
Raised Fist0
Azurecloud~5 mins

Storage tier optimization in Azure - Commands & Configuration

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
Storage tier optimization helps you save money by moving your data to different storage types based on how often you use it. It automatically moves data to cheaper storage when you don't need it often and brings it back when you do.
When you have files that are rarely accessed but must be kept for a long time, like backups or archives.
When you want to reduce storage costs by moving old data to cheaper storage automatically.
When you want to keep frequently used data quickly accessible while saving money on less used data.
When you want to manage storage costs without manually moving files between storage types.
When you want to set rules that automatically move data between hot, cool, and archive storage tiers.
Config File - storage-lifecycle-policy.json
storage-lifecycle-policy.json
{
  "rules": [
    {
      "name": "move-to-cool-after-30-days",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            }
          }
        }
      }
    },
    {
      "name": "move-to-archive-after-90-days",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"]
        },
        "actions": {
          "baseBlob": {
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}

This JSON file defines lifecycle rules for Azure Blob Storage.

  • rules: A list of rules to manage data movement.
  • move-to-cool-after-30-days: Moves blobs to the cool tier if they haven't changed for 30 days.
  • move-to-archive-after-90-days: Moves blobs to the archive tier if they haven't changed for 90 days.
  • filters: Applies only to block blobs.
  • actions: Defines the tier change actions based on days since last modification.
Commands
This command applies the lifecycle policy to the storage account named 'mystorageaccount' in the resource group 'myresourcegroup'. It tells Azure to start moving blobs between tiers based on the rules in the JSON file.
Terminal
az storage account management-policy create --account-name mystorageaccount --resource-group myresourcegroup --policy @storage-lifecycle-policy.json
Expected OutputExpected
{ "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myresourcegroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount/managementPolicies/default", "name": "default", "type": "Microsoft.Storage/storageAccounts/managementPolicies", "policy": { "rules": [ { "name": "move-to-cool-after-30-days", "enabled": true, "type": "Lifecycle", "definition": { "filters": { "blobTypes": ["blockBlob"] }, "actions": { "baseBlob": { "tierToCool": { "daysAfterModificationGreaterThan": 30 } } } } }, { "name": "move-to-archive-after-90-days", "enabled": true, "type": "Lifecycle", "definition": { "filters": { "blobTypes": ["blockBlob"] }, "actions": { "baseBlob": { "tierToArchive": { "daysAfterModificationGreaterThan": 90 } } } } } ] } }
→
--account-name - Specifies the storage account to apply the policy
→
--resource-group - Specifies the resource group of the storage account
→
--policy - Points to the lifecycle policy JSON file
This command shows the current lifecycle management policy applied to the storage account. It helps verify that the policy was set correctly.
Terminal
az storage account management-policy show --account-name mystorageaccount --resource-group myresourcegroup
Expected OutputExpected
{ "policy": { "rules": [ { "name": "move-to-cool-after-30-days", "enabled": true, "type": "Lifecycle", "definition": { "filters": { "blobTypes": ["blockBlob"] }, "actions": { "baseBlob": { "tierToCool": { "daysAfterModificationGreaterThan": 30 } } } } }, { "name": "move-to-archive-after-90-days", "enabled": true, "type": "Lifecycle", "definition": { "filters": { "blobTypes": ["blockBlob"] }, "actions": { "baseBlob": { "tierToArchive": { "daysAfterModificationGreaterThan": 90 } } } } } ] } }
→
--account-name - Specifies the storage account to check
→
--resource-group - Specifies the resource group of the storage account
Key Concept

If you remember nothing else from this pattern, remember: lifecycle policies automatically move data to cheaper storage tiers based on how long data is unused, saving money without manual effort.

Common Mistakes
Not enabling the lifecycle rules in the policy JSON.
If rules are not enabled, Azure will ignore them and no data movement happens.
Always set "enabled": true for each rule you want active.
Applying the policy to the wrong storage account or resource group.
The policy won't apply if the account or group names are incorrect, causing confusion and no cost savings.
Double-check the storage account and resource group names before running the command.
Using incorrect blob types in filters, like missing 'blockBlob'.
The rules won't apply to the blobs you want to manage, so data stays in the expensive tier.
Specify the correct blob types in the filters section, usually "blockBlob" for most blobs.
Summary
Create a lifecycle policy JSON file defining rules to move blobs to cool and archive tiers after set days.
Apply the lifecycle policy to your Azure storage account using the Azure CLI.
Verify the policy is active by showing the current management policy on the storage account.

Practice

(1/5)
1. Which Azure Storage tier is best for data that you access very often?
easy
A. Archive tier
B. Cool tier
C. Hot tier
D. Premium tier

Solution

  1. Step 1: Understand storage tiers purpose

    The Hot tier is designed for data accessed frequently, providing low latency and high throughput.

  2. Step 2: Match access frequency to tier

    Since the question asks for very often access, Hot tier fits best compared to Cool (infrequent) or Archive (rare).

  3. Final Answer:

    Hot tier -> Option C

  4. Quick Check:

    Frequent access = Hot tier [OK]
Hint: Hot tier = frequent access, Cool = less, Archive = rare [OK]
Common Mistakes:
  • Confusing Cool tier as best for frequent access
  • Choosing Archive tier for active data
  • Thinking Premium tier is a storage tier
2. Which Azure CLI command correctly changes a blob's tier to Cool?
easy
A. az storage blob update-tier --tier Cool --container mycontainer --blob myblob --account mystorage
B. az storage blob set-tier --tier Cool --container-name mycontainer --name myblob --account-name mystorage
C. az storage blob change-tier --tier Cool --container mycontainer --name myblob --account mystorage
D. az storage blob tier-set --tier Cool --container mycontainer --name myblob --account mystorage

Solution

  1. Step 1: Recall correct Azure CLI syntax

    The correct command to set a blob's tier is az storage blob set-tier with parameters for tier, container, blob name, and account.

  2. Step 2: Verify az storage blob set-tier --tier Cool --container-name mycontainer --name myblob --account-name mystorage matches syntax

    az storage blob set-tier --tier Cool --container-name mycontainer --name myblob --account-name mystorage uses set-tier and correct parameter names, matching Azure CLI documentation.

  3. Final Answer:

    az storage blob set-tier --tier Cool --container-name mycontainer --name myblob --account-name mystorage -> Option B

  4. Quick Check:

    Correct CLI command = az storage blob set-tier --tier Cool --container-name mycontainer --name myblob --account-name mystorage [OK]
Hint: Use 'az storage blob set-tier' to change tier [OK]
Common Mistakes:
  • Using incorrect command verbs like update-tier
  • Wrong parameter names like --container instead of --container-name
  • Mixing blob and container parameters
3. Given this Azure CLI command:
az storage blob set-tier --tier Archive --container-name logs --name log1.txt --account-name mystorage
What happens to the blob log1.txt after this command?
medium
A. Blob remains in Hot tier with no change
B. Blob is deleted permanently
C. Blob is copied to another container
D. Blob is moved to Archive tier and becomes offline until rehydrated

Solution

  1. Step 1: Understand Archive tier behavior

    Setting a blob to Archive tier moves it to a low-cost, offline storage. It cannot be read until rehydrated.

  2. Step 2: Analyze command effect

    The command sets the tier to Archive, so the blob becomes offline and inaccessible until restored.

  3. Final Answer:

    Blob is moved to Archive tier and becomes offline until rehydrated -> Option D

  4. Quick Check:

    Archive tier = offline storage [OK]
Hint: Archive tier blobs are offline until rehydrated [OK]
Common Mistakes:
  • Thinking Archive tier deletes the blob
  • Assuming blob stays accessible immediately
  • Confusing Archive with Hot tier
4. You run this command to change a blob's tier:
az storage blob set-tier --tier Hot --container-name data --name file1.csv --account-name mystorage
But you get an error saying the blob does not exist. What is the most likely cause?
medium
A. The blob name or container name is incorrect
B. The account name is invalid
C. The tier Hot is not supported
D. The Azure CLI is outdated

Solution

  1. Step 1: Understand error meaning

    An error stating the blob does not exist usually means the blob or container name is wrong or the blob was deleted.

  2. Step 2: Check other options

    Account name errors usually give different messages; Hot tier is valid; CLI outdated causes different errors.

  3. Final Answer:

    The blob name or container name is incorrect -> Option A

  4. Quick Check:

    Blob not found = wrong name [OK]
Hint: Check blob and container names first on 'not found' errors [OK]
Common Mistakes:
  • Assuming tier Hot is invalid
  • Blaming CLI version without checking names
  • Ignoring typo in blob or container names
5. You have a large dataset stored in Azure Blob Storage. You want to minimize costs but still access some data occasionally. Which tier strategy is best?
hard
A. Store frequently accessed data in Hot tier, infrequent in Cool, and rarely accessed in Archive
B. Store all data in Archive tier and never rehydrate
C. Store all data in Cool tier regardless of access frequency
D. Store all data in Hot tier for fastest access

Solution

  1. Step 1: Understand tier cost and access trade-offs

    Hot tier is expensive but fast, Cool is cheaper for infrequent access, Archive is cheapest but offline.

  2. Step 2: Apply tier optimization best practice

    Using Hot for frequent, Cool for infrequent, and Archive for rare access balances cost and performance.

  3. Final Answer:

    Store frequently accessed data in Hot tier, infrequent in Cool, and rarely accessed in Archive -> Option A

  4. Quick Check:

    Tier data by access frequency = Store frequently accessed data in Hot tier, infrequent in Cool, and rarely accessed in Archive [OK]
Hint: Match data access frequency to tier for cost savings [OK]
Common Mistakes:
  • Putting all data in Hot tier wastes money
  • Never rehydrating Archive data makes it unusable
  • Using only Cool tier ignores access patterns