Implement and manage storage
Free Microsoft Certified: Azure Administrator Associate practice — 6 questions on Implement and manage storage, with explanations. No sign-up. Full 12-question mixed test →
A company has a StorageV2 account named storesrc in East US and wants to asynchronously replicate all blob changes to a secondary account named storedest in West US for compliance archiving. They create an object replication policy in the Azure portal, but validation fails with an error about a missing prerequisite. Both accounts currently have only blob soft delete enabled. Which change resolves the validation error?
Object replication requires blob versioning to be enabled on BOTH the source and destination accounts (and change feed on the source) before a policy can be validated and created. Soft delete alone does not satisfy this prerequisite.
A financial services company must store trade records in Blob Storage so that once written, records cannot be modified or deleted for exactly 7 years, the retention period must be extendable if regulations change, and the protection must not be removable early even by a Global Administrator. Which configuration meets this requirement?
A locked time-based retention policy enforces true WORM protection: no user, including a Global Administrator, can delete or modify blobs before the retention date, and locked policies explicitly allow the retention period to be extended (up to 5 times, by up to 10 years) but never shortened or removed.
You issued an ad-hoc service SAS (not tied to a stored access policy) scoped to a blob container, signed with the storage account's key, with an expiry 30 days out. Two days later the token leaks publicly. Other applications are actively using different SAS tokens signed with the same account key, and you cannot risk breaking their access. What is the outcome regarding revoking ONLY the leaked token?
An ad-hoc SAS with no stored access policy has no independent revocation mechanism. The only way to invalidate it early is to rotate the account key that signed it, which invalidates every other SAS signed with that same key — violating the constraint of not breaking other applications. This scenario is the exact reason Microsoft recommends stored access policies, which allow individual policy-level revocation.
You deploy Azure File Sync between an on-premises server endpoint and an Azure file share (cloud endpoint), with cloud tiering enabled and a volume free space policy of 20%. Six months later, users report that some recently uploaded files take a long time to open, while other older files near the start of the folder alphabetically open instantly — with no consistent pattern related to file name. What is the MOST likely cause?
Cloud tiering replaces the content of infrequently accessed files with lightweight stub (reparse point) files on the server endpoint once the volume free space threshold is reached, prioritizing the coldest files by access recency and heat, not alphabetical order. Opening a tiered file triggers an on-demand recall from the Azure file share, which is slower than reading a locally cached file — explaining the described symptom, with the alphabetical observation being coincidental.
A company's storage account uses GZRS. During a regional outage affecting the primary region, the application must continue to READ data (read-only access is acceptable) immediately, without any manual intervention or failover. Which change should be made, and why?
RA-GZRS (Read-Access Geo-Zone-Redundant Storage) adds a separate read-only endpoint in the secondary region that is continuously available, including during a primary region outage, with no failover action required.
An enterprise needs to grant a partner application read and write access to a specific blob container for 4 hours. Policy prohibits storing or distributing storage account access keys anywhere, and requires that the credential used to sign the SAS be revocable independently, without regenerating account keys or invalidating other issued SAS tokens. Which SAS type should be issued?
A user delegation SAS is signed using a key derived from Microsoft Entra ID credentials (via Get User Delegation Key) rather than the storage account key, so no account key is ever stored or distributed. It can be revoked by revoking the underlying Entra ID role assignment or by the delegation key's own short expiration, without touching account keys or affecting other SAS tokens.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →