AZ-104 Implement and manage storage: 141 practice questions

12 of the 141 Implement and manage storage questions in the Certsqill AZ-104 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-104? Take the free 5-min readiness check →

1. Issue a minimally scoped service SAS referencing a stored: Which action should the administrator take?

1. Create a private endpoint for the storage account and use it instead of a SAS to authorize the external application.

   A private endpoint provides private network connectivity, not delegated storage authorization. It does not replace a SAS for granting the external application scoped, time-limited access.
2. Create a user delegation SAS for the container and manage revocation by changing the container's stored access policy.

   A user delegation SAS uses Entra credentials and applies to blobs, but it cannot reference a stored access policy. Therefore, changing that policy does not provide the stated centralized revocation mechanism.
3. Create an account SAS and associate it with a stored access policy on the container.

   An account SAS cannot reference a stored access policy, so this configuration cannot provide the required policy-based centralized revocation.
4. Issue a minimally scoped service SAS referencing a stored access policy. ✓

   A service SAS can reference a container stored access policy. Changing that policy can revoke associated service SAS tokens without rotating account keys, while permissions and expiry limit access.

Use a container service SAS tied to a stored access policy; policy changes can revoke its associated SAS tokens without rotating account keys.

2. Make the account’s DNS name resolve to its private: What should you do first?

1. Make the account’s DNS name resolve to its private endpoint in the application VNet. ✓

   The private endpoint exists, but the client is resolving the service name incorrectly. Correct DNS resolution directs traffic to the private endpoint.
2. Assign Reader on the storage account to the VM's managed identity so it can use the private endpoint.

   Azure RBAC permissions and private connectivity are separate. Reader also does not correct the client's DNS resolution.
3. Grant the VM's managed identity Storage Blob Data Reader at the storage-account scope.

   This can address authorization for blob reads, but it does not change name resolution or establish the private network path.
4. Disable public network access on the storage account and leave DNS unchanged.

   Restricting public access does not make the existing public DNS result resolve to the private endpoint; the DNS problem remains.

The private endpoint is present, but clients must resolve the storage name to its private IP. Fix DNS before changing authorization.

3. Assign Storage Blob Data Reader at the scope of the target: Which Azure RBAC change best satisfies the require

1. Assign Storage Blob Data Reader at the scope of the target storage account. ✓

   This grants the required blob-data read access at the narrowest stated resource scope without adding management permissions.
2. Assign Storage Blob Data Reader at the resource-group scope.

   The role provides the needed data access, but the broader resource-group scope also applies to other storage accounts in that group.
3. Assign Reader at the scope of the target storage account.

   Reader is a management-plane role and does not provide the required blob-data access.
4. Assign Storage Blob Data Contributor at the scope of the target storage account.

   This is a data-plane role at the correct scope, but Contributor grants more data permissions than the required read-only access.

Use the data-plane reader role at the target storage-account scope. A management Reader role is the wrong plane, Contributor is excessive, and resource-group scope is too broad.

4. Link the blob private DNS zone to VNet1 and configure: Which action should the administrator take to make the

1. Assign the VM the Storage Blob Data Reader role at the storage-account scope.

   This can provide authorization to read blobs, but it does not change DNS resolution or establish the private network path.
2. Disable public network access on the storage account and leave the VM's DNS configuration unchanged.

   Disabling public access may enforce network restriction, but it does not provide the required name resolution; the VM would still resolve the service name incorrectly.
3. Create a second private endpoint in VNet1 without changing DNS configuration.

   A second private endpoint is a real configuration, but leaving DNS unchanged does not make the VM resolve the service name to either private endpoint.
4. Link the blob private DNS zone to VNet1 and configure private endpoint name resolution. ✓

   The private endpoint provides the private IP, but clients must resolve the service name appropriately. Linking the relevant private DNS zone to VNet1 addresses the stated name-resolution problem.

Configure private DNS resolution for VNet1. Private endpoint connectivity and DNS resolution are separate requirements.

5. Use the application’s identity to read a test blob: Which verification step best tests the requested result?

1. Use the application’s identity to read a test blob in the storage account. ✓

   This directly tests the requested data-plane result. The effective permissions from inherited and child-scope assignments are additive, so the child Reader assignment does not remove permissions inherited from the subscription role.
2. Create a private endpoint for the storage account and retry the blob read from any client.

   A private endpoint addresses network connectivity, not authorization, and it does not by itself prove that the application has the required RBAC permissions. The client also needs appropriate DNS and network connectivity.
3. Remove the subscription-scope role and retain only the storage-account Reader assignment, then retry the blob read.

   This changes the authorization model instead of verifying the current configuration. It may also remove permissions that are required for the application’s effective access.
4. Confirm that both role assignments appear in the storage account’s access-control list.

   This verifies assignment visibility, not whether the application can actually read blob data. It does not test the requested result.

Use the application identity to perform an actual blob read. This verifies the requested data-plane outcome while preserving the current additive RBAC assignments.

6. Create a stored access policy on the container with read: Which configuration should the administrator use?

1. Assign the application Storage Blob Data Reader at the storage account scope and rely on the role assignment's short duration for revocation.

   This does not meet the requested SAS-based design, and the stated evidence does not establish role assignments as a short-lived, policy-revocable token mechanism for this access.
2. Create a stored access policy on the container with read permission and a short expiry, then issue a service SAS that references the policy. ✓

   A container stored access policy can define the service SAS permissions and expiry, and changing or removing the policy can revoke associated service SAS tokens without rotating account keys.
3. Issue a user delegation SAS for the storage account with read permission and a short expiry, and manage revocation by changing the container's stored access policy.

   A user delegation SAS can provide limited blob access, but it cannot reference a stored access policy, so changing that policy does not revoke this SAS.
4. Issue an account SAS with read permission limited to the target container and use a stored access policy for later revocation.

   An account SAS cannot reference a stored access policy, so the proposed policy-based revocation mechanism does not apply to this token.

Use a read-only service SAS linked to a container stored access policy with a short expiry.

7. Zone-redundant storage: Which redundancy option should the administrator select?

1. Zone-redundant storage (ZRS) ✓

   ZRS synchronously replicates data across availability zones in the primary region, matching the required zonal protection without requiring a secondary region.
2. Locally redundant storage (LRS)

   LRS keeps copies within a single primary-region location, so it does not meet the requirement for synchronous replication across availability zones.
3. Geo-redundant storage (GRS)

   GRS provides asynchronous replication to a secondary region. It does not provide the required synchronous cross-zone replication in the primary region.
4. Read-access geo-zone-redundant storage (RA-GZRS)

   RA-GZRS includes geo-replication whose secondary-region data can lag; the requirement specifically calls for synchronous replication across zones in the primary region and does not require secondary reads.

Choose ZRS because it synchronously replicates blob data across availability zones in the primary region.

8. Create a service SAS for the container and associate it: Which action meets the requirement?

1. Create a service SAS with a long expiry and revoke access by rotating the storage account keys whenever the partner should be blocked.

   This is a real service SAS configuration, but it does not meet the requirement to revoke access by changing a stored access policy and introduces account-wide key rotation.
2. Create an account SAS and associate it with the container’s stored access policy.

   An account SAS cannot reference a stored access policy, so this configuration cannot provide the required policy-based revocation.
3. Create a service SAS for the container and associate it with a stored access policy; change that policy to revoke or alter the access. ✓

   A service SAS can reference a stored access policy on a container. Changing the policy can revoke associated service SAS access without rotating account keys.
4. Continue using a user delegation SAS and associate it with the container’s stored access policy.

   A user delegation SAS applies to blobs but cannot reference a stored access policy, so the failed association is not resolved.

Use a service SAS tied to a container stored access policy. User delegation and account SAS types cannot reference stored access policies.

9. Change the account from GRS to RA-GRS: Which action is still required?

1. Create a service SAS that targets the secondary endpoint.

   A service SAS delegates access permissions and expiry, but it does not enable secondary-region reads. GRS still lacks that capability before failover.
2. Keep GRS and wait for replication to become synchronously consistent.

   Geo-replication to a secondary region is asynchronous; waiting does not make GRS provide synchronous consistency or secondary reads before failover.
3. Change the account from GRS to ZRS.

   ZRS synchronously replicates across availability zones in the primary region, but it does not provide a secondary region for pre-failover reads.
4. Change the account from GRS to RA-GRS. ✓

   GRS provides asynchronous geo-replication but does not allow reads from the secondary before failover. RA-GRS enables that secondary-read capability.

GRS adds asynchronous geo-replication but does not permit reading the secondary before failover. RA-GRS is required for that access pattern.

10. Replication to the secondary region is asynchronous: What best explains this result?

1. The blob must have been deleted from the primary.

   An older secondary version does not demonstrate deletion.
2. Replication to the secondary region is asynchronous. ✓

   A recent primary write may not yet have reached the secondary region.
3. RA-GRS stores no copy outside the primary region.

   RA-GRS maintains a geographically separate copy.
4. The secondary is readable only after account failover.

   RA-GRS allows secondary reads before failover.

A recent primary write may not yet have reached the secondary region.

11. Change the stored access policy to invalidate the SAS: Which verification step best proves that the revocation

1. Rotate one storage account access key, then retry the existing service SAS and confirm that it is rejected.

   Key rotation is a different revocation approach and does not test the stated stored-policy revocation decision. The requirement specifically avoids rotating account keys.
2. Create a new user delegation SAS with the same permissions and confirm that it can upload to the container.

   This verifies that a newly issued blob SAS works, not that the existing service SAS was revoked. A user delegation SAS also uses a different authorization mechanism.
3. Change the stored access policy to invalidate the SAS, then use the unchanged SAS to attempt an upload and confirm access is denied. ✓

   A service SAS can reference a container stored access policy, and changing that policy can revoke associated service SAS tokens without rotating account keys. Testing the unchanged token against the requested upload verifies the actual result.
4. Remove the container's stored access policy and verify that the storage account still permits the SAS request.

   A successful request would demonstrate continued access rather than revocation. The verification must test the unchanged SAS after the policy change and expect denial.

Change the container's stored access policy and test the unchanged service SAS; denial proves revocation without account-key rotation.

12. Enable blob soft delete and configure its retention period: Which action should the administrator take?

1. Enable protection for deleted containers on the storage account.

   Container-deletion protection is distinct from blob soft delete and does not address recovery of individual deleted blobs.
2. Change the storage account to zone-redundant storage (ZRS).

   ZRS synchronously replicates data across availability zones, but redundancy is not the requested protection for logical blob deletion.
3. Enable blob soft delete and configure its retention period to cover the recovery requirement. ✓

   Blob soft delete retains deleted blobs so they can be recovered during the retention period.
4. Create a lifecycle management rule that deletes blobs according to the retention schedule.

   A lifecycle rule automates tier transitions or deletion; it does not provide recovery for accidentally deleted blobs.

Enable blob soft delete because the requirement concerns recovery of individually deleted blobs within a retention period.

Other AZ-104 domains

• Manage Azure identities and governance — 186 questions →
• Deploy and manage Azure compute resources — 169 questions →
• Implement and manage virtual networking — 130 questions →
• Monitor and maintain Azure resources — 96 questions →
• All 722 AZ-104 questions →