First published on MSDN on Sep 22, 2016
Starting with SQL Server 2014 you can use SQL Server with Data Files in Microsoft Azure Blob Storage . This feature is very common when you work with SQL Server on Azure VM's, the steps to accomplish this are:
- Create an Azure VM and then Install SQL Server 2014 or above.
- Create a Storage Account
- Create a Container with Private access
- Create a SAS Key
- Create a database in SQL Server with database files in the Blob container
Check this Tutorial for more reference.
The result is a Database storing their files in a Blob Container 
As database administrator you are worried about database integrity, and for that reason, you scheduled a job or maintenance plan to check for the database integrity.
The first execution of the DBCC CHECKDB command runs without a problem.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'ADWorks2016'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Problem
After a week in the second execution of the DBCC CHECKDB you get the following error:
Msg 1823, Level 16, State 8, Line 32 A database snapshot cannot be created because it failed to start. Msg 5120, Level 16, State 155, Line 32 Unable to open the physical file "https://mssaalwaysonr1.blob.core.windows.net/mssql01adw/ADWData.mdf_MSSQL_DBCC9". Operating system error 80: "80(The file exists.)". Msg 7928, Level 16, State 1, Line 32 The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
Workaround
The workaround started by looking into the container: 
" DBCC CHECKDB uses an internal database snapshot for the transactional consistency needed to perform these checks." This Snapshot is deleted after the execution of the DBCC but in this case the Snapshot file was not deleted.
The following step, was to look the permissions for the SAS in the container Policy. ( Azure Storage Explorer ) 
Conclusion
The credential defined in SQL Server to access to the container uses a SAS (Shared Access Signature) and it has a Policy without the Delete permission.
Resolution
Grant the Delete Permission to the Access Policy associated with the SAS in the container and manually Delete the old Snapshot file. 
Now after the execution of the DBCC CHECKDB the Snapshot file is deleted automatically and there is no problem with the next execution.