Task 2.3: Configure Azure Files and Azure Blob Storage

• AChange the tier to hot with standard rehydrate priority

  Incorrect

  Standard priority can take up to 15 hours for objects under 10 GB, which misses the deadline.

• BChange the tier to hot with high rehydrate priority

  Correct

  High priority is processed ahead of standard requests and can finish in under an hour for objects under 10 GB.

• CRead the blob directly from the archive tier with a SAS

  Incorrect

  Archived data is offline; a blob can't be read until it's rehydrated to an online tier.

• DDownload the blob with AzCopy, which reads archived data

  Incorrect

  AzCopy can't read an offline blob either; the data must be rehydrated to an online tier before any download.

A blob in the archive tier is offline. Rehydrate it by changing its tier with Set Blob Tier or by copying it to an online tier, and set x-ms-rehydrate-priority to High when it must be back quickly.

• AIt's deleted, because the rule deletes blobs after 30 days

  Incorrect

  The delete action applies after 365 days; 30 days is the condition for moving the blob to the cool tier.

• BNothing yet, because the rule counts days since the blob was last read

  Incorrect

  These conditions use the last-modified time, not the last access time, so reads don't matter.

• CIt stays in hot, because it was created more than 30 days ago

  Incorrect

  The rule tests days since modification, not since creation; the blob's age doesn't block the move.

• DIt moves to cool now and is deleted 365 days after its last change

  Correct

  Forty days since modification satisfies tierToCool, and the delete action applies after 365 days without modification.

Each action in baseBlob has its own condition. daysAfterModificationGreaterThan is measured from the last modification, so this blob qualifies for tierToCool now and for delete after 365 days. New or changed rules can take up to 24 hours to run.

• AThe container and its blobs, through blob soft delete

  Incorrect

  Blob soft delete restores deleted blobs when their container still exists; it doesn't bring back a deleted container.

• BThe container, through the Undelete Blob operation

  Incorrect

  Undelete Blob restores soft-deleted blobs, not containers, and the container is gone.

• CNothing, since container soft delete was disabled

  Correct

  Container soft delete must have been enabled before the deletion to restore a container and its contents.

• DThe container, by creating a new one with the same name

  Incorrect

  A new container with the same name is empty; it doesn't bring the deleted blobs back.

Container soft delete and blob soft delete protect different things. Only container soft delete, enabled before the deletion, can restore a deleted container; blob soft delete covers blobs, snapshots and versions in containers that still exist.

• ACopy the file from the Previous Versions tab in File Explorer

  Correct

  Share snapshots appear as previous versions on Windows, and single files can be copied back from them.

• BUndelete the share from the soft-deleted shares list

  Incorrect

  Share soft delete recovers a deleted share; the share here wasn't deleted, a file inside it was changed.

• CRestore the share's contents with point-in-time restore for the account

  Incorrect

  Point-in-time restore applies to block blobs, not to files in Azure Files.

• DRehydrate the file from the archive tier

  Incorrect

  Azure Files has no archive tier; rehydration applies to archived blobs.

A share snapshot is a read-only, incremental, point-in-time copy of a share, and files can be restored individually. On Windows, SMB share snapshots show up on the Previous Versions tab; a share can hold up to 200 snapshots.

• AYes, but by restoring with point-in-time restore

  Incorrect

  Soft delete retention is set directly on blob soft delete.

• BNo, the longest retention is 30 days

  Incorrect

  Thirty days is well inside the range; the maximum is 365 days.

• CNo, the longest retention is 90 days

  Incorrect

  The maximum is longer than 90 days.

• DYes, retention can be set from 1 to 365 days

  Correct

  Blob soft delete keeps deleted data for the period you set, between 1 and 365 days.

Blob soft delete takes a retention period between 1 and 365 days, and you can change it at any time.

• AA time-based retention policy of ten years

  Incorrect

  A fixed period doesn't match an unknown end date and can't be shortened once locked.

• BA ReadOnly lock on the storage account

  Incorrect

  Locks protect the account's settings, not the data in it.

• CA legal hold on the container

  Correct

  A legal hold keeps data immutable until the hold is explicitly cleared.

• DBlob soft delete with 365 days of retention

  Incorrect

  Soft delete allows deletes and only keeps a recoverable copy for a time.

Time-based retention keeps data immutable for a set interval; a legal hold keeps it immutable until it's removed, which suits an open-ended case.

• ANo, a share holds at most 5 TiB

  Incorrect

  Shares scale well past 5 TiB: to 100 TiB or 256 TiB per share, depending on the billing model.

• BYes, provided the share uses the NFS protocol

  Incorrect

  The size limit depends on the billing model, not on the protocol.

• CYes, a share can grow to 100 TiB or more

  Correct

  Pay-as-you-go and provisioned v1 shares reach 100 TiB, and provisioned v2 shares 256 TiB.

• DNo, the data must be split across blob containers

  Incorrect

  Splitting isn't needed; the share size limit is higher.

An Azure file share scales to 100 TiB on the pay-as-you-go and provisioned v1 billing models, and to 256 TiB on provisioned v2 (which file shares created as Microsoft.FileShares resources also use), so a 60 TiB share fits either way.

• ARead the archived blob with a SAS that grants read permission

  Incorrect

  Permissions don't help; an archived blob is offline until it's rehydrated.

• BSet the blob's tier to hot, then back to archive after the audit

  Incorrect

  Changing the tier moves the original out of archive, and moving it back starts a new archive period.

• CChange the account's default tier to hot

  Incorrect

  Explicitly archived blobs keep their tier; the default doesn't apply to them.

• DCopy the blob to a new blob in the hot tier

  Correct

  Copy Blob creates an online copy and leaves the source blob unchanged in the archive tier.

Archived blobs can be rehydrated by changing their tier or by copying them to an online tier. Copy Blob is recommended for most scenarios because the original stays in archive.