"The specified container does not allow anonymous access, and no authentication information was provided." – Azure Blob Storage

When hardening an Azure Storage account, administrators often set the allowBlobPublicAccess property to false to prevent new containers from being configured for anonymous read access. However, the documentation indicates that this account‑level flag does not automatically change the access level of containers that were already made public.

The goal is to confirm whether disabling allowBlobPublicAccess also revokes anonymous access for blobs that reside in containers whose ACL was previously set to blob or container. If the flag alone is insufficient, what additional step is required to ensure those existing containers no longer serve unauthenticated requests, and what error response should be expected when attempting to read a blob from such a container after the change?

• Does setting allowBlobPublicAccess=false immediately block anonymous reads on existing public containers?
• If not, must the container ACL be explicitly updated to remove public access, and what command or API accomplishes that?
• What HTTP status code and error message are returned when a subsequent anonymous request targets a blob in a container that should now be private?