- Blog link is deprecated, the connector is now native Docker, and apparently only File Share is supported indeed:

https://docs.docker.com/cloud/aci-integration/#using-azure-file-share-as-volumes-in-aci-containers

- AKS is a different product from ACI, and AKS supports Blob:

"Data volumes can use: Azure Disks, Azure Files, Azure NetApp Files, or Azure Blobs."

https://docs.microsoft.com/en-us/azure/aks/concepts-storage#volumes

"Microsoft updates, which Microsoft refers to as planned maintenance events, sometimes require that VMs be rebooted to complete the update." Planned maintenance refers to update domains, not fault domains. We need two update domains, answer is D.

Azure blob storage and Azure files are the one's for azure import/export service to securely transfer data to Azure by shipping the data from disk drives.

For setting up Azure File Sync between an on-premises server (Server1) and an Azure file share, you need to perform the following two actions in the Azure subscription:

First action: Create a Storage Sync Service

Explanation: The Storage Sync Service acts as the central service in Azure to manage synchronization between the Azure file share and your on-premises server.

Second action: Create a sync group

Explanation: A sync group defines the sync relationship between the Azure file share and the on-premises server. It includes the configuration of which files and directories to synchronize.

Incorrect actions:

• Install the Azure File Sync agent: This is done on the on-premises server (Server1), not in the Azure subscription.
• Run Server Registration: This step is also performed on the on-premises server after installing the agent, to register it with the Azure Storage Sync Service.

Example for clarification: Think of the Storage Sync Service as the "control center" in the cloud, and the sync group as the specific "job" you want to configure for syncing files. Installing the agent and registering the server are tasks to be done locally, like connecting a computer to a network after setting up the network infrastructure.

=> B is correct.

Box 1: No

A sync group must contain one cloud endpoint, which represents an Azure file share and one or more server endpoints.

Box 2: Yes

Data2 is located on Server2 which is registered to Sync1.

Box 3: No

Data3 is located on Server3 which is not registered to Sync1.

Reference:

https://docs.microsoft.com/en-us/azure/storage/file-sync/file-sync-deployment-guide?tabs=azure-portal%2Cproactive-portal#create-a-sync-group-and-a-%20cloud-endpoint

Storage accounts: Storage 3 only

Storage Account must be in the same Region as the Recovery Services Vault.

Log Analytics workspaces: Analytics1, Analytics2, and Analytics3

Set up one or more Log Analytics workspaces to store your Backup reporting data. The location and subscription where this Log Analytics workspace can be created is independent of the location and subscription where your Vaults exist.

Reference:

https://docs.microsoft.com/en-us/azure/backup/configure-reports#1-create-a-log-analytics-workspace-or-use-an-existing-one

Box 1: contoso104 only

Premium file shares are hosted in a special purpose storage account kind, called a FileStorage account.

Box 2: contoso101 and contos103 only

Object storage data tiering between hot, cool, and archive is supported in Blob Storage and General Purpose v2 (GPv2) accounts. General Purpose v1 (GPv1) accounts don't support tiering.

The archive tier supports only LRS, GRS, and RA-GRS.

Reference:

https://docs.microsoft.com/en-us/azure/storage/common/storage-account-overview

https://docs.microsoft.com/en-us/azure/storage/files/storage-how-to-create-premium-fileshare?tabs=azure-portal

https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-storage-tiers

Box 1: will have no access

The IP 193.77.134.1 does not have access on the SAS, because it is not matching the SAS requirements. IP is out of range.

Box 2: will have no access

The SAS token is not supported in mounting Azure File share currently, it just supports the Azure storage account key.

Since it is using "net use" where it uses SMB, the SMB (Server Message Broker) protocol does not support SAS. it still asks for username/password. Accordingly, it will give error wrong username/pass and will not provide access.

Reference:

https://docs.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1

https://docs.microsoft.com/en-us/azure/vs-azure-tools-storage-manage-with-storage-explorer?tabs=windows

https://docs.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows

https://docs.microsoft.com/en-us/answers/questions/40741/sas-key-for-unc-path.html

VMs can only be backed up in a single Recovery Services Vault. You have to stop the VM2 backup from the RSV1 first. Otherwise you won't able find the VM2 in RSV2.

Reference:

https://docs.microsoft.com/en-us/azure/backup/backup-azure-move-recovery-services-vault#must-preserve-previous-backed-up-data

https://docs.microsoft.com/en-in/azure/backup/backup-azure-vms-first-look-arm

General-purpose v2 storage accounts support the latest Azure Storage features and incorporate all of the functionality of general-purpose v1 and Blob storage accounts. General-purpose v2 accounts are recommended for most storage scenarios. General-purpose v2 accounts deliver the lowest per-gigabyte capacity prices for Azure Storage, as well as industry-competitive transaction prices. General-purpose v2 accounts support default account access tiers of hot or cool and blob level tiering between hot, cool, or archive.

Upgrading to a general-purpose v2 storage account from your general-purpose v1 or Blob storage accounts is straightforward. You can upgrade using the Azure portal, PowerShell, or Azure CLI. There is no downtime or risk of data loss associated with upgrading to a general-purpose v2 storage account. The account upgrade happens via a simple Azure Resource Manager operation that changes the account type.