AZ-104 Implement and manage storage: 164 practice questions

12 of the 164 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. Configure the stored access policy with only the required: Which two actions should the administrator take?

Select two. More than one option is correct — every correct one is ticked below.

1. Configure the stored access policy with only the required upload permissions and a short expiration time. ✓

   Least-required permissions and short validity limit the partner’s access and exposure if the SAS is disclosed.
2. Create a private endpoint for the storage account and use it as the partner’s authorization mechanism.

   A private endpoint provides private network connectivity; it does not provide SAS authorization or replace the required permissions and expiration controls.
3. Create a service SAS that references a stored access policy on the target container. ✓

   A service SAS can reference a container stored access policy, and changing that policy can revoke associated SAS tokens without rotating account keys.
4. Create a user delegation SAS and associate it with the stored access policy.

   A user delegation SAS uses Entra credentials and applies to blobs, but it cannot reference a stored access policy; therefore this does not provide the required policy-based revocation.
5. Create an account SAS so the partner can be revoked by changing the stored access policy.

   Account SAS tokens cannot reference stored access policies, so changing the policy would not revoke this SAS.

Use a service SAS tied to a stored access policy, and constrain that policy to the least required permissions and a short lifetime.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. Issue a service SAS for the container that references: Which two actions should the administrator take?

Select two. More than one option is correct — every correct one is ticked below.

1. Issue an account SAS with read permission and a 24-hour expiry.

   An account SAS cannot reference a stored access policy, so changing the container policy would not revoke this SAS as required.
2. Issue a user delegation SAS using Entra credentials and reference the stored access policy.

   A user delegation SAS applies to blobs but cannot reference a stored access policy, so the required policy-based revocation is not achieved.
3. Issue a service SAS with read permission and a 24-hour expiry directly in the SAS token.

   This is a supported service SAS configuration, but it is not associated with a stored access policy; changing that policy therefore cannot revoke it.
4. Issue a service SAS for the container that references the stored access policy. ✓

   A service SAS can reference a container stored access policy, providing the delegated blob access while allowing later policy-based revocation.
5. Create a container stored access policy with read permission and a 24-hour expiry. ✓

   A stored access policy can define the required permission and expiry at container scope, and changing it can revoke associated service SAS tokens without rotating account keys.

Use a container stored access policy and issue a service SAS that references it. This supplies read-only, time-limited access and enables policy-based revocation without key rotation.

12. 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.

Other AZ-104 domains

• Manage Azure identities and governance — 213 questions →
• Deploy and manage Azure compute resources — 196 questions →
• Implement and manage virtual networking — 149 questions →
• Monitor and maintain Azure resources — 112 questions →
• All 834 AZ-104 questions →
• AZ-104 certification: requirements, cost and exam format →