A storage account request can fail even when the caller holds the correct data-plane role. The request may arrive from a network that the account does not permit, use the wrong endpoint, or present a shared access signature that has expired. Microsoft AZ-104<\/a> administrators need a layered diagnosis: network reachability, firewall\/public endpoint settings, private or service endpoint path, authentication type, authorization scope, and the exact operation.<\/p>\n Imagine an application writing reports to a Blob container while administrators access the same account from an approved management workstation. The application should normally use an identity-based mechanism where supported; a third-party downloader might instead receive a narrowly scoped, short-lived SAS. Neither caller should require the storage account’s broad access keys in a configuration file. State the exception if a legacy integration truly cannot use an identity.<\/p>\n Valid Entra authorization or SAS delegation<\/a> does not override an account network rule. A caller may possess the correct token and still be blocked by the storage firewall or the selected private endpoint. Diagnose source-network rules, account-key custody, SAS expiry and stored access policies as separate controls; revoking one does not necessarily revoke the others.<\/p>\n A storage account can have a public endpoint yet restrict inbound sources using network controls. A private endpoint places a private IP representation of the service into a virtual network, and correct DNS must route clients to it. These are different architectures. Do not assume a firewall rule and a private endpoint provide identical connectivity or that turning off public network access automatically configures internal DNS.<\/p>\n Create a test storage account, limit its network access, then attempt a request from an allowed network and a denied one. Inspect actual source path and endpoint, not only whether the portal can list the account. Azure portal management-plane visibility can succeed when direct blob data access fails; administrators must distinguish listing a resource’s configuration from downloading an object.<\/p>\n Private endpoint connectivity<\/a> depends on both DNS resolution and routing. A hostname that still resolves to the public endpoint can explain a network rejection even when an authorized identity and private endpoint both exist. Record DNS resolution, route, effective security controls, and the storage firewall response.<\/p>\n Storage account keys are powerful shared secrets and should not be the default authentication path for modern long-lived workloads. Exposure can allow broad data actions depending on service and configuration. Prefer Microsoft Entra authorization for supported applications, keep required keys in an approved secret store, restrict who can list or regenerate them, and monitor administrative key operations.<\/p>\n Rotating keys can disrupt clients if they all use the same key. A controlled migration uses an inventory of consumers and, when applicable, a staged rotation between key slots, with tests that confirm each application has moved. Do not blindly regenerate the only key a critical workload knows. Any automation should have approved timing, rollback and operational ownership.<\/p>\n Where the service permits disabling Shared Key authorization, evaluate that setting only after checking integration compatibility. It can break existing account\/service SAS patterns while leaving appropriate identity-based or user-delegation access available. Record the difference in the change plan and avoid saying that all SAS mechanisms universally require a shared account key.<\/p>\n A shared access signature grants delegated permissions for a particular resource or account scope. It is not a user identity and should not be copied into logs, support messages, or permanent documentation. Define the minimum read\/write\/list\/delete permissions, target resource, protocol, validity period, and any applicable IP restriction. A SAS without a clear expiry or purpose is difficult to govern.<\/p>\n Distinguish user delegation SAS for Blob Storage from service SAS and account SAS that depend on the account key. Check service and API support and choose the mechanism appropriate to the workload. Signing a SAS does not grant access if the enclosing account’s network restrictions prevent the request. The final authorization path combines token validity, resource permission and network acceptance.<\/p>\n Test a read-only link that can retrieve one object but cannot delete it or list unrelated containers. Repeat after expiry and with a malformed signature. A denied request should be recorded as an expected security outcome. Do not infer that disabling one type of SAS invalidates every possible account-level data access method.<\/p>\n A stored access policy can provide centrally managed constraints for supported service SAS resource types, enabling certain permission and expiry changes or revocation by changing the policy. It is not supported in the same way for every type of SAS, and it does not turn an account SAS into a user-delegation credential. Consult the relevant service reference before designing a revocation workflow.<\/p>\n In a lab, associate an appropriate service SAS with a stored access policy on a supported container or share. Verify a legitimate read, then modify or remove the policy and observe the access effect after applicable propagation. Track the policy identifier and token generation time so a debugging session can distinguish a stale SAS from an account network failure.<\/p>\n Do not treat the presence of a stored access policy as an excuse to issue excessive permissions. A well-defined token still has a narrow purpose, and revoking one policy may affect many clients using it. Inventory consumers before making changes that could interrupt production.<\/p>\n Start with the failure’s actual error code and request identity. For HTTP 403 or a client authorization error, inspect account firewall or private endpoint path, the specific URL and service endpoint, selected authentication type, RBAC role and scope, token clock\/expiry, and requested operation. A role that permits management actions may not include the corresponding data action.<\/p>\n For intermittent failures, compare the failing client’s network environment and credential refresh behavior with the successful client. A desktop tool may use an interactive Entra sign-in while an automated script uses a cached shared key. Two tools pointing at the same storage account can therefore have different security paths and logs.<\/p>\n Use Microsoft’s storage network security<\/a> documentation to test the selected endpoint pattern. Note service-specific behaviors and changing portal labels instead of relying on a timeless screenshot. Write the precise diagnostic question and acceptable result for each layer.<\/p>\n Create a disposable storage account and container, one approved identity, and one external read-only consumer scenario. Configure an identity-based data role for the application. Restrict network access, validate DNS where a private endpoint is selected, then test an allowed upload and a network-denied attempt. Document the difference between management and data access results.<\/p>\n Generate a short-lived read-only SAS for one object, test a forbidden delete, and test the token’s expiry. If the token uses a stored access policy on a supported service SAS, test the approved policy-change behavior. Keep the SAS out of logs or shared reports. Treat the test token as a secret throughout its short lifecycle.<\/p>\n Before rotating an account key, identify every consumer that still depends on that secret and determine which can move to Microsoft Entra authentication or a user delegation SAS. In a nonproduction test, make one access method invalid and verify the expected error, network path, fallback condition and owner. Do not invalidate production credentials just to demonstrate the concept. A defensible rotation plan shows the consumer inventory, permitted transition order, verification and a rollback path.<\/p>\n Create a table with columns for endpoint hostname, resolved destination, source network, authentication scheme, role or SAS scope, requested operation and server error code. A caller with the right data role can still be refused by the account firewall. A caller with network connectivity can be denied because its SAS is expired or lacks permission to delete. A caller with a management-plane Contributor role can often inspect account settings while still lacking Blob data actions.<\/p>\n Use two known clients: one from an approved subnet and one outside it. Verify both resolve the account endpoint, then run the same supported operation under the same narrow credential. If only the source-network condition changes the result, diagnose firewall, private endpoint or route. If identical network paths differ by identity, inspect the data role or SAS signature. A public endpoint’s presence does not mean all public clients are permitted.<\/p>\n List every legitimate consumer of a shared account key and how it retrieves that key before initiating rotation. In a controlled test, move a disposable client to an alternative working key or identity, prove it still performs the intended read and only then plan regeneration. A key rotation performed without a consumer inventory can break unrelated workloads whose configuration was never migrated.<\/p>\n For a supported service SAS with a stored access policy, demonstrate the effect of updating or removing the referenced policy and checking the resulting request after normal propagation. Do not claim that stored access policies govern every SAS type; account SAS and user-delegation SAS have different constraints. The data protection controls<\/a> help plan recovery from mistakes after the authentication design is fixed.<\/p>\n","protected":false},"excerpt":{"rendered":" Troubleshoot Azure Storage network\/firewall access separately from keys, Entra data roles, SAS expiration, and stored access-policy revocation.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[341,2],"tags":[],"et_vendor":[],"et_program":[],"et_certification":[],"et_exam":[],"et_topic":[],"class_list":["post-3993","post","type-post","status-publish","format-standard","hentry","category-microsoft-az-104","category-post"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/posts\/3993","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/comments?post=3993"}],"version-history":[{"count":7,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/posts\/3993\/revisions"}],"predecessor-version":[{"id":4960,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/posts\/3993\/revisions\/4960"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/media?parent=3993"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/categories?post=3993"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/tags?post=3993"},{"taxonomy":"et_vendor","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_vendor?post=3993"},{"taxonomy":"et_program","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_program?post=3993"},{"taxonomy":"et_certification","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_certification?post=3993"},{"taxonomy":"et_exam","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_exam?post=3993"},{"taxonomy":"et_topic","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_topic?post=3993"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Choose a public endpoint or private access deliberately<\/h2>\n
Protect account keys and understand their scope<\/h2>\n
Scope SAS by purpose, resource, permission and expiry<\/h2>\n
Stored access policies are useful but limited<\/h2>\n
Build an authorization troubleshooting table<\/h2>\n
Complete a reversible storage access lab<\/h2>\n
Classify a storage 403 before making changes<\/h2>\n
Plan a credential rotation and revocation rehearsal<\/h2>\n