4 of the 9 questions we have for this objective, shown with the answer and the reasoning.
Configure Azure Files and Azure Blob Storage
Stanmore Robotics keeps robot firmware packages as block blobs in the container firmware in the storage account ststanmorefw. Engineers frequently upload a new package with the same blob name, replacing the previous one. The company requires that every previous version of each package be retained automatically until an engineer explicitly removes it, and that any previous version be restorable at any time. Blob soft delete is already enabled with a 7-day retention period.
What should you enable on the storage account?
- AIncrease the blob soft delete retention period to 365 daysSoft delete keeps overwritten data only for the retention period and then removes it permanently; the maximum is 365 days, which does not meet the requirement to retain until explicitly removed.
- BBlob versioningVersioning automatically keeps every earlier version of a blob when it is overwritten or deleted, each with its own version ID, and versions persist until they are explicitly deleted or removed by a lifecycle rule.
- CContainer soft deleteContainer soft delete protects deleted containers; it does nothing for individual blob overwrites.
- DChange feedChange feed records that an overwrite occurred but does not preserve the previous content of the blob.
Why: Blob soft delete and blob versioning both protect against overwrites, but with different lifetimes. Soft delete retains the previous content as a soft-deleted snapshot or version for a fixed retention window and then discards it. Versioning creates an immutable prior version on every overwrite and keeps it indefinitely until something deletes it, which satisfies a requirement for permanent retention under engineer control. Because versions accrue storage cost, a lifecycle management rule that deletes or tiers old versions is the usual companion. The scenario's deciding phrase is retention until explicitly removed, which rules out any time-boxed retention setting.
Configure Azure Files and Azure Blob Storage
Thornbury Legal keeps closed case files in the Archive tier in the storage account stthornburycases. A court issues an order requiring a specific 2 GB case file to be produced within one hour. The file is currently a block blob in the Archive tier.
What should you do to meet the deadline?
- ADownload the blob directly from the Archive tierArchive blobs are offline; read and download operations fail until the blob is rehydrated to an online tier.
- BChange the blob's tier to Hot by using the Standard rehydration priorityStandard priority rehydration can take up to 15 hours, which misses the one-hour deadline.
- CChange the blob's tier to Hot by using the High rehydration priorityHigh priority rehydration is designed to complete in under one hour for objects smaller than 10 GB.
- DEnable blob versioning and read the previous version of the blobVersioning does not change the tier of existing data; any prior versions would also be in Archive and still require rehydration.
Why: The Archive tier trades near-instant access for the lowest storage cost. To read an archived blob you must rehydrate it, either by changing its tier (Set Blob Tier) or by copying it to a new blob in an online tier. Rehydration has two priorities: Standard, which may take up to 15 hours, and High, which targets completion in under one hour for blobs under 10 GB at a higher cost. The one-hour deadline in the scenario is the constraint that forces High priority.
Configure Azure Files and Azure Blob Storage
Birchmere Imaging uploads medical scans as block blobs to the container scans in the general-purpose v2 storage account stbirchmerescans. Scans are viewed frequently for 30 days after upload, rarely afterward, and must be deleted seven years after upload. The company wants the data moved to the Cool tier after 30 days and to the Archive tier after 180 days with minimal administrative effort.
What should you configure?
- AA lifecycle management policy on the storage account with rules that tier blobs to Cool after 30 days, to Archive after 180 days, and delete them after 2,555 days since modificationLifecycle management is the built-in rule engine that transitions and deletes blobs based on age, and it runs automatically with no scripting.
- BAn Azure Automation runbook that lists blobs daily and calls Set Blob Tier based on the upload dateA runbook can achieve the result but requires custom code, scheduling, and maintenance, which is more administrative effort than the native policy.
- CSet the default access tier of the storage account to CoolThe default tier applies to new blobs at upload time and does not move blobs between tiers as they age.
- DAn Azure Data Factory pipeline that copies blobs to a second storage account in the Archive tierData Factory is an integration service; copying to another account adds cost and complexity and still does not handle deletion after seven years.
Why: Lifecycle management is the standard way to implement age-based tiering and retention for block blobs. A policy contains rules, each with filters (prefix, blob type, tags) and actions (tierToCool, tierToCold, tierToArchive, delete) keyed to days since modification, creation, or last access. The policy runs about once a day and applies to general-purpose v2, premium block blob, and blob storage accounts. The scenario asks for minimal administrative effort, which is why the native policy beats automation or pipeline approaches that produce the same outcome by hand.
Configure Azure Files and Azure Blob Storage
Caldwell Media Group created a lifecycle management rule on the storage account stcaldwellmedia that moves block blobs to the Cool tier when they have not been read for 60 days, using the daysAfterLastAccessTimeGreaterThan condition. Ninety days later, an administrator notices that no blobs have moved to Cool even though billing data shows that most blobs have not been accessed since upload.
What is the most likely cause?
- AChange feed is not enabled on the storage accountChange feed records a log of blob changes for consumers such as object replication and point-in-time restore; lifecycle rules do not depend on it.
- BLast access time tracking is not enabled on the storage accountThe access-time condition is evaluated against the blob's LastAccessTime property, which is populated only when last access time tracking is enabled on the account; without tracking there is no access history for the rule to act on, so it never tiers the blobs.
- CBlob versioning is not enabled on the storage accountVersioning is a prerequisite for some features such as object replication, but lifecycle rules on the base blob run without it.
- DThe rule is missing a prefix filter, so it applies to no blobsA rule without a prefix filter applies to all blobs of the specified type in the account, not to none.
Why: Lifecycle rules can key off three timestamps: modification time, creation time, and last access time. The first two are always recorded, but last access time is populated only when you enable the Last access time tracking setting on the account's blob service, and it is updated only by read and write operations on the blob. If a rule uses daysAfterLastAccessTimeGreaterThan and the blob has no LastAccessTime value, the service falls back to the date on which tracking was enabled, so on an account where tracking was never turned on the rule has no access history to work with and moves nothing. Also remember that policies take up to 24 hours to take effect after being created or updated, so a few days of no movement is normal, but 90 days points to the missing prerequisite.