Technical Lab: Manage data by using Azure Storage Explorer and AzCopy
Questions
Question 1 — Multiple Choice
You need to transfer 10 TB of data from one Blob container to another container in a different storage account, within the same region. The operation must be automated, run in the background, and completed with the highest possible performance.
Which approach best meets these requirements?
A) Use Azure Storage Explorer with copy and paste operation between containers, as it automatically manages large transfers.
B) Use azcopy copy with the --recursive flag, as AzCopy performs server-side transfers without routing data through the local machine.
C) Use azcopy sync with the --delete-destination flag, as this option is more efficient for large volumes than the copy command.
D) Use Azure Storage Explorer with batch upload option, as it utilizes multiple threads to maximize bandwidth.
Question 2 — Technical Scenario
An administrator executes the following command:
azcopy copy 'https://source.blob.core.windows.net/container1/reports' \
'https://destination.blob.core.windows.net/container2/reports' \
--recursive
The command fails with an authorization error. The administrator confirmed that RBAC permissions are correct in both accounts. What is the most likely cause of the failure?
A) AzCopy doesn't support direct copying between two storage accounts; data needs to pass through the local machine.
B) The --recursive flag is not compatible with transfers between different accounts.
C) AzCopy is not authenticated to access the accounts; it's necessary to run azcopy login or provide SAS tokens in the URLs.
D) The destination container doesn't exist and must be created manually before executing the command.
Question 3 — True or False
The azcopy sync command replicates the source directory state to the destination by checking only files with more recent modification dates, and never removes files at the destination that no longer exist in the source, regardless of the flags used.
Question 4 — Technical Scenario
A team uses Azure Storage Explorer connected to a subscription via Microsoft Entra ID account. An analyst reports that they can view containers, but when trying to upload a file receives the error "This request is not authorized to perform this operation".
The administrator verifies that the analyst has the Storage Blob Data Reader role assigned at the storage account level.
What is the appropriate fix?
A) Reassign the Storage Blob Data Reader role at the container level instead of the account level.
B) Assign the Storage Blob Data Contributor role or higher, as the current role grants only read access.
C) Generate an account-level SAS key and configure it in Storage Explorer, as Entra ID doesn't support upload via Storage Explorer.
D) Assign the Owner role at the subscription level, as write operations on Blob require subscription-level permissions.
Question 5 — Multiple Choice
When using Azure Storage Explorer, an administrator wants to connect to a storage account in an isolated environment where Microsoft Entra ID login is not available. Which connection method is most appropriate?
A) Connection via account access key, providing the account name and key in the connection wizard.
B) Connection via implicit OAuth 2.0, manually configured in Storage Explorer's advanced options.
C) Connection via X.509 certificate associated with the Microsoft Entra ID tenant of the account.
D) Connection via public endpoint only with the account name, without need for additional credentials.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The azcopy copy with --recursive performs server-side transfers between Azure storage accounts, meaning data doesn't pass through the local machine. This is crucial for performance with large volumes like 10 TB.
Storage Explorer (alternatives A and D) routes data through the operator's machine, making it unsuitable for large-scale automation. Alternative C confuses the commands: azcopy sync serves for incremental synchronization, not for high-performance initial transfers, and the --delete-destination flag removes files at the destination that don't exist at the source, which can be destructive without clear intent.
Answer Key — Question 2
Answer: C
AzCopy requires explicit authentication. Without azcopy login (which uses Microsoft Entra ID flow) or SAS tokens embedded in URLs, any operation returns authorization error, even if RBAC permissions are correctly configured in the portal.
Alternative A is false: AzCopy supports direct copying between accounts via server-side copy. Alternative B is false: --recursive is fully compatible with transfers between accounts. Alternative D might even be true in some scenarios, but is not the cause of the authorization error, which precedes any destination verification.
Answer Key — Question 3
False
The azcopy sync can indeed remove files at the destination when the --delete-destination=true flag is used. Without this flag, the default behavior is not to delete extra files at the destination. The statement is false because it uses the term "never removes... regardless of flags", which contradicts the actual command behavior. This is a critical security point: executing sync with --delete-destination=true in production without review can cause unintentional data loss.
Answer Key — Question 4
Answer: B
The Storage Blob Data Reader role grants only read permissions (GET, LIST). Write operations require at minimum the Storage Blob Data Contributor role, which includes PUT, DELETE, and CREATE.
Alternative A doesn't solve the problem: the role remains read-only regardless of scope. Alternative C is incorrect: Microsoft Entra ID is fully supported for upload in Storage Explorer. Alternative D represents an over-provisioning practice and is not the correct approach in a least-privilege model.
Answer Key — Question 5
Answer: A
The account access key is the Storage Explorer authentication method that doesn't depend on Microsoft Entra ID. It provides complete access to the account and is available even in isolated environments or without tenant connectivity.
Alternative B is invalid: Storage Explorer doesn't expose manual configuration of implicit OAuth. Alternative C is incorrect: X.509 certificates are not an available connection method in Storage Explorer for storage accounts. Alternative D is false: Storage Explorer always requires some form of credential; there's no authenticated access using only the account name without additional credentials.