You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
To create an Azure storage account, administrators can use the Azure portal, PowerShell, or the Azure CLI. Choosing the correct account type is critical because it dictates the underlying capabilities and supported data services. For general workloads, General-purpose v2 accounts support blobs, files, queues, and tables. Specialized workloads may require premium performance, which offers options like Premium block blob for fast blob access, Premium page blob for virtual machine disks, or Premium file share for high-performance file storage.
Data durability depends on the chosen replication strategy, which copies data to protect against hardware failures or regional disasters. Options include locally-redundant storage (LRS), which keeps three copies in a single data center, and geo-redundant storage (GRS), which replicates data to a secondary region. For immediate read access to the secondary region, administrators can use read-access geo-redundant storage (RA-GRS). To optimize costs, data can be assigned to different access tiers: Hot for frequently accessed data, Cool for infrequently accessed data, and Archive for long-term storage where latency is acceptable.
Protecting storage accounts requires a combination of network restrictions and identity verification. Enabling secure transfer (HTTPS) enforces encrypted communication, while infrastructure encryption adds a second layer of encryption at the service level. To control access, administrators should configure network rules that restrict traffic to trusted IP addresses or specific virtual networks. Utilizing private endpoints secures traffic by routing it through a private IP address within a virtual network instead of exposing the account to the public internet.
Implementing robust access control relies on the principle of least privilege to ensure users only access necessary resources. Administrators should use Microsoft Entra ID for authentication rather than shared keys, as it supports fine-grained role-based access control. To reduce security risks, you should disable anonymous read access to containers and disallow shared key authorization entirely. When temporary access is required, generate user delegation SAS tokens signed with Entra credentials instead of using storage account keys. For cases where account keys must be used, store them securely in Azure Key Vault and rotate them regularly.
Securing the network boundary involves reducing the public attack surface of your storage accounts. Administrators should disable public network access and deploy private endpoints so traffic travels securely over Azure Private Link. Firewalls should be configured with a default-deny rule, allowing traffic only from specific virtual networks or trusted IP ranges. For transit security, enforce the secure transfer required option and mandate a minimum of TLS version 1.2. While Azure encrypts data at rest by default, you can manage your own encryption keys by configuring customer-managed keys stored in Azure Key Vault.
To protect against accidental deletions and data corruption, Azure provides several built-in safety features. Enabling blob soft delete and container soft delete allows deleted items to be recovered within a configured retention period. Activating blob versioning tracks historical changes to blobs, while point-in-time restore lets you revert block blobs to a healthy previous state. For strict compliance requirements, immutability policies can enforce legal holds or time-based retention to prevent any data modification or deletion. To control costs, configure lifecycle management policies that automatically move blobs to cooler access tiers or delete them based on age.
Selecting the correct parameters during provisioning is critical because you cannot change the account type after creation. For most standard workloads, a Standard General-purpose v2 account is the default choice as it supports blobs, files, queues, and tables. Workloads requiring low latency and high transaction rates should use the Premium performance tier, which uses solid-state drives. Redundancy options must be evaluated against the organization's Recovery Point Objective (RPO) and data residency rules.
Administrators must determine how users and applications will connect to the storage account during the initial provisioning phase. There are three primary connection options: public endpoints allow internet access but can be secured using virtual network filters and firewall rules; service endpoints provide secure, direct connections to Azure services over the private Azure backbone network; and private endpoints utilize Azure Private Link to route traffic privately by assigning a private IP address from your virtual network. Choosing private endpoints provides the highest level of security by isolating the storage account from the public internet entirely.
For big data and analytics workloads using Azure Data Lake Storage Gen2, administrators should enable the hierarchical namespace to organize files into directories and improve performance. Selecting the correct default access tier, such as Hot or Cool, helps align storage costs with how frequently data will be read. Properly defining these parameters upfront ensures that the storage account remains highly scalable and cost-efficient as data volume grows.
Zone-redundant storage (ZRS) protects data by synchronously copying it across three separate availability zones within a single Azure region. An availability zone is a distinct physical location with its own power, cooling, and network. This setup ensures your data remains available even if an entire data center fails. ZRS provides very high durability and is recommended for workloads that need high availability and must keep data within a specific geographic region for governance reasons. Unlike some other options, ZRS allows applications to continue reading and writing without interruption during a zonal outage.
For protection against a major disaster affecting an entire region, you can use geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS). Both options asynchronously copy your data to a secondary geographic region hundreds of miles away. The key difference is the protection in the primary region: GRS uses locally redundant storage (LRS), while GZRS uses the stronger ZRS. In both cases, the data in the secondary region is always stored using LRS. These options are critical for business continuity and provide the highest levels of data durability.
To maximize availability, you can enable read-access geo-redundant storage (RA-GRS) or RA-GZRS. These options provide a secondary, read-only endpoint in the paired region. If the primary region becomes unavailable, applications can be designed to shift their read operations to this secondary endpoint. It's important to know that data on the secondary side is eventually consistent, meaning it may be slightly behind the primary due to the asynchronous replication. Note that Azure Files does not support read-access geo-redundancy.
A failover is the process of making the secondary region the new active primary region. This is done by updating DNS records. An unplanned failover carries a risk of data loss because replication is asynchronous; the recovery point objective (RPO) is typically under 15 minutes. Importantly, initiating an unplanned failover converts the storage account to LRS in the new region, and you must manually re-enable geo-redundancy afterward. You must also consider data residency, as the paired secondary region is fixed by Azure and cannot be customized.
Azure supports three failover types. A customer-managed unplanned failover is for real outages, while a customer-managed planned failover is for testing. A Microsoft-managed failover is initiated by Microsoft only in extreme, region-wide disasters and should not be relied upon for your recovery plans. After an unplanned failover, the account is converted to LRS, and you must manually re-enable geo-redundancy, which involves data transfer costs. Always check the Last Sync Time property before a failover to understand potential data loss.
The main redundancy options form a spectrum from least to most protective. Locally Redundant Storage (LRS) is the lowest-cost option, storing three copies within one datacenter and protecting only against local hardware failures. Zone-Redundant Storage (ZRS) stores copies across three availability zones in one region, protecting against a datacenter failure. Geo-Redundant Storage (GRS) adds asynchronous replication to a secondary region for protection against regional disasters. Read-Access Geo-Redundant Storage (RA-GRS) is like GRS but allows read access from the secondary region during an outage. Geo-Zone-Redundant Storage (GZRS) and RA-GZRS combine ZRS in the primary region with geo-replication, offering the highest level of protection.
When evaluating which model to use, consider three main factors. First, balance cost versus availability: LRS is cheapest but offers the least protection, while GZRS offers the most at a higher price. Second, determine your replication needs: decide if you need protection only within a region (LRS/ZRS) or across regions (GRS/GZRS). Third, assess if your application needs read access during an outage, which would point you toward RA-GRS or RA-GZRS. To apply these models effectively, use separate storage accounts for data with different redundancy needs, have a clear disaster recovery plan that includes your failover strategy, and actively monitor costs, as higher redundancy levels and cross-region data transfers increase your expenses.
A decision tree that branches on geographic protection and read-access needs to select the appropriate Azure Storage redundancy model, from LRS to RA-GZRS.
Object replication is a feature that asynchronously copies block blobs between a source and destination storage account. Unlike standard redundancy options, it allows for granular control by letting administrators define specific replication policies and rules for containers. This service is essential for building sophisticated multi-region topologies that are not restricted by Azure's default regional pairings.
There are several advanced scenarios where object replication outperforms traditional redundancy. It is frequently used to minimize latency by placing data closer to global users and to optimize compute workloads across different regions. Common use cases include data distribution where specific results are replicated to additional regions for local access, cost optimization by moving replicated data to the archive tier in the destination account using lifecycle policies, and compliance by ensuring data resilience across specific geographic boundaries to meet regulatory requirements.
To implement this feature, both accounts must have blob versioning enabled, and the source account requires the blob change feed. Object replication is not supported for accounts with a hierarchical namespace or for blobs encrypted with customer-provided keys. Archived blobs and snapshots are not included in the replication process, requiring careful planning for data lifecycle management.
The configuration of this service relies on a replication policy, which acts as a container for specific instructions. Each policy is identified by a unique Policy ID that must match on both the source and destination accounts to function. Within these policies, you define replication rules that specify which containers are paired together. Prefix filters allow you to limit replication to specific blobs that start with a certain string of characters. The copy scope setting determines if the policy applies only to new objects or includes existing data. A single policy can support up to 1000 separate rules for different container mappings.
Because the replication process is asynchronous, there is a slight delay, meaning the source and destination are not perfectly in sync at every moment. Blob versioning is mandatory because it allows the system to replicate the current state of a blob along with its historical versions. If a user deletes a blob at the source, the destination reflects this change by moving the current version into a previous version state. It is important to note that blob snapshots and index tags are not carried over during the replication process.
For organizations with strict recovery requirements, priority replication provides a Service Level Agreement for faster data transfer. This advanced feature guarantees that 99% of objects will replicate within 15 minutes if the accounts are located on the same continent. However, this performance guarantee excludes objects larger than 5 GB or those that are modified more than 10 times per second. Administrators can track the health of their data movement through replication metrics, which monitor pending operations and total bytes waiting to be copied.
Object replication in Azure Storage allows for the asynchronous copying of block blobs between a source storage account and a destination account. This feature supports several scenarios, including minimizing latency by enabling clients to access data from a region closer to them, increasing efficiency for compute workloads by allowing the same data sets to be processed in different regions, optimizing data distribution by processing or analyzing data in one location and then replicating to other regions, and optimizing costs by moving replicated data to the archive tier after replication using lifecycle management policies.
To use object replication, certain Azure Storage features must be enabled. The change feed must be enabled on the source account, and blob versioning must be enabled on both the source and destination accounts. These features may incur additional costs. Object replication is supported for general-purpose v2 storage accounts and premium block blob accounts, but only for block blobs. It is not supported for append blobs, page blobs, or blobs encrypted with customer-provided keys.
Object replication copies block blobs in a container based on configured rules. The blob's contents, versions, metadata, and properties are all replicated from the source to the destination container. However, replication is asynchronous, meaning the source and destination accounts are not immediately in sync. There is no SLA on replication time, but the replication status can be checked on the source blob.
While geo-redundant storage provides a built-in failover mechanism to a fixed paired region, object replication offers any-to-any region flexibility. Standard redundancy options like GRS replicate the entire storage account, whereas object replication allows for filtering by container or prefix. However, object replication does not support customer-managed failover, meaning it serves as a data synchronization tool rather than a full disaster recovery failover solution. The cost implications of object replication include egress charges for data moving between regions and transaction costs for reading the change feed.
Azure Storage service-side encryption (SSE) automatically encrypts all data at rest using 256-bit AES encryption, which meets FIPS 140-2 standards and works like BitLocker. This encryption is turned on by default for every storage account, covering all performance tiers, access tiers, and deployment models. It protects not just the actual data but also object metadata across blobs, disks, files, queues, and tables. There is no extra charge for this encryption, and it cannot be turned off, so data stays protected without any extra work from you.
Microsoft-managed keys handle encryption by default, but you can take more control through two customer-controlled options. Customer-managed keys let you use your own key stored in Azure Key Vault or Azure Key Vault Managed HSM to encrypt and decrypt data in Blob Storage and Azure Files. Customer-provided keys work differently—you supply an encryption key directly with each Blob Storage request, giving you fine-grained control over individual operations. The main difference between these options is where the key lives and who is responsible for rotating it.
Encryption scopes let you apply different encryption rules to specific containers or even individual blobs within the same storage account. This is useful when you need to separate data between different customers or departments. Each encryption scope can use either Microsoft-managed keys or customer-managed keys, creating distinct security boundaries that help meet regulatory compliance requirements.
For the highest security needs, you can enable infrastructure encryption, which applies double encryption—once at the service level and again at the infrastructure level—using two different algorithms and two different keys. Even if someone compromises one encryption system, the data remains protected by the second layer. The service-level encryption can use Microsoft-managed or customer-managed keys, while the infrastructure level always uses a separate Microsoft-managed key. Client-side encryption encrypts data in your application before it uploads to Azure, adding protection for sensitive information. However, you should use client-side encryption v2 (which uses GCM mode with AES) rather than v1, because v1 has a known security vulnerability.
Azure Storage Service Encryption (SSE) protects all data at rest by default using Microsoft-managed keys, giving every storage account basic security without any setup. For organizations that need more control—such as meeting specific regulatory requirements—you can switch to customer-managed keys (CMK) using Azure Key Vault, which lets you own and manage the encryption keys yourself.
To enable customer-managed keys, you need an Azure Key Vault with Soft Delete and Do Not Purge properties turned on. These settings protect against accidentally losing your keys—if a key gets deleted, soft delete lets you recover it within the retention period. Without these properties enabled, you cannot use the key vault with storage account encryption. You can configure customer-managed keys through the Azure portal, PowerShell, or Azure CLI.
For extra protection, infrastructure encryption adds a second layer of encryption on top of whatever you already have configured. When you enable this, data gets encrypted twice—once by the storage service and once at the infrastructure level—using two different keys and algorithms. You enable this when creating a storage account by including the RequireInfrastructureEncryption option. Using customer-managed keys and infrastructure encryption helps meet compliance requirements by giving you control over encryption keys and the ability to audit key access.
Customer-managed keys (CMK) give you full control over the encryption keys protecting your Azure Storage data, which helps meet compliance requirements and provides flexibility in how you manage key lifecycle. These keys must live in Azure Key Vault or Azure Key Vault Managed HSM, and the key vault must have both soft delete and purge protection enabled before you can use it with storage encryption.
To set up CMK, you need a managed identity assigned to your storage account—this can be either user-assigned or system-assigned. This managed identity receives the Key Vault Crypto Service Encryption User role, which grants minimum permissions to perform three operations: wrapkey (to encrypt the key), unwrapkey (to decrypt the key), and get (to read the key). The key vault supports RSA and RSA-HSM keys at 2048, 3072, or 4096 bits.
When configuring CMK, you choose between automatic and manual key version updates. With automatic rotation, Azure Storage checks your key vault daily for new key versions and updates the encryption key without any action from you. With manual rotation, you specify the exact key version and must update the storage account settings yourself whenever you create a new key version. Either approach works, but automatic rotation reduces the operational burden. Key rotation is important for security, and while Azure Storage does not rotate keys automatically, you can set up rotation policies in Azure Key Vault or rotate keys manually.
If you disable or revoke a customer-managed key, any storage operations that need decryption will fail with error code 403 (Forbidden). This affects Blob Storage operations like listing, reading, copying, and writing blobs, as well as Azure Files operations like creating, listing, reading, and modifying files and directories. Revoking a key essentially locks access to the encrypted data, which is exactly what you want when meeting strict compliance requirements—but it also means you must be careful never to revoke a key you still need. You can switch between Microsoft-managed keys and customer-managed keys at any time through the portal, PowerShell, or CLI.
AzCopy is a high-performance command-line utility for moving data into, out of, and between Azure storage accounts. It supports Azure Blob, Azure Files, and Azure Table storage, and administrators often choose it for scriptable, automated tasks. Key use cases include migrating data from on-premises sources to the cloud, transferring data between different storage accounts, and synchronizing local directories with cloud containers.
Before using AzCopy, you must provide authorization credentials to ensure secure data access. The most secure method is using Microsoft Entra ID, which requires signing in once with the azcopy login command. Alternatively, you can use a Shared Access Signature (SAS) token appended to the resource URL. Choosing the right authorization method is critical for maintaining security during large-scale migrations.
The two primary commands for data movement are azcopy copy and azcopy sync. The copy command performs a one-time transfer of files, while the sync command replicates changes by comparing file names and timestamps. Using the --recursive flag is essential to include all subdirectories in a transfer. Important parameters include --include-pattern to filter specific file types and --delete-destination to remove files from the target that no longer exist at the source.
For large-scale transfers, you can optimize performance by adjusting the AZCOPY_CONCURRENCY_VALUE environment variable, which increases the number of concurrent requests to utilize more network bandwidth. To maintain reliability, limit individual jobs to fewer than 10 million files to avoid excessive tracking overhead. The azcopy benchmark command helps identify bottlenecks in your environment. Security can be further enhanced by configuring the AllowedCopyScope property on a storage account, restricting data transfers to specific scopes such as the same Microsoft Entra tenant or via Private Link.
Managing data with Azure Storage Explorer and AzCopy requires understanding both security and operational controls. AzCopy is a command-line utility optimized for high-performance, scriptable transfers, while Azure Storage Explorer is a graphical tool suited for ad-hoc file operations. Both tools require careful attention to authentication, permissions, and data protection.
For authentication with AzCopy, you can use Microsoft Entra ID with RBAC roles like Storage Blob Data Contributor and authenticate interactively or with a service principal for automation. Alternatively, Shared Access Signatures (SAS) provide time-limited tokens with granular permissions. Storage account keys offer full access but are less recommended due to broad permissions. For Data Lake Storage Gen2, you must also have your identity present in Access Control Lists (ACLs). Misconfigured permissions, such as missing RBAC roles or expired SAS tokens, lead to 403 Forbidden errors.
Key data protection features include SAS tokens that limit access by time, IP, and allowed operations; RBAC that enforces least privilege; the AllowedCopyScope setting that restricts copy sources to specific environments; the Secure Transfer Required setting that enforces HTTPS/TLS; and firewalls and private endpoints that limit network access. Combining RBAC, SAS, and network controls ensures robust security for both automated and manual data movement.
For operational excellence, use AzCopy's log and journal files to track job status and resume interrupted operations. Exit codes indicate success (0), recoverable errors (1), or critical failures (2+). Tune performance by adjusting concurrency and using parallel uploads, and always use the latest AzCopy version. Implement exponential back-off when retrying after 503/500 throttling errors, but avoid retrying non-retryable errors like 400 Bad Request. Use the sync command for one-way synchronization and ensure no writes occur to source files during transfer for consistency.
Azure Storage Explorer provides a graphical interface to manage Azure storage accounts, working with blobs, files, queues, and tables. It simplifies performing data operations such as upload, download, and copy, and configuring access permissions. The intuitive interface makes ad-hoc data operations straightforward.
To navigate the tool, you connect to multiple storage accounts and then manage individual services: create, delete, and manage blob containers and their contents; work with Azure file shares, including uploading and downloading files; manage message queues by adding and retrieving messages; and interact with table storage by querying and updating entities. For data operations, you can easily upload files and folders to your storage account, download files and blobs to your local machine, and copy data between different storage accounts or containers.
Access permissions are configured through Shared Access Signatures (SAS)—you generate SAS tokens to grant limited, time-bound access—and by setting access control for different users and applications to control who can view or modify your data. AzCopy complements Azure Storage Explorer by providing advanced command-line capabilities for bulk data transfer and automation. While the Explorer handles interactive tasks, AzCopy is better suited for large, scriptable, or scheduled transfers. Together, these tools ensure secure, efficient, and optimized storage operations for any Azure administrator.
Prepare and test your skills
Prepare and test your skills
Both GRS and GZRS asynchronously copy data to a secondary geographic region for disaster recovery, but they differ in protection within the primary region. GRS uses locally redundant storage (LRS) in the primary region, while GZRS uses zone-redundant storage (ZRS) across three availability zones for higher availability.
Object replication should be used for granular control over copying specific block blobs between any regions, such as for minimizing latency for global users or optimizing costs with lifecycle policies. Standard geo-redundant storage replicates the entire storage account to a fixed Azure-paired region and includes a built-in failover mechanism, which object replication does not provide.
Customer-managed keys are stored and managed in Azure Key Vault or Azure Key Vault Managed HSM, allowing you to control the encryption key lifecycle for Blob Storage and Azure Files. Customer-provided keys are supplied directly with each Blob Storage request, giving fine-grained control over individual operations but requiring the application to manage and rotate the keys.
StudyCerts
StudyCerts