This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure storage, databases, and networking (25–30%)
   --> Implement security for storage accounts
      --> Manage access to storage, including access policies

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

Managing access to Azure Storage is a core security responsibility in the Secure storage, databases, and networking domain of the SC-500 exam. You should understand how to select an authorization method, assign permissions at the appropriate scope, create shared access signatures, manage stored access policies, and reduce the risks associated with Shared Key authorization.

Azure Storage supports several access-control mechanisms. The correct choice depends on whether the workload uses Microsoft Entra identities, requires temporary delegated access, needs file- and directory-level permissions, or must support legacy applications.

1. Understand the Azure Storage Authorization Models

Azure Storage authorization can be broadly divided into the following models:

1. Microsoft Entra ID and Azure RBAC
2. Microsoft Entra ID and access control lists
3. Shared access signatures
4. Shared Key authorization
5. Anonymous public access, where explicitly permitted

Microsoft recommends Microsoft Entra ID with managed identities whenever possible because access can be centrally governed, audited, and revoked without distributing storage account keys.

Microsoft Entra ID and Azure RBAC

Microsoft Entra ID provides identity-based authentication, while Azure RBAC determines what the authenticated identity is allowed to do.

The identity may be:

• A user
• A group
• A service principal
• A managed identity
• An application

For example, an Azure Function or AI agent can use a managed identity to access Blob Storage without storing a connection string or account key in application configuration.

Common built-in data-plane roles include:

Assign roles at the smallest practical scope:

• Storage account
• Container
• File share
• Queue
• Table
• Resource group
• Subscription

For example, if an application only needs to read blobs in one container, assign Storage Blob Data Reader at the container scope instead of granting access to the entire storage account.

Important distinction: Management-plane versus data-plane roles

A role such as Storage Account Contributor allows a principal to manage the storage account resource, but it does not automatically grant access to the contents of blobs, files, queues, or tables.

Conversely, a role such as Storage Blob Data Reader grants access to blob data but does not provide general permission to modify the storage account configuration.

This distinction is frequently tested in certification questions.

2. Use Microsoft Entra ID with Managed Identities

Managed identities are usually the preferred authorization method for Azure-hosted applications.

A managed identity:

• Eliminates the need to store credentials in application code
• Uses Microsoft Entra authentication
• Can be assigned Azure RBAC roles
• Can be revoked centrally
• Supports auditing through identity and resource logs
• Works well with Azure Functions, App Services, virtual machines, AKS, and other Azure services

Example

An Azure Function must read customer documents from a Blob Storage container.

A secure design would be:

1. Enable a system-assigned or user-assigned managed identity on the Function App.
2. Assign Storage Blob Data Reader to the identity.
3. Scope the role to the required container.
4. Configure the application to use Microsoft Entra authentication.
5. Avoid storing the storage account key in application settings.

This is more secure than embedding a connection string containing an account key.

3. Understand Access Control Lists in Azure Data Lake Storage

Access control lists, or ACLs, provide more granular access control for directories and files in accounts that use the hierarchical namespace capability of Azure Data Lake Storage Gen2.

ACLs can control access at the:

• File-system level
• Directory level
• File level

ACLs use POSIX-style permissions, commonly represented as:

• Read
• Write
• Execute

For directories:

• Read allows listing directory contents.
• Write allows creating, deleting, or renaming items, subject to the applicable permissions.
• Execute allows traversing the directory.

For files:

• Read allows reading the file.
• Write allows modifying the file.
• Execute is generally relevant to directory traversal rather than ordinary file execution.

ACLs can be assigned to:

• Individual users
• Groups
• Named users or groups
• Default ACL entries inherited by newly created child items

RBAC and ACL evaluation

For Azure Data Lake Storage Gen2, access may depend on both Azure RBAC and ACLs.

A principal may receive access through:

• Azure RBAC
• POSIX ACLs
• Both

When using a user delegation SAS, the effective access is constrained by the permissions available to the identity that requested the user delegation key and the permissions included in the SAS. If hierarchical namespace is enabled, ACLs can also participate in authorization when RBAC does not grant the required access.

Common ACL mistake

Granting a user read permission on a file is not always sufficient. The user may also need execute permission on each parent directory to traverse the path to that file.

4. Understand Shared Access Signatures

A shared access signature, or SAS, provides delegated, time-limited access to a storage resource.

A SAS can restrict:

• The resource being accessed
• The permitted operations
• The start time
• The expiration time
• The allowed protocol
• The permitted IP address range
• The resource type
• The signing authority

For example, a SAS might allow a customer to upload one file to a specific container for 15 minutes without granting the customer access to the rest of the storage account.

SAS types

The major SAS types include:

Microsoft recommends using a user delegation SAS when SAS is required for Blob Storage or Data Lake Storage because it is signed using Microsoft Entra credentials rather than the storage account key.

User delegation SAS

To create a user delegation SAS:

1. Authenticate the requesting principal with Microsoft Entra ID.
2. Grant the principal permission to request a user delegation key.
3. Request the user delegation key.
4. Construct the SAS with the required permissions and restrictions.
5. Provide the SAS to the client over a secure channel.

A user delegation SAS can be scoped to a blob, container, directory, or prefix, depending on the supported storage service and authorization version.

SAS security practices

Always:

• Use HTTPS-only access.
• Grant only the required permissions.
• Use the shortest practical expiration period.
• Restrict the SAS to the required resource.
• Avoid distributing SAS tokens broadly.
• Have a revocation or replacement plan.
• Prefer user delegation SAS over account-key-based SAS when possible.

A SAS is effectively a bearer token. Anyone who obtains a valid SAS may use it within its permitted scope and lifetime. Microsoft Entra identity checks do not automatically identify the person using a SAS.

5. Understand Stored Access Policies

A stored access policy is a server-side policy that can be associated with a service SAS.

For Blob Storage, stored access policies are defined on a container. For Azure Files, they are defined on a file share.

A stored access policy can specify:

• Permissions
• Start time
• Expiration time
• Policy identifier

The SAS references the policy identifier rather than necessarily containing all of the access settings itself.

Why use a stored access policy?

Stored access policies provide centralized control over the lifecycle of associated SAS tokens.

For example, suppose a vendor receives a SAS that references a policy named vendor-read.

If the vendor’s access must be revoked, an administrator can:

• Delete the stored access policy
• Change its expiration time
• Change its permissions

This can invalidate or modify the behavior of SAS tokens associated with that policy.

Without a stored access policy, a service SAS signed with an account key generally cannot be individually revoked before it expires unless the account key is rotated or another broader revocation mechanism is used.

Important limitation

Stored access policies are not supported for user delegation SAS or account SAS. They are associated with service SAS scenarios for supported services.

Stored access policy configuration

The process generally involves two steps:

1. Create or update the stored access policy on the container or file share.
2. Create a SAS that references the policy.

The policy and SAS must collectively provide the required authorization fields. If required values are missing, the request fails. If the same value is specified in both the policy and the SAS where duplication is not permitted, the request may fail.

A container can have a maximum of five stored access policies at one time.

Example policy design

A company provides a third-party auditor with read-only access to a container.

The administrator creates a stored access policy with:

• Policy ID: audit-read
• Permission: Read
• Start time: Current time
• Expiration: Seven days from now

The auditor receives a service SAS referencing audit-read.

If the audit ends early, the administrator can delete or modify the stored access policy rather than waiting for the SAS to expire.

6. Stored Access Policies and Revocation

Stored access policies are useful for centralized SAS lifecycle management, but revocation may not be instantaneous.

After creating or updating a stored access policy, allow up to approximately 30 seconds for the change to take effect. During this period, a SAS associated with the policy may temporarily continue to work or may return a 403 response while the policy becomes active.

Exam distinction

A stored access policy can help revoke a service SAS, but it does not:

• Identify the person using the SAS
• Replace Microsoft Entra authentication
• Provide network isolation
• Encrypt the data
• Automatically prevent the SAS from being copied
• Apply to every SAS type

7. Disable Shared Key Authorization

Shared Key authorization uses one of the storage account access keys. These keys provide broad access to the storage account and should be treated like highly privileged secrets.

If an attacker obtains an account key, the attacker may be able to access or modify data across the storage account, depending on the services and operations involved.

Microsoft recommends disabling Shared Key authorization when workloads can use Microsoft Entra ID instead.

The storage account property is:

allowSharedKeyAccess = false

When Shared Key authorization is disabled:

• Requests signed with the account keys are rejected.
• Microsoft Entra authorization remains available.
• User delegation SAS can still be used where supported.
• Applications that depend on account keys or service SAS may stop working.

Before disabling Shared Key authorization

Inventory:

• Connection strings
• Application settings
• Azure Functions
• Logic Apps
• Data integration tools
• Storage Explorer workflows
• Automation scripts
• Third-party applications
• Service SAS tokens
• Account SAS tokens

Do not disable Shared Key authorization without validating application compatibility.

Enforce the setting with Azure Policy

Azure Policy can be used to audit or deny storage accounts that permit Shared Key authorization.

A policy-based approach can:

• Identify noncompliant accounts
• Prevent new noncompliant deployments
• Support remediation
• Enforce the organization’s security baseline consistently

This is especially useful in large environments where manually checking each storage account is impractical.

8. Anonymous Public Access

Blob Storage can support anonymous public access if it is enabled at both the storage-account and container levels.

Anonymous access should be disabled unless it is explicitly required.

A secure baseline is to:

1. Disable public blob access at the storage-account level.
2. Avoid setting containers to public access.
3. Use Microsoft Entra ID or SAS for controlled access.
4. Monitor for accidental exposure.
5. Use Azure Policy to enforce the configuration.

Disabling anonymous access does not prevent authorized access through Microsoft Entra ID or SAS.

9. Choosing the Correct Authorization Method

10. Common Exam Traps

Trap 1: Confusing management access with data access

Being a Storage Account Contributor does not necessarily grant permission to read blob contents.

Trap 2: Assuming SAS identifies the user

A SAS is a bearer token. Possession of the token may be sufficient to use it within its scope.

Trap 3: Assuming all SAS tokens support stored access policies

Stored access policies are not supported for user delegation SAS or account SAS.

Trap 4: Granting excessive RBAC scope

Assigning a data-plane role at the subscription level may provide much more access than required.

Trap 5: Disabling Shared Key without checking dependencies

Legacy applications and existing service SAS tokens may fail when Shared Key authorization is disabled.

Trap 6: Assuming ACLs replace RBAC

ADLS Gen2 ACLs provide fine-grained file and directory permissions, but they operate within the broader identity and authorization model.

Trap 7: Assuming a SAS is automatically safe

A SAS can be copied, logged, exposed in URLs, or misused until it expires or is revoked.

Trap 8: Forgetting directory traversal permissions

In ADLS Gen2, a user may need execute permissions on parent directories to reach a file.

11. Recommended Security Checklist

Use the following checklist when securing Azure Storage access:

• Prefer Microsoft Entra ID over Shared Key authorization.
• Use managed identities for Azure-hosted workloads.
• Assign data-plane RBAC roles at the smallest reasonable scope.
• Use ACLs for directory- and file-level control in ADLS Gen2.
• Disable anonymous public access unless explicitly required.
• Use user delegation SAS when a SAS is necessary.
• Restrict SAS permissions, resources, protocols, and lifetimes.
• Use stored access policies for centrally managed service SAS lifecycles.
• Protect storage account keys in Azure Key Vault if they must be used.
• Rotate account keys according to a documented procedure.
• Inventory applications before disabling Shared Key authorization.
• Use Azure Policy to enforce security settings.
• Monitor authorization failures and suspicious access patterns.
• Never place SAS tokens or account keys in source code, logs, screenshots, or public repositories.

Practice Exam Questions

Question 1

An Azure Function needs to read blobs from a single container. The security team wants to avoid storing credentials in application settings and wants the access to be revocable through Azure role assignments.

What should you implement?

A. A container-level stored access policy
B. A managed identity with the Storage Blob Data Reader role
C. An account SAS signed with the storage account key
D. Anonymous read access on the container

Correct answer: B

Explanation: A managed identity combined with the Storage Blob Data Reader role provides identity-based access without storing credentials in the application. The role should be scoped to the required container whenever possible. A stored access policy is associated with a service SAS and is not a replacement for managed identity authorization.

Question 2

A company provides a third-party auditor with read-only access to a Blob Storage container. The company must be able to revoke the access before the SAS expiration time without rotating the storage account key.

What should the company use?

A. A service SAS associated with a stored access policy
B. A user delegation SAS with write permissions
C. Anonymous public access
D. An account SAS with a one-year expiration

Correct answer: A

Explanation: A service SAS associated with a stored access policy can be revoked by deleting or modifying the policy. Stored access policies provide centralized lifecycle management for supported service SAS tokens. Anonymous access is not appropriate, and an account SAS does not support stored access policies.

Question 3

An organization wants to prevent applications from authenticating to a storage account by using account keys. Applications have already been migrated to managed identities and Microsoft Entra authorization.

Which setting should be configured?

A. Set allowSharedKeyAccess to false
B. Enable anonymous blob access
C. Enable public network access
D. Assign Storage Account Contributor to all applications

Correct answer: A

Explanation: Setting allowSharedKeyAccess to false disables Shared Key authorization for the storage account. This helps prevent account-key-based access. The organization should first verify that all dependent applications and SAS workflows support the change.

Question 4

A data engineering team uses Azure Data Lake Storage Gen2. A user must read a file located at:

finance/2026/reports/revenue.csv

The user has read permission on the file but receives an authorization error when accessing it.

What is the most likely missing permission?

A. Storage Account Contributor on the subscription
B. Write permission on the file
C. Execute permission on one or more parent directories
D. Owner permission on the storage account

Correct answer: C

Explanation: In hierarchical namespace-enabled storage, the user may need execute permission on the parent directories to traverse the path to the file. Read permission on the file alone may not be sufficient.

Question 5

An application must allow a customer to upload one file to a specific container for 10 minutes. The customer must not be able to read existing files or delete objects.

Which SAS permissions are most appropriate?

A. Read and delete
B. Create and write
C. List and read
D. Full account permissions

Correct answer: B

Explanation: Create and write permissions are appropriate for uploading a new file. Read and delete permissions are not required and would increase risk. The SAS should also be restricted to the required resource, use HTTPS, and expire after the shortest practical period.

Question 6

Which statement correctly describes a user delegation SAS?

A. It is signed using a Microsoft Entra-based user delegation key
B. It can only be created by using a storage account key
C. It always supports stored access policies
D. It grants unrestricted access to the entire storage account

Correct answer: A

Explanation: A user delegation SAS is created using a user delegation key obtained through Microsoft Entra authorization. It is generally preferred over account-key-based SAS for supported scenarios. Stored access policies are not supported for user delegation SAS, and the SAS remains limited by its specified permissions and scope.

Question 7

An administrator updates a stored access policy to revoke access. Immediately afterward, a client continues to access the resource successfully.

What should the administrator understand?

A. Stored access policies cannot revoke SAS tokens
B. The storage account must always be deleted and recreated
C. The SAS must be converted to an account SAS
D. Changes to stored access policies may take approximately 30 seconds to take effect

Correct answer: D

Explanation: Changes to stored access policies may take up to approximately 30 seconds to become effective. During this interval, associated SAS requests may not immediately reflect the policy change.

Question 8

A security engineer assigns Storage Account Contributor to an application. The application can manage the storage account but cannot read blob contents.

What is the best explanation?

A. Blob Storage does not support Microsoft Entra ID
B. The application must use anonymous access
C. The application needs an appropriate blob data-plane role
D. The application must be assigned Owner at the subscription level

Correct answer: C

Explanation: Storage Account Contributor is primarily a management-plane role. Reading blob contents requires a suitable data-plane role, such as Storage Blob Data Reader, assigned at an appropriate scope.

Question 9

A company must provide a service provider with temporary read access to a container. The company wants to restrict the SAS to HTTPS, read-only operations, and a short expiration time.

Which design best meets the requirement?

A. A narrowly scoped service SAS with read permission, HTTPS-only access, and a short lifetime
B. An account SAS with all service and resource permissions
C. Anonymous public access to the container
D. A storage account key embedded in the provider’s application

Correct answer: A

Explanation: A narrowly scoped SAS should include only the permissions and resource access required. HTTPS-only access and a short expiration reduce the risk of token exposure and misuse. An account SAS and storage account key provide excessive access.

Question 10

An organization wants to enforce a rule that all storage accounts must use Microsoft Entra authorization and must not allow Shared Key authorization.

What should the organization use to enforce this requirement consistently across subscriptions?

A. A stored access policy on every container
B. A SAS token with a short expiration
C. An ACL on the root directory
D. Azure Policy targeting the Shared Key authorization setting

Correct answer: D

Explanation: Azure Policy can audit, deny, and help remediate storage accounts that allow Shared Key authorization. This provides consistent governance across subscriptions and resource groups. Stored access policies, SAS tokens, and ACLs do not enforce the storage-account-level authorization setting.

Final Summary

For the SC-500 exam, remember these key principles:

• Managed identities and Microsoft Entra ID are preferred for application access.
• Azure RBAC controls access to storage data and should be assigned at the smallest practical scope.
• ACLs provide file- and directory-level permissions in ADLS Gen2.
• SAS tokens provide delegated, limited, time-bound access.
• Stored access policies centrally manage supported service SAS lifecycles.
• User delegation SAS is signed through Microsoft Entra credentials and does not support stored access policies.
• Shared Key authorization should be disabled when applications no longer require it.
• Azure Policy can enforce storage authorization requirements at scale.
• Least privilege, short lifetimes, HTTPS, and careful secret handling are essential for secure storage access.

Go to the SC-500 Exam Prep Hub main page