This chapter covers AzCopy and Azure Storage Explorer, two essential tools for transferring data to and from Azure Storage. On the AZ-104 exam, approximately 5-8% of questions relate to data transfer tools, including AzCopy, Storage Explorer, and other utilities like Azure Data Box and Azure Import/Export. Understanding when to use each tool, their capabilities, and their command syntax is critical for both the exam and real-world administration. This chapter provides a deep dive into AzCopy's command-line operations, Storage Explorer's graphical interface, and how they integrate with Azure Storage features like SAS tokens, Azure AD authentication, and blob lifecycle management.
Jump to a section
Think of Azure Storage as a massive overseas warehouse complex. AzCopy is like a specialized cargo ship that moves containers between your local warehouse (on-premises) and the overseas warehouse (Azure Storage). The ship is fast, can carry huge loads, and operates via a precise manifest (command-line parameters). It can copy, sync, and even schedule transfers. Storage Explorer, on the other hand, is like a mobile warehouse crane with a glass cabin. It gives you a visual dashboard to see every shelf, box, and item inside the warehouse. You can drag-and-drop files, view metadata, and manage access policies. The crane operator (you) can see exactly what's where and make small adjustments. But for moving thousands of containers across the ocean, the crane is too slow and manual—you need AzCopy. Both tools use the same underlying storage APIs, just like both the ship and crane use standard shipping containers. AzCopy is for bulk, automated, scriptable transfers; Storage Explorer is for interactive exploration and small-scale management.
What Are AzCopy and Azure Storage Explorer?
AzCopy is a command-line utility designed for high-performance, scriptable data transfers to and from Azure Blob Storage, Azure Files, and Azure Table Storage. It is optimized for throughput, supporting parallel operations and automatic retries. Storage Explorer is a graphical tool that provides a visual interface for managing Azure Storage resources across multiple subscriptions and tenants. Both tools are free and can be used on Windows, macOS, and Linux.
How AzCopy Works Internally
AzCopy uses the Azure Storage REST API to perform operations. When you run a command, AzCopy: 1. Parses the source and destination URLs, including any SAS tokens or Azure AD authentication. 2. If using Azure AD, obtains an OAuth 2.0 token from Azure AD (requires proper RBAC roles like 'Storage Blob Data Contributor'). 3. For uploads, splits large files into blocks (default block size: 8 MiB for Blob Storage, but adjustable). 4. Initiates multiple concurrent connections (default: 8 for uploads, 64 for downloads) to send blocks in parallel. 5. Maintains a journal file (by default in $HOME/.azcopy/) to track progress. If the transfer is interrupted, AzCopy can resume from the last completed block. 6. For sync operations, compares file hashes (MD5 or CRC64) to determine which files need to be copied. 7. Optionally logs errors and failed transfers to a log file.
Key Components and Defaults
Block Size: Default 8 MiB for Blob Storage. Can be set via --block-size-mb. For files > 256 MiB, AzCopy automatically increases block size.
Concurrency: --concurrency flag. Default 8 for uploads, 64 for downloads. Higher values increase throughput but consume more CPU/memory.
Journal: Stored in %USERPROFILE%\.azcopy\ (Windows) or $HOME/.azcopy/ (Linux/macOS). Disable with --no-resume.
Log Level: --log-level (INFO, WARNING, ERROR, NONE). Default INFO.
Transfer Type: --block-blob, --page-blob, --append-blob. Default is block blob.
Authentication: SAS token appended to URL, or Azure AD via --login.
Sync Mode: azcopy sync uses last modified time and MD5 hash by default.
Configuration and Verification Commands
#### Install AzCopy
- Windows: Download .exe, add to PATH.
- Linux: wget -O azcopy.tar.gz https://aka.ms/downloadazcopy-v10-linux && tar -xzf azcopy.tar.gz && sudo cp ./azcopy_linux_amd64_*/azcopy /usr/bin/
- macOS: brew install azcopy
#### Common Commands
Copy a single file to a container:
azcopy copy "C:\local\file.txt" "https://mystorageaccount.blob.core.windows.net/mycontainer/file.txt?<SAS>"Copy entire directory recursively:
azcopy copy "C:\local\folder" "https://mystorageaccount.blob.core.windows.net/mycontainer/folder?<SAS>" --recursiveSync a local folder to a container (bidirectional):
azcopy sync "C:\local\folder" "https://mystorageaccount.blob.core.windows.net/mycontainer/folder?<SAS>" --recursiveCopy between storage accounts:
azcopy copy "https://sourceaccount.blob.core.windows.net/container1?<SAS1>" "https://destaccount.blob.core.windows.net/container2?<SAS2>" --recursiveUse Azure AD authentication:
azcopy login
azcopy copy "C:\local\file.txt" "https://mystorageaccount.blob.core.windows.net/mycontainer/file.txt"List contents of a container:
azcopy list "https://mystorageaccount.blob.core.windows.net/mycontainer?<SAS>"How Storage Explorer Works
Storage Explorer connects to Azure via:
Azure AD authentication (interactive or device code)
Storage account name and key
Connection string
SAS URI
Once connected, it displays storage accounts in a tree view. You can:
Browse containers, blobs, file shares, queues, and tables.
Upload/download files via drag-and-drop.
Manage access policies (SAS, stored access policies).
Copy blobs between containers/accounts.
View and edit blob metadata and properties.
Manage Azure Data Lake Storage Gen2 (hierarchical namespace).
Interaction with Related Technologies
SAS Tokens: Both tools support SAS for fine-grained access without exposing account keys.
Azure AD RBAC: AzCopy and Storage Explorer can use Azure AD authentication. Required RBAC roles: 'Storage Blob Data Contributor' for read/write, 'Storage Blob Data Reader' for read-only.
Azure Data Box: For offline transfers > 10 TB, Data Box is preferred over AzCopy due to network bandwidth constraints.
Azure Import/Export Service: For physical disk shipping, not covered by AzCopy.
Azure File Sync: For hybrid file shares, not AzCopy.
Lifecycle Management: AzCopy can be used to move blobs between tiers (Hot, Cool, Archive) by copying to a different tier.
Performance Optimization
Use --concurrency to increase parallelism (up to 300 for high-bandwidth networks).
For large files, increase --block-size-mb to reduce the number of blocks.
Use --from-to to specify source and destination types (e.g., LocalBlob, BlobBlob).
For cross-region transfers, consider using Azure Content Delivery Network or Azure Front Door.
Error Handling
AzCopy retries failed transfers up to 3 times by default (--retry-count).
Use --overwrite to control overwrite behavior (true, false, ifSourceNewer, prompt).
Check journal files for resume capability.
Use --cap-mbps to limit bandwidth usage.
Security Considerations
Avoid hardcoding SAS tokens in scripts; use environment variables or managed identities.
For Azure AD, ensure the service principal has the correct RBAC role.
Use --put-md5 to calculate and store MD5 hash for integrity checks.
For sensitive data, consider Azure Private Endpoint to keep traffic within Microsoft backbone.
Integration with Azure Automation
AzCopy can be used in:
Azure DevOps pipelines (using Azure CLI or AzCopy task).
Azure Automation runbooks (PowerShell or Python).
Scheduled tasks or cron jobs.
Azure Functions (via custom bindings).
Install AzCopy on Local Machine
Download the latest version of AzCopy from the official Microsoft website. For Windows, run the executable and add it to the system PATH. For Linux, use wget to download the tarball, extract it, and copy the binary to /usr/bin. For macOS, use Homebrew. Verify installation by running `azcopy --version`. The current version as of 2025 is 10.x. Ensure the system has internet access to Azure endpoints.
Authenticate to Azure Storage
Decide authentication method: SAS token (appended to URL) or Azure AD. For Azure AD, run `azcopy login` which opens a browser for interactive login, or use `azcopy login --service-principal --application-id <app-id> --tenant-id <tenant-id>` for service principals. The principal must have 'Storage Blob Data Contributor' role on the target container. For SAS, generate the token via Azure portal, Storage Explorer, or Azure CLI: `az storage container generate-sas --account-name <account> --name <container> --permissions rwdl --expiry <date>`.
Prepare Source and Destination Paths
Construct the source and destination URLs. For local paths, use absolute or relative paths. For Azure Blob Storage, use the format: `https://<account>.blob.core.windows.net/<container>/<blob>?<SAS>`. For Azure Files: `https://<account>.file.core.windows.net/<share>/<path>?<SAS>`. For Azure Table: `https://<account>.table.core.windows.net/<table>?<SAS>`. Ensure the SAS token has the required permissions (read for source, write for destination). Use environment variables to store SAS tokens securely.
Execute AzCopy Transfer Command
Run `azcopy copy` with source and destination. Add `--recursive` for directories. For sync, use `azcopy sync` which compares last modified times and MD5 hashes. Monitor progress in the terminal. AzCopy displays transfer rate, number of files, and errors. Use `--log-level=ERROR` to suppress info. For large transfers, consider using `--cap-mbps` to limit bandwidth. Example: `azcopy copy "C:\data" "https://mystorage.blob.core.windows.net/backup?<SAS>" --recursive --cap-mbps 100`.
Verify Transfer and Handle Errors
After completion, check the exit code (0 for success). Use `azcopy list` to verify files in the destination. Review log files in `%USERPROFILE%\.azcopy\` (Windows) or `$HOME/.azcopy/` (Linux/macOS). If errors occurred, check the log for specific failures (e.g., permission denied, network timeout). For failed transfers, AzCopy can resume using the journal file if the same command is run again. Use `--overwrite ifSourceNewer` to avoid overwriting newer files.
Enterprise Scenario 1: Migrating On-Premises File Server to Azure Blob Storage
A company with 50 TB of on-premises file shares needs to migrate to Azure Blob Storage for archival. They choose AzCopy because it supports parallel transfers and can resume after interruptions. The administrator creates a SAS token with write permissions for the target container. They run AzCopy from a Windows Server with high-bandwidth connection (1 Gbps). Using --concurrency 64 and --block-size-mb 16, they achieve ~800 Mbps throughput. The migration completes in 6 days with 3 interruptions due to network issues, each time AzCopy resumes from the journal. Post-migration, they use azcopy sync weekly to copy incremental changes. A common mistake is forgetting to set --recursive, causing only top-level files to be copied. Also, they initially used account key in the script, which posed a security risk; they switched to SAS tokens stored in Azure Key Vault.
Enterprise Scenario 2: Cross-Region Replication for Disaster Recovery
A financial services firm needs to replicate blob containers from US East to US West for DR. They use AzCopy in a scheduled Azure Automation runbook. The runbook uses a managed identity with 'Storage Blob Data Contributor' on both accounts. They use azcopy copy with --from-to BlobBlob and --overwrite ifSourceNewer. The transfer runs nightly. Performance is limited by the source account's egress limits (default 60 Gbps per account). To avoid throttling, they spread across multiple source containers. They also set --cap-mbps 500 to avoid saturating the VPN. A misconfiguration occurred when the destination SAS token expired, causing failures; they now use Azure AD authentication to avoid token expiry.
Enterprise Scenario 3: Storage Explorer for Ad-Hoc Management
A DevOps team uses Storage Explorer for quick troubleshooting. They connect to multiple subscriptions via Azure AD. When a developer accidentally deletes a blob, they use Storage Explorer to restore it from the soft delete container (if enabled). They also use it to generate SAS tokens for temporary access. Storage Explorer is not suitable for bulk operations; they once tried to upload 10,000 files via drag-and-drop, which caused the UI to freeze. They now use AzCopy for any transfer > 100 files. A common issue is that Storage Explorer does not support Azure Data Lake Gen2's ACL management fully; they use Azure CLI for that.
What AZ-104 Tests on AzCopy and Storage Explorer
The exam objectives under 'Manage Azure Storage' (2.4) include: 'Configure Azure Storage tools' and 'Use AzCopy and Storage Explorer'. Specific tested items:
- AzCopy authentication: When to use SAS vs Azure AD. Exam expects you to know that Azure AD requires RBAC roles (e.g., 'Storage Blob Data Contributor').
- AzCopy copy vs sync: Sync compares timestamps and hashes; copy does not.
- AzCopy resume capability: Uses journal files. Exam may ask about --no-resume flag.
- Storage Explorer connection methods: Account key, connection string, SAS, Azure AD.
- Supported services: Blob, File, Queue, Table, and Data Lake Gen2.
- Performance parameters: --concurrency, --block-size-mb, --cap-mbps.
Common Wrong Answers
'AzCopy can only use SAS tokens': Wrong. It also supports Azure AD (via azcopy login) and anonymous access (though rarely used).
'Storage Explorer can be used for automated transfers': Wrong. It is GUI-only; automation requires AzCopy or Azure CLI.
'AzCopy sync always deletes files at the destination that don't exist at the source': Wrong. By default, sync does not delete; you need --delete-destination flag.
'AzCopy supports Azure Table Storage': True, but many candidates think it does not. It does, with limitations (no sync for tables).
'Storage Explorer requires a storage account key for every connection': Wrong. It supports Azure AD, SAS, and connection strings.
Specific Numbers and Values
Default block size: 8 MiB.
Default concurrency: 8 (uploads), 64 (downloads).
Max concurrency: 300.
Default retry count: 3.
Journal location: %USERPROFILE%\.azcopy\ (Windows) or $HOME/.azcopy/ (Linux/macOS).
Storage Explorer supports Azure Government and Azure China clouds.
Edge Cases
AzCopy and Azure Data Lake Gen2: Use --hierarchical-namespace flag.
AzCopy and Azure Files: Requires SMB protocol for some operations; AzCopy uses REST API, so it can't preserve NTFS permissions.
Storage Explorer and Managed Disks: Cannot manage disks; only blob/page blobs.
AzCopy and large number of small files: Use --include-pattern and --exclude-pattern to filter.
How to Eliminate Wrong Answers
If a question asks about 'automated recurring transfers', AzCopy is the answer, not Storage Explorer.
If a question mentions 'interactive browsing', Storage Explorer is the answer.
For 'resumable transfers', look for 'journal' or '--no-resume'.
For 'authentication without account key', look for Azure AD or SAS.
Pay attention to 'sync' vs 'copy' — sync uses timestamps and hashes, copy does not.
AzCopy is a CLI tool for high-performance, scriptable data transfers to/from Azure Storage.
Storage Explorer is a GUI tool for interactive management of Azure Storage resources.
AzCopy supports SAS tokens and Azure AD authentication; Storage Explorer supports multiple connection methods.
Use `azcopy copy` for one-time transfers and `azcopy sync` for incremental synchronization.
AzCopy default block size is 8 MiB; default concurrency is 8 for uploads, 64 for downloads.
AzCopy journal files enable resuming interrupted transfers; located in $HOME/.azcopy/.
Storage Explorer cannot automate transfers; use AzCopy for automation.
Both tools support Blob, File, Queue, Table, and Data Lake Gen2 storage.
For Azure AD authentication, the principal needs 'Storage Blob Data Contributor' or equivalent RBAC role.
AzCopy can copy between storage accounts using source and destination URLs with SAS or Azure AD.
These come up on the exam all the time. Here's how to tell them apart.
AzCopy
Command-line tool for automated, scriptable transfers.
Supports high-performance parallel transfers with configurable concurrency.
Can be used in CI/CD pipelines and scheduled tasks.
Supports resume via journal files.
Best for bulk transfers (>100 files) and recurring sync.
Storage Explorer
Graphical user interface for interactive exploration.
Limited to manual operations; no scripting support.
Ideal for browsing, small uploads/downloads, and managing access policies.
No built-in resume; transfers restart if interrupted.
Best for ad-hoc management, troubleshooting, and visualizing storage.
Mistake
AzCopy can only be used with Blob Storage.
Correct
AzCopy supports Azure Blob Storage, Azure Files, Azure Table Storage, and Azure Data Lake Storage Gen2. For Azure Files, it uses the REST API, not SMB.
Mistake
Storage Explorer requires a storage account key to connect.
Correct
Storage Explorer supports multiple authentication methods: Azure AD, account key, SAS token, and connection string. You can connect without the key by using Azure AD.
Mistake
AzCopy sync deletes files at the destination that are not present at the source by default.
Correct
By default, `azcopy sync` does not delete files. You must explicitly use the `--delete-destination` flag to enable deletion (either 'true' or 'prompt').
Mistake
AzCopy cannot be used to copy data between two Azure storage accounts.
Correct
AzCopy can copy between two Azure storage accounts (even across regions) by providing both source and destination URLs with appropriate authentication (SAS or Azure AD).
Mistake
Storage Explorer can be used to run scheduled automated transfers.
Correct
Storage Explorer is a GUI tool for interactive management. It does not have built-in scheduling or automation capabilities. For automated transfers, use AzCopy with scripts or Azure Automation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AzCopy `copy` transfers all files from source to destination unconditionally (unless `--overwrite` is set to false). `sync` compares source and destination based on last modified time and MD5 hash, and only transfers files that have changed. Sync also supports `--delete-destination` to remove files at the destination that no longer exist at the source. Use copy for one-time migrations, sync for ongoing replication.
Yes, AzCopy supports Azure Files. Use the URL format `https://<storageaccount>.file.core.windows.net/<share>/<path>?<SAS>`. However, AzCopy uses the REST API, so it does not preserve NTFS permissions. For SMB-based file shares with permission preservation, use Azure File Sync or robocopy.
AzCopy automatically creates a journal file in `%USERPROFILE%\.azcopy\` (Windows) or `$HOME/.azcopy/` (Linux/macOS) when a transfer starts. If the transfer is interrupted, simply re-run the exact same command. AzCopy will detect the journal and resume from the last completed block. To disable this, use the `--no-resume` flag.
The user, service principal, or managed identity must have the appropriate RBAC role on the storage account or container. For read/write access, assign 'Storage Blob Data Contributor'. For read-only, assign 'Storage Blob Data Reader'. For Azure Files, use 'Storage File Data SMB Share Contributor' (but note that AzCopy uses REST, not SMB).
Yes, Storage Explorer supports Azure Data Lake Storage Gen2 accounts with hierarchical namespace enabled. You can browse, upload, download, and manage folders and files. However, for fine-grained ACL management, Microsoft recommends using Azure CLI or AzCopy with `--hierarchical-namespace` flag.
Use the `--cap-mbps` flag to set a maximum transfer rate in megabits per second. For example, `--cap-mbps 100` limits the transfer to 100 Mbps. This is useful when running AzCopy on a shared network to avoid saturating bandwidth.
AzCopy can transfer files up to the Azure Blob Storage maximum size, which is approximately 4.75 TiB for block blobs. For page blobs, the maximum is 8 TiB. AzCopy automatically handles large files by splitting them into blocks. You can adjust the block size with `--block-size-mb`.
You've just covered AzCopy and Storage Explorer — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?