Azure Storage security is a question of identity, network reach and the exact permissions a client needs. The AZ-104 exam expects administrators to move beyond the idea that a storage account is either public or private. A workload can authenticate with Microsoft Entra ID, use a shared access signature for delegated access, rely on account keys, or be constrained by network rules. Each mechanism solves a different problem and carries a different operational risk.
Shared access signatures are especially important because they are convenient and easy to misuse. A SAS is effectively a delegated authorization token. Whoever possesses a valid SAS can use the permissions it grants until the token expires or is otherwise invalidated. That makes scope, expiry, protocol and signing method part of the security design rather than minor configuration details.
Prefer identity-based authorization when the workload supports it
For Azure resources and modern applications, Microsoft Entra ID with Azure RBAC is usually easier to govern than distributing storage account keys. A managed identity can receive a data-plane role and authenticate without embedding a long-lived secret in code or configuration. Administrators can then review and revoke the role assignment through the normal identity model.
This approach separates identity from the storage account’s master credentials. It also supports least privilege more naturally because a principal can receive only the role and scope it needs. The broader Microsoft Azure infrastructure certifications path repeatedly returns to the same principle: prefer identities and scoped authorization over shared secrets where the service supports them.
That does not make SAS unnecessary. SAS remains useful when a client needs temporary delegated access without receiving a full Azure identity or direct role assignment. The key is to use it deliberately rather than as the default answer for every storage-access scenario.
Understand the three SAS types before choosing one
A user delegation SAS is authorized through Microsoft Entra credentials and a user delegation key. Microsoft recommends this form when possible because it avoids signing the token with the storage account key. It is particularly useful for Blob Storage scenarios in which a trusted application needs to delegate bounded access to another client.
A service SAS is signed with the storage account key and delegates access within one storage service. An account SAS is also signed with the account key but can grant broader capabilities across storage services and service-level operations. Because possession of the account key allows powerful delegation, protecting those keys is a major administrative responsibility.
The exam decision is not simply “which SAS exists.” It is “what should the client be able to do, for how long, against which resources, and what identity or key should authorize that delegation?” A narrow user delegation SAS is often preferable to a broad account SAS when both could technically satisfy the task.
Design the token around least privilege
A SAS can constrain permissions such as read, write or delete; the resource being accessed; the validity window; permitted protocol; and in some cases the source IP range. These are security controls, not decorative options. A token created for a one-hour upload workflow should not remain valid for a month and should not include read or delete permissions unless the workflow needs them.
Short validity reduces the window of exposure if a token leaks. HTTPS-only access reduces the risk of interception. Narrow resource scope limits blast radius. Administrators should also avoid logging SAS URLs because the token is commonly embedded in the query string and can be exposed through diagnostics, browser history or copied messages.
Think of a SAS as a bearer credential. The client presenting it generally does not have to prove that it is the person to whom the token was originally sent. Operational handling therefore matters as much as token construction.
Stored access policies add control to service SAS tokens
A stored access policy is defined on a container, file share, queue or table and can supply constraints for service SAS tokens associated with it. This gives administrators a server-side control point for changing expiry or permissions and, importantly, for revoking related service SAS access by changing or removing the policy.
Stored access policies do not apply to user delegation SAS or account SAS. That distinction matters because revocation options differ by SAS type. An ad hoc token without a stored policy may remain usable until expiry unless the signing credential or other underlying access is changed. Administrators should choose the delegation model with its lifecycle in mind.
This is a good example of how AZ-104 combines configuration and operations. Generating a token is the easy part. Designing how access can later be reduced or revoked is the administrator’s responsibility.
Storage firewalls and virtual-network rules control network reach
Authorization does not have to be the only boundary. Storage accounts can restrict network access so that valid credentials are accepted only from approved network paths. Firewall rules, virtual-network integration and private connectivity can reduce exposure and make accidental public access less likely.
Network restriction and identity authorization are complementary. A workload may have the correct data-plane role and still be unable to connect because the storage firewall blocks its network path. Conversely, being on an allowed network does not automatically grant data access. Candidates should check both layers when troubleshooting.
This layered view connects storage administration with the larger cloud architecture certification domain. Secure cloud services are rarely protected by a single switch; identity, network boundaries, encryption and operational monitoring work together.
Account keys are powerful and should be treated accordingly
Storage account access keys provide broad authority and are used to sign service and account SAS tokens. They are convenient for legacy integrations, but that convenience creates risk because applications that possess the key can potentially gain extensive access. If keys are used, administrators need a rotation plan and must understand the impact on clients that depend on them.
Regenerating a key can invalidate clients that still use it, which is why storage accounts provide multiple keys to support rotation patterns. A common operational approach is to move clients to the secondary key, regenerate the primary, move clients back and then regenerate the secondary. The exact process must account for every dependency before credentials are changed.
The better architectural question is whether a key is needed at all. Managed identities, Entra authorization and user delegation SAS can often reduce dependence on shared keys and simplify access review.
Azure Files and Blob Storage have different authorization details
Both Azure Files and Blob Storage live under Azure Storage, but administrators should not assume every authentication feature behaves identically across services and protocols. Azure Files can participate in identity-based access patterns for file shares, while Blob Storage commonly uses Entra data roles and user delegation SAS. Protocol choice and client capability influence what is possible.
AZ-104 scenarios often describe a requirement in business language: give a partner temporary read access, allow an Azure workload to write without stored credentials, or restrict a share to a known network. Translate that requirement into identity, scope, duration and network constraints before selecting the mechanism.
This prevents a common exam mistake: choosing the technically possible method that is much broader than necessary. The secure solution is usually the one that gives the client exactly enough access for the task and makes revocation manageable.
Troubleshoot storage access from the outside in
When a client receives an authorization failure, start by determining how it is authenticating. If it uses Entra ID, check the assigned data-plane role and scope. If it uses SAS, verify expiry, permissions, resource scope, protocol and signature. If it uses an account key, confirm that the current key is being used.
Then inspect the network path. Storage firewall rules, private endpoints, DNS resolution and virtual-network configuration can prevent a request from reaching the service even when credentials are valid. Finally, distinguish management-plane permission from data-plane permission. Being able to configure a storage account does not automatically mean the same identity can read every blob inside it.
The Azure administrator role is largely about making these cross-layer distinctions quickly. Storage security is a strong example because identity, delegation, networking and operations all meet at the same service boundary.
Use a simple decision sequence on exam day
First ask whether the caller can use an Azure identity. If yes, prefer scoped identity-based access where practical. If temporary delegation is required, determine which SAS type fits the service and choose the narrowest permissions and shortest practical lifetime. If a service SAS needs centralized revocation, consider a stored access policy. If the problem is exposure rather than identity, look at storage network rules and private connectivity.
That sequence keeps the focus on security intent instead of memorizing portal screens. AZ-104 storage questions reward administrators who understand not only how to grant access, but also how to keep that access limited, observable and reversible.
Separate anonymous access, Shared Key and delegated access
Storage security becomes clearer when administrators distinguish anonymous access from authenticated access. Some Blob Storage scenarios can be configured to allow anonymous read access, but that is a deliberate exposure choice and should not be confused with a SAS. A SAS still represents authenticated delegated authorization because the token is cryptographically signed and constrained by its permissions and validity.
Shared Key authorization is another separate concept. It uses the storage account key directly or indirectly to authorize requests. Because the key has broad power, organizations that can use Microsoft Entra authorization often prefer to reduce Shared Key dependence. That makes credential rotation easier to reason about and avoids distributing a master secret to many applications.
When reading an AZ-104 scenario, identify which model is actually being requested. Publicly readable content, identity-based application access and temporary delegated access have different solutions. Treating all three as variations of “storage permissions” can lead to an answer that works technically but violates the security requirement.