Globally unique resources that provide access to data management services and serve as the parent namespace for the services.
Hi ,
Thanks for reaching out to Microsoft Q&A.
No, the storage-account recover/undelete operation does not accept or preserve allowSharedKeyAccess, and it defaults to true, which causes a Deny policy requiring allowSharedKeyAccess - false to block the recovery.
Practical options now:
Preferred: Don’t rely on account-level soft-delete as your primary recovery method. Use data-level protections (blob soft delete, versioning, point-in-time restore where available) or replicate critical data to a second, policy-compliant account so you can restore data without recovering the original account.
Workaround: If full account recovery is mandatory and you can temporarily relax policy, create a narrowly scoped policy exemption for the recovery operation, restore the account, immediately set allowSharedKeyAccess = false, then remove the exemption. This is operationally supported but temporarily weakens the policy.
If continuous Deny enforcement is required: There is currently no supported account-recovery path that meets that constraint; you must use an independent data-recovery strategy.
Better open a support ticket or product feedback request asking that the recover API preserve or accept security properties (for example, allowSharedKeyAccess) during recovery. The current behavior creates a policy deadlock: an originally compliant account cannot be recovered without temporarily weakening the policy.
Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.