Skip to main content

Technical Lab: Configure blob versioning

Questions​

Question 1 — Multiple Choice​

A development team stores configuration files in an Azure Blob Storage container with versioning enabled. A developer accidentally overwrites a blob named config.json with incorrect content. When investigating, they notice that the previous version no longer appears as the current version.

Which statement correctly describes the versioning behavior in this scenario?

A) The overwrite permanently deletes the previous version, as versioning only protects against deletions, not overwrites.

B) The previous version is automatically promoted to the current version after the overwrite is detected as incorrect by the service.

C) The overwrite creates a new current version, and the previous version is automatically preserved with its own version ID.

D) Versioning prevents the blob from being overwritten while the previous version is not explicitly deleted by the user.

Question 2 — Technical Scenario​

An administrator needs to enable versioning on an existing storage account. They execute the following command:

az storage account blob-service-properties update \
  --account-name mystorageaccount \
  --resource-group myRG \
  --enable-versioning true

After successful execution, they notice that blobs created before the command do not have previous versions listed.

What is the correct explanation for this behavior?

A) The command was executed incorrectly; the correct parameter is --versioning-enabled.

B) Versioning only applies to operations performed after its enablement; the previous history is not retroactive.

C) It is necessary to restart the storage account for versioning to start tracking existing blobs.

D) Existing blobs need to be copied to a new container for versioning to start tracking them.

Question 3 — True or False​

When blob versioning is enabled and a blob is deleted without using soft delete, the current version is removed, but previous versions remain accessible indefinitely until explicitly deleted or removed by a lifecycle management policy.

Question 4 — Technical Scenario​

An organization uses blob versioning and wants to implement a retention strategy that keeps only the 3 most recent versions of each blob, automatically deleting the rest. The infrastructure team proposes the following lifecycle policy:

{
  "rules": [
    {
      "name": "limit-versions",
      "enabled": true,
      "definition": {
        "filters": { "blobTypes": ["blockBlob"] },
        "actions": {
          "version": {
            "delete": { "daysAfterCreationGreaterThan": 0 }
          }
        }
      }
    }
  ]
}

The team notices that the policy is deleting all previous versions, including recent ones. What is the cause of the problem?

A) The property daysAfterCreationGreaterThan: 0 deletes any version that is not current at the time of policy evaluation, without respecting a minimum count of versions to preserve.

B) The blobTypes field does not support versioning; it is necessary to use appendBlob to control versions with lifecycle.

C) The version.delete action only works when combined with the baseBlob.delete action in the same rule.

D) The problem is in the enabled: true field; versions are only managed by policies defined as enabled: false during the testing period.

Question 5 — Multiple Choice​

When working with versioning enabled, an operator wants to restore a previous version of a blob as the current version, without deleting the existing history.

What is the correct approach to perform this operation?

A) Delete the current version and wait for the service to automatically promote the most recent previous version.

B) Use the Copy Blob operation to copy the previous version over the base blob, creating a new current version that reflects the previous content.

C) Use the Undelete Blob operation to revert the base blob to the desired version state.

D) Manually change the version ID of the previous version so the service recognizes it as the current version.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: C

When versioning is enabled, any write operation that modifies the content of an existing blob (such as an overwrite via Put Blob or Put Block List) automatically preserves the previous state as an immutable version with a unique version ID based on timestamp. The new write becomes the current version. Versioning protects against both overwrites and deletions.

The main misconception represented by the distractors is assuming that versioning only works as protection against deletion (distractor A) or that it prevents write operations (distractor D). In practice, versioning does not block any operations; it records the history transparently.

Answer Key — Question 2​

Answer: B

Versioning in Azure Blob Storage is prospective: it starts creating versions from the moment it is enabled. Blobs that existed before enablement do not retroactively receive a version history. The first recorded version for a pre-existing blob is only created on the next write or delete operation that occurs after enablement.

Distractors C and D represent common operational misconceptions: the service does not require restart and there is no need to migrate blobs between containers. Distractor A is plausible for those who don't remember the exact syntax, but the parameter used in the command is correct.

Answer Key — Question 3​

True

When a blob is deleted with versioning enabled but without soft delete, the current version (the base blob) is removed, making the blob invisible in standard listings. However, previous versions remain in storage and continue to be accessible through calls that include the version ID. They persist until explicitly deleted or removed by a lifecycle management rule.

This behavior is relevant for cost planning: orphaned versions accumulate storage charges even after the base blob is deleted. Combining versioning with lifecycle management is the recommended practice to control this accumulation.

Answer Key — Question 4​

Answer: A

The version.delete action with daysAfterCreationGreaterThan: 0 instructs the service to delete any previous version that is at least 0 days since its creation, i.e., all previous versions immediately on the next policy evaluation. Azure Blob Storage lifecycle management does not natively offer an option like "keep the N most recent versions" as a direct parameter. To preserve recent versions, it would be necessary to use a larger value in daysAfterCreationGreaterThan, accepting that versions older than X days will be deleted, without guarantee of minimum count.

Distractors B and C represent incorrect assumptions about service restrictions that do not exist. Distractor D is technically implausible, but was included for representing a misconception about the enabled field.

Answer Key — Question 5​

Answer: B

The correct way to promote a previous version to the current version is to use the Copy Blob operation, copying the versioned blob (identified by its version ID) over the base blob. This operation creates a new current version with the desired content and, at the same time, preserves the entire history of previous versions, including the version that was used as the source of the copy.

Distractor A is incorrect because deleting the current version does not automatically promote any previous version; it simply removes the base blob. Distractor C confuses Undelete Blob, which is an operation related to soft delete, not versioning. Distractor D represents an impossible operation: version IDs are immutable and generated by the service.