Configure access to storage
📘Microsoft Certified: Azure Administrator Associate (AZ-104)
What Is a Stored Access Policy?
A Stored Access Policy (SAP) is an optional security control that you can apply to a container, file share, table, or queue in Azure Storage.
It is used to manage one or more Shared Access Signatures (SAS) by defining:
- Start time (optional)
- Expiry time
- Permissions (read, write, list, delete, etc.)
Instead of embedding permissions and expiry times inside every SAS token, you can attach multiple SAS tokens to a single stored access policy. This lets you change or revoke permissions centrally without needing to regenerate SAS tokens individually.
Why Stored Access Policies Matter (Exam-Relevant Points)
The AZ-104 exam wants you to know why SAPs are better than standalone SAS tokens:
✔ 1. Easy Revocation
If a SAS token is leaked:
- Delete or modify the stored access policy → all SAS tokens using it instantly become invalid.
Without SAP:
You would need to regenerate the entire storage account keys, which affects all applications.
✔ 2. Centralized Management
You can update the permissions or expiry time in the policy, and all SAS tokens linked to it automatically inherit those changes.
✔ 3. More Secure Enterprise Operations
Organizations often issue many SAS URLs to apps, developers, automation scripts, and external partners.
SAPs make managing these safer and easier.
Where Can You Use Stored Access Policies?
Stored access policies apply only to:
| Storage Type | Supported? |
|---|---|
| Blob Containers | ✔ Yes |
| File Shares (Azure Files) | ✔ Yes |
| Queues | ✔ Yes |
| Tables | ✔ Yes |
| Individual Blobs | ✘ No |
| General Storage Accounts | ✘ No (must attach to a specific container/share/table/queue) |
Key Elements Inside a Stored Access Policy
A policy includes:
- Identifier (Policy Name)
- Must be unique within the container/share/table/queue.
- Start Time (optional)
- When the SAS becomes active.
- Expiry Time
- When the SAS becomes invalid.
- Permissions
- What operations SAS users can perform.
Blob container permissions include:
r– Readw– Writed– Deletel– Lista– Addc– Create
How Stored Access Policies Work with SAS
When generating a SAS token, you choose one of two types:
1. Ad-hoc SAS (no stored access policy)
Permissions & expiry embedded in the SAS token.
2. SAS linked to a stored access policy
The SAS inherits:
- Permissions
- Expiry
- Start time
from the stored access policy.
Important exam note:
If both the SAS and the stored access policy define expiry/permissions, the most restrictive values apply.
Scenario: Why IT Teams Use Stored Access Policies
Example IT Situation (exam-appropriate)
Your organization runs an application that uploads diagnostic logs to a blob container. Developers need temporary access to read the logs.
Instead of:
- Creating individual SAS tokens with hard-coded expiry values
- Manually revoking access if someone leaves the project
You create:
- A stored access policy named “dev-read”
- With read-only permissions
- Expiring in 24 hours
Then issue multiple SAS tokens mapped to this policy.
If someone should lose access early:
- Remove or update the “dev-read” policy
→ All issued SAS tokens stop working immediately.
How to Create a Stored Access Policy (Azure Portal)
Steps:
- Open the Storage account.
- Go to the Blob service (or File Shares/Queues/Tables).
- Select a container.
- Click Shared access tokens OR Access policy (UI differs slightly).
- Under Stored access policies, click Add.
- Set:
- Name (Identifier)
- Start time (optional)
- Expiry time
- Permissions
- Click Save.
- Then generate a SAS token that uses this policy.
How to Create a Stored Access Policy (Azure CLI)
Example: Create a policy on a blob container:
az storage container policy create \
--account-name mystorageaccount \
--container-name logs \
--name readpolicy \
--permissions r \
--expiry 2025-01-01T00:00Z
Generate a SAS with it:
az storage container generate-sas \
--account-name mystorageaccount \
--container-name logs \
--policy-name readpolicy \
--https-only \
--output tsv
How to Modify or Delete a Stored Access Policy
Changing the policy affects all linked SAS tokens.
To modify:
- Change permissions or expiry time.
- Save the updated policy.
To revoke access:
- Delete the policy.
→ All SAS tokens linked to it immediately become invalid.
Best Practices for Stored Access Policies (Important for AZ-104)
The exam expects you to know best practice rules:
✔ Use stored access policies whenever issuing SAS tokens to teams or applications.
✔ Limit the number of stored access policies
Azure storage supports up to 5 policies per container/share/table/queue.
✔ Set short expiry times, then renew by modifying the policy if needed.
✔ Never grant more permissions than necessary.
✔ Protect the policy name
Anyone with the SAS token + policy name can use it.
✔ Use HTTPS-only SAS tokens.
Common AZ-104 Exam Questions About Stored Access Policies
1. How can you revoke a SAS token immediately?
- Delete or modify the stored access policy used by that SAS.
2. Can a stored access policy be applied to individual blobs?
- No. Only containers, file shares, queues, and tables.
3. What happens if a SAS token has an expiry date but the policy also has an expiry date?
- The most restrictive expiry time is used.
4. How many stored access policies can exist per container?
- Up to 5
5. Why use stored access policies instead of ad-hoc SAS?
- Centralized management
- Easy revocation
- Security best practices
Summary
Stored access policies allow Azure administrators to:
- Manage SAS tokens in a centralized way
- Modify or revoke access instantly
- Avoid regenerating storage account keys
- Apply consistent security rules in production systems
For the AZ-104 exam, ensure you understand:
- What stored access policies are
- When to use them
- How they secure SAS tokens
- How to create, update, and delete them
- How they behave when combined with SAS permissions
Mastering this topic helps you manage secure access for applications, teams, automation systems, and external clients in any Azure Storage environment.
What Is a Stored Access Policy?
A Stored Access Policy (SAP) is an optional security control that you can apply to a container, file share, table, or queue in Azure Storage.
It is used to manage one or more Shared Access Signatures (SAS) by defining:
- Start time (optional)
- Expiry time
- Permissions (read, write, list, delete, etc.)
Instead of embedding permissions and expiry times inside every SAS token, you can attach multiple SAS tokens to a single stored access policy. This lets you change or revoke permissions centrally without needing to regenerate SAS tokens individually.
Why Stored Access Policies Matter (Exam-Relevant Points)
The AZ-104 exam wants you to know why SAPs are better than standalone SAS tokens:
✔ 1. Easy Revocation
If a SAS token is leaked:
- Delete or modify the stored access policy → all SAS tokens using it instantly become invalid.
Without SAP:
You would need to regenerate the entire storage account keys, which affects all applications.
✔ 2. Centralized Management
You can update the permissions or expiry time in the policy, and all SAS tokens linked to it automatically inherit those changes.
✔ 3. More Secure Enterprise Operations
Organizations often issue many SAS URLs to apps, developers, automation scripts, and external partners.
SAPs make managing these safer and easier.
Where Can You Use Stored Access Policies?
Stored access policies apply only to:
| Storage Type | Supported? |
|---|---|
| Blob Containers | ✔ Yes |
| File Shares (Azure Files) | ✔ Yes |
| Queues | ✔ Yes |
| Tables | ✔ Yes |
| Individual Blobs | ✘ No |
| General Storage Accounts | ✘ No (must attach to a specific container/share/table/queue) |
Key Elements Inside a Stored Access Policy
A policy includes:
- Identifier (Policy Name)
- Must be unique within the container/share/table/queue.
- Start Time (optional)
- When the SAS becomes active.
- Expiry Time
- When the SAS becomes invalid.
- Permissions
- What operations SAS users can perform.
Blob container permissions include:
r– Readw– Writed– Deletel– Lista– Addc– Create
How Stored Access Policies Work with SAS
When generating a SAS token, you choose one of two types:
1. Ad-hoc SAS (no stored access policy)
Permissions & expiry embedded in the SAS token.
2. SAS linked to a stored access policy
The SAS inherits:
- Permissions
- Expiry
- Start time
from the stored access policy.
Important exam note:
If both the SAS and the stored access policy define expiry/permissions, the most restrictive values apply.
Scenario: Why IT Teams Use Stored Access Policies
Example IT Situation (exam-appropriate)
Your organization runs an application that uploads diagnostic logs to a blob container. Developers need temporary access to read the logs.
Instead of:
- Creating individual SAS tokens with hard-coded expiry values
- Manually revoking access if someone leaves the project
You create:
- A stored access policy named “dev-read”
- With read-only permissions
- Expiring in 24 hours
Then issue multiple SAS tokens mapped to this policy.
If someone should lose access early:
- Remove or update the “dev-read” policy
→ All issued SAS tokens stop working immediately.
How to Create a Stored Access Policy (Azure Portal)
Steps:
- Open the Storage account.
- Go to the Blob service (or File Shares/Queues/Tables).
- Select a container.
- Click Shared access tokens OR Access policy (UI differs slightly).
- Under Stored access policies, click Add.
- Set:
- Name (Identifier)
- Start time (optional)
- Expiry time
- Permissions
- Click Save.
- Then generate a SAS token that uses this policy.
How to Create a Stored Access Policy (Azure CLI)
Example: Create a policy on a blob container:
az storage container policy create \
--account-name mystorageaccount \
--container-name logs \
--name readpolicy \
--permissions r \
--expiry 2025-01-01T00:00Z
Generate a SAS with it:
az storage container generate-sas \
--account-name mystorageaccount \
--container-name logs \
--policy-name readpolicy \
--https-only \
--output tsv
How to Modify or Delete a Stored Access Policy
Changing the policy affects all linked SAS tokens.
To modify:
- Change permissions or expiry time.
- Save the updated policy.
To revoke access:
- Delete the policy.
→ All SAS tokens linked to it immediately become invalid.
Best Practices for Stored Access Policies (Important for AZ-104)
The exam expects you to know best practice rules:
✔ Use stored access policies whenever issuing SAS tokens to teams or applications.
✔ Limit the number of stored access policies
Azure storage supports up to 5 policies per container/share/table/queue.
✔ Set short expiry times, then renew by modifying the policy if needed.
✔ Never grant more permissions than necessary.
✔ Protect the policy name
Anyone with the SAS token + policy name can use it.
✔ Use HTTPS-only SAS tokens.
Common AZ-104 Exam Questions About Stored Access Policies
1. How can you revoke a SAS token immediately?
- Delete or modify the stored access policy used by that SAS.
2. Can a stored access policy be applied to individual blobs?
- No. Only containers, file shares, queues, and tables.
3. What happens if a SAS token has an expiry date but the policy also has an expiry date?
- The most restrictive expiry time is used.
4. How many stored access policies can exist per container?
- Up to 5
5. Why use stored access policies instead of ad-hoc SAS?
- Centralized management
- Easy revocation
- Security best practices
Summary
Stored access policies allow Azure administrators to:
- Manage SAS tokens in a centralized way
- Modify or revoke access instantly
- Avoid regenerating storage account keys
- Apply consistent security rules in production systems
For the AZ-104 exam, ensure you understand:
- What stored access policies are
- When to use them
- How they secure SAS tokens
- How to create, update, and delete them
- How they behave when combined with SAS permissions
Mastering this topic helps you manage secure access for applications, teams, automation systems, and external clients in any Azure Storage environment.
