Domain 2: Practice Q&A — Storage

Answer each question before expanding the solution. Aim for under 2 minutes per question.

Q1

Your company stores compliance records in Azure Blob Storage. After 90 days, the blobs must be moved to Archive tier. After 3 years, they must be deleted. No manual intervention is acceptable.

Which feature should you configure?

  • A. Azure Backup policies
  • B. Blob lifecycle management policies
  • C. Blob versioning with retention rules
  • D. A logic app that runs daily and checks blob modification dates
Answer + Explanation

Correct: B — Blob lifecycle management policies

Why B: Lifecycle management policies are declarative rules that automatically transition blobs between tiers and delete them based on conditions like daysAfterModificationGreaterThan. No code, no manual action.

Why not A: Azure Backup policies are for protecting resources — they don't tier or delete blobs.

Why not C: Blob versioning preserves previous versions but doesn't automatically move or delete by age.

Why not D: A logic app would work technically but is unnecessary complexity when lifecycle policies do exactly this natively.

Q2

A storage account uses GRS replication. A regional outage affects the primary region. Users report they cannot read data. The secondary region is healthy.

Which action allows reads from the secondary region immediately without initiating a failover?

  • A. Change the replication to RA-GRS
  • B. Manually initiate a failover to the secondary region
  • C. Create a read replica in the secondary region
  • D. This is not possible with GRS — failover is required
Answer + Explanation

Correct: D — GRS does not allow reads from secondary; A would fix the problem going forward but not immediately

Most precise correct answer depends on exact question wording:

  • If the question asks "what should you have done to prevent this?" → A (RA-GRS)
  • If it asks "what can you do right now?" → B (initiate failover) — though this is destructive
  • If GRS is already in place and the outage is ongoing → you cannot read the secondary without failover or changing to RA-GRS (which also has lag)

The exam usually frames this as: "To allow reads from the secondary during an outage without failover, which replication type should you have used?" → RA-GRS or RA-GZRS.

Key rule: GRS = no secondary reads. RA-GRS = secondary reads allowed at https://<account>-secondary.blob.core.windows.net.

Q3

You generate a Service SAS token for a container with read/list permissions, valid for 24 hours. After 2 hours, a security incident requires you to immediately revoke the SAS without affecting other SAS tokens that grant access to other containers.

What is the fastest way to revoke only this SAS?

  • A. Delete the storage container
  • B. Rotate the storage account key used to sign the SAS
  • C. Delete the Stored Access Policy associated with this SAS
  • D. You cannot revoke a standalone SAS — wait for it to expire
Answer + Explanation

Correct: C — Delete the Stored Access Policy (if the SAS was linked to one)

OR

D is correct if the SAS was standalone (not linked to a SAP)

This question tests if you designed correctly: A standalone SAS (no SAP) can only be invalidated by:

  1. Letting it expire
  2. Rotating the signing key (but this breaks ALL SAS tokens signed with that key)

A SAP-linked SAS can be revoked by deleting or modifying the SAP — without rotating the key and without affecting other SAS tokens on other containers.

The correct design for revocable SAS: Always link SAS tokens to Stored Access Policies.

Exam tip: The question is really asking: "Did you know to use a SAP?" If the scenario says you need to revoke a single SAS without side effects, the answer implies a SAP-linked SAS and option C.

Q4

A developer wants to access blob data in a storage account from an Azure VM. You want to follow the principle of least privilege and avoid storing any credentials in the VM or its code.

Which approach should you use?

  • A. Store the storage account access key in an environment variable on the VM
  • B. Assign a system-assigned managed identity to the VM and grant it the Storage Blob Data Reader role on the storage account
  • C. Generate a long-lived SAS token with read permissions and store it in the VM's configuration
  • D. Create a service principal with a client secret and store the secret in Azure Key Vault
Answer + Explanation

Correct: B — Managed identity + Storage Blob Data Reader

Why B: Managed identities are credential-free by design — the VM automatically obtains tokens from the Azure Instance Metadata Service (IMDS). No secret to store, rotate, or leak. Granting Storage Blob Data Reader provides exactly the data-plane access needed.

Why not A: Storing the account key (which has full access) in an env var is insecure and violates least privilege.

Why not C: Long-lived SAS tokens in config files are essentially the same problem as hardcoded credentials — they can be extracted and misused.

Why not D: Service principal + Key Vault is a legitimate pattern, but it's more complex than managed identity and still requires code to fetch the secret. Managed identity is simpler and preferred.

Exam tip: "No credentials to manage" or "no credentials stored in code" on an Azure VM = managed identity.

Q5

A storage account has a ReadOnly lock applied. An administrator with the Owner RBAC role attempts to list the storage account's access keys. The operation fails. What is the correct explanation?

  • A. Owner does not have permission to list keys — they need the Key Vault Secrets Officer role
  • B. The listKeys operation is classified as a write action on the management plane, which ReadOnly locks block
  • C. Access keys can only be listed by users with the Storage Account Contributor role
  • D. The ReadOnly lock prevents all operations, including reads, when applied to storage accounts
Answer + Explanation

Correct: B — listKeys is a write action blocked by ReadOnly locks

Why B: The ARM action Microsoft.Storage/storageAccounts/listKeys/action is classified as a write because retrieving keys grants write-equivalent access to all data in the account. ReadOnly locks block all management-plane write actions — including listKeys — even for Owners.

Why not A: Key Vault Secrets Officer is irrelevant — storage account keys are not stored in Key Vault unless you explicitly put them there.

Why not C: Storage Account Contributor is a valid role, but the issue here is the lock, not RBAC permissions.

Why not D: ReadOnly locks allow read operations — they block writes and listKeys (classified as write). They don't block all operations.

Q6

You need to store VM disk VHD files in Azure Blob Storage. Which blob type must you use?

  • A. Block blob
  • B. Append blob
  • C. Page blob
  • D. Any blob type — the storage account handles the type automatically
Answer + Explanation

Correct: C — Page blob

Why C: Azure VM unmanaged disk VHDs are stored as page blobs because page blobs support random read/write access in 512-byte pages — exactly what a virtual disk requires for random I/O.

Why not A: Block blobs are optimized for streaming large sequential uploads — suitable for files, backups, media. Not for random-access disk I/O.

Why not B: Append blobs only support append operations — no in-place writes. Unusable for VM disks.

Why not D: Blob type must be specified — it doesn't auto-select. You cannot change blob type after creation.

Exam tip: VHD files → page blobs. Log files / event streams → append blobs. Everything else → block blobs.

Q7

You need to store log files that are written to constantly for 30 days, then accessed rarely for the next 60 days, then never accessed again. Cost optimization is the primary goal. Minimum access time must be under 1 hour for any log within its first 90 days.

Which configuration best meets these requirements?

  • A. Hot tier for first 30 days, then Archive for days 30–90, then delete after 90 days
  • B. Hot tier for first 30 days, then Cool tier for days 30–90, then delete after 90 days
  • C. Hot tier for first 30 days, then Cold tier for days 30–90, then delete after 90 days
  • D. Hot tier for entire 90 days, then delete
Answer + Explanation

Correct: B or C — both are valid depending on cost preference, but Archive tier (A) violates the access time requirement.

Why not A: Archive tier requires up to 15 hours for rehydration. The requirement says "under 1 hour" — Archive is immediately disqualified.

Why B (Cool): Cool tier provides immediate access. It's cheaper than Hot for storage cost, more expensive for access. Minimum storage duration is 30 days — which aligns with the transition happening exactly at day 30.

Why C (Cold): Cold tier is cheaper than Cool for storage but more expensive for access. Minimum storage duration is 90 days — transitioning blobs to Cold at day 30 means you're committed for 60 more days, matching the 90-day total. Cold was added in 2023 and is appearing in newer exam versions.

Exam tip: Archive tier = offline, rehydration required. If the question says "must be readable within hours" → Archive is never the answer.

Q8

A company needs to prevent any modification or deletion of financial records stored in Azure Blob Storage for exactly 7 years due to regulatory requirements. Even storage administrators must not be able to delete the data.

Which feature should you configure?

  • A. Blob soft delete with 7-year retention
  • B. Azure Backup with long-term retention policy
  • C. Time-based WORM retention policy (immutability policy)
  • D. ReadOnly resource lock on the container
Answer + Explanation

Correct: C — Time-based WORM (immutability) policy

Why C: A time-based retention policy on a container enforces WORM — Write Once, Read Many. For the duration of the retention period, no one (not even storage admins or owners) can delete or overwrite data. This is the only feature that satisfies the "even admins cannot delete" requirement.

Why not A: Soft delete prevents permanent deletion for a period, but an admin with the right RBAC can bypass soft delete by permanently deleting the soft-deleted blobs. It doesn't block admins.

Why not B: Azure Backup doesn't provide immutability on the original storage data.

Why not D: A ReadOnly lock blocks modifications but can be removed by an Owner or User Access Admin. It's not audit-proof for regulatory compliance.

Exam tip: "Even admins cannot delete" + "regulatory compliance" + "fixed retention period" = WORM immutability policy.