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!
By default, an Azure Storage account accepts traffic from all networks. To restrict access, you change the default action to deny and then create explicit firewall rules. These rules permit data plane traffic from specific sources, such as certain public IP addresses or Azure subnets. Control plane operations, like managing the account, are not blocked by these rules. To allow traffic from a virtual network subnet, you must first enable the Microsoft.Storage service endpoint on that subnet. Certain authorized Microsoft services, like Azure Backup, can bypass these restrictions via a trusted services exception, which remains functional even if you disable all public network access.
Secure network integration is achieved through service endpoints or private endpoints. Service endpoints extend your virtual network's identity to the storage service, keeping traffic on Azure's private backbone. Private endpoints assign a private IP address from your virtual network directly to the storage account, blocking all public access and allowing secure connections from on-premises networks. Service endpoints apply to all storage accounts in a region, while a private endpoint isolates access to a single account. Private endpoints provide stronger data exfiltration protection but require manual management of private DNS records and incur extra cost.
Virtual network rules are preferred over IP rules because they prevent any public IPs from reaching the storage account, significantly reducing the attack surface. The configuration is a two-step process: first, enable the service endpoint on a subnet, and second, create a corresponding network rule on the storage account. This is typically done using PowerShell commands like Set-AzVirtualNetworkSubnetConfig and Add-AzStorageAccountNetworkRule. Finally, you update the storage account's default network rule action to deny.
Shared Access Signature (SAS) tokens provide limited, time-bound access to storage resources without sharing your account key. The token is a signed URL that specifies allowed permissions, resources, and a validity period. There are three types: a Service SAS grants access to a specific resource (like a container) and is signed with the storage account key; an Account SAS provides broader access across services; and a User Delegation SAS is signed with Microsoft Entra credentials and is the most secure option. When creating a SAS, you define its permissions, set a strict expiration time, and can optionally restrict access to specific IP addresses.
The User Delegation SAS is recommended for Blob Storage when clients authenticate via Microsoft Entra ID. Use a Service SAS for granular access to a single service when you need the benefits of a stored access policy. An Account SAS should only be used for complex scenarios requiring cross-service access. For Service and Account SAS tokens, which rely on shared keys, you must enforce HTTPS, use very short expiration times, and associate Service SAS tokens with stored access policies for manageability.
Set short expiration times to limit risk if a token is leaked. Account for clock skew by setting the token's start time at least 15 minutes in the past. For Service SAS tokens, implement a Stored Access Policy (SAP); this server-side policy allows you to centrally manage permissions and instantly revoke all linked tokens by deleting the policy. Always follow the principle of least privilege, granting only the minimum necessary permissions and forcing the use of HTTPS. You can also configure a SAS expiration policy at the storage account level to set a recommended maximum validity period.
A stored access policy is a server-side template used to centrally manage groups of service-level SAS tokens. You define permissions and timeframes within the policy, which only works with service SAS tokens. You can create up to five policies per resource container. You manage policies using the storage account access keys. The key benefit is immediate revocation: if a token is compromised, you can invalidate all tokens linked to a policy by deleting it or setting its expiry to a past time.
Stored access policies can be applied to Blob containers, File shares, Queues, and Tables. Creating a policy requires using the Set Container ACL operation, authorized with the storage account's Shared Key. You define a policy with a unique ID, start time, expiry time, and permission string. Any service SAS referencing this policy inherits its constraints and cannot specify permissions or expiry outside the policy's limits.
Integrating a Stored Access Policy with a Service SAS provides centralized control and enhanced security. The SAS inherits the policy's constraints. The major advantage is the ability to revoke or modify access after the SAS is issued by changing the underlying policy, which instantly affects all linked tokens. This structure simplifies security management by controlling rules from a single point.
Storage account access keys provide full control via Shared Key authorization and are a security risk. They should be disabled in favor of Microsoft Entra ID authentication. Use Azure Role-Based Access Control (RBAC) to control who can view or regenerate keys. For secure storage and automated rotation, use Azure Key Vault. To rotate keys safely without downtime, Azure provides two keys (Key1 and Key2); update applications to use Key2, regenerate Key1, then update apps to the new Key1, and finally regenerate Key2.
Azure Files can authenticate users with their on-premises Active Directory Domain Services (AD DS) credentials. You must domain-join the storage account to your AD using tools like the AzFilesHybrid PowerShell module. Access control has two layers: assign share-level permissions using Azure RBAC roles, and manage directory and file-level permissions using traditional Windows NTFS permissions (ACLs) inside the share. On-premises clients typically connect over Port 445 (SMB) via a VPN, ExpressRoute, or a Private Endpoint.
This method uses Microsoft Entra ID identities to authenticate users to Azure file shares, with no on-premises domain needed. Start by assigning share-level permissions using specific Azure RBAC roles for the file share. Once a user has this access, you can configure directory and file-level permissions using Windows ACLs. For services like Azure File Sync, you can use a managed identity instead of storage account keys for secure authentication.
Permission management for Azure Files is a two-tier process. At the share level, use precise Azure RBAC roles scoped to the file share. After a user is granted share access, NTFS permissions provide fine-grained control inside the share using Windows ACLs. These ACLs are preserved during migration and can be managed with tools like File Explorer. Both permission levels are combined, with the most restrictive taking effect.
A process flow showing how Azure Files combines share-level Azure RBAC permissions with directory and file-level NTFS permissions, where the most restrictive permission takes effect.
To create a storage account, you choose an account type, which dictates supported services. General-purpose v2 accounts support blobs, files, queues, and tables. For premium performance, options include Premium block blob, Premium page blob, or Premium file share. Data durability is configured via replication strategies like locally-redundant storage (LRS) or geo-redundant storage (GRS). To optimize costs, data can be assigned to different access tiers: Hot, Cool, or Archive. Security involves enabling secure transfer (HTTPS), configuring network rules to restrict traffic, and utilizing private endpoints. You should use Microsoft Entra ID for authentication, disable anonymous read access, and disallow shared key authorization. Data protection features include blob soft delete, container soft delete, blob versioning, and immutability policies.
Zone-redundant storage (ZRS) synchronously copies data across three availability zones within a region, protecting against a datacenter failure. For disaster recovery, geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) asynchronously copies data to a secondary region. To allow read access during an outage, you can enable read-access geo-redundant storage (RA-GRS) or RA-GZRS. A failover makes the secondary region the new active primary. An unplanned failover carries a risk of data loss and converts the account to LRS, requiring you to manually re-enable geo-redundancy afterward. When evaluating redundancy, balance cost versus availability, determine if you need cross-region protection, and assess if read access during an outage is required.
Object replication asynchronously copies block blobs between a source and destination storage account based on defined policies and rules. It is used for scenarios like minimizing latency, optimizing compute workloads across regions, and meeting compliance requirements. Both source and destination accounts must have blob versioning enabled, and the source requires the blob change feed. Replication is asynchronous, so the destination is not immediately in sync. It does not support customer-managed failover and serves as a data synchronization tool rather than a full disaster recovery solution. Costs 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 by default with Microsoft-managed keys. For more control, you can use customer-managed keys stored in Azure Key Vault or customer-provided keys supplied with each request. Encryption scopes let you apply different encryption rules to specific containers or blobs within the same account. For the highest security, you can enable infrastructure encryption, which applies double encryption—once at the service level and again at the infrastructure level. To enable customer-managed keys, you need an Azure Key Vault with Soft Delete and Purge Protection enabled, and you must assign a managed identity to the storage account.
AzCopy is a high-performance command-line utility for moving data into, out of, and between Azure storage accounts. It supports authorization via Microsoft Entra ID or Shared Access Signature (SAS) tokens. The azcopy copy command performs a one-time transfer, while azcopy sync replicates changes by comparing files. Azure Storage Explorer is a graphical tool for managing storage accounts and performing ad-hoc operations like upload and download. For security, use RBAC and SAS tokens with least privilege, enforce HTTPS, and utilize firewalls and private endpoints. For operational control, use AzCopy's log files to resume interrupted jobs and tune performance by adjusting concurrency settings.
To create a file share, you first create a storage account. You choose between premium performance (on SSD) for low latency or standard performance (on HDD) for cost-effectiveness. Standard accounts offer access tiers: Transaction Optimized, Hot, and Cool. For authentication, Azure Files supports on-premises AD DS, Microsoft Entra Domain Services, or Microsoft Entra Kerberos using the Kerberos protocol. Authorization involves two layers: Azure RBAC for share-level permissions and Windows ACLs for directory/file-level permissions. For network security, use Private Endpoints or Service Endpoints to block public internet access. On-premises clients typically need a VPN or ExpressRoute, or you can enable SMB over QUIC to use Port 443.
Securing Blob Storage involves combining multiple controls. A stored access policy provides server-side management for SAS tokens. A SAS token itself grants delegated, time-limited access. You also assign Azure RBAC roles for identity-based access. You can set the AllowBlobPublicAccess property to false to block anonymous access. When creating a container, you can apply immutability policies for Write Once, Read Many (WORM) compliance, either as time-based retention or a legal hold. You can also attach metadata or tags to the container for organization and cost tracking.
Azure Blob Storage offers four access tiers: Hot, Cool, Cold, and Archive. The Hot tier has the highest storage cost but lowest transaction fees. Cool and Cold have lower storage costs but higher access fees and minimum retention periods (30 and 90 days respectively). The Archive tier is offline and requires a rehydration process to access data. You can set a default tier at the account level and override it per blob. To automate movement, use lifecycle management policies with JSON rules. Be aware of early deletion penalties if you delete or move data before its minimum retention period ends. Azure Files standard shares can also move between Hot and Cool tiers, with each transition incurring transaction fees.
Soft delete protects against accidental deletions by placing resources in a temporary, recoverable state. For containers, soft delete hides the container and its contents for a configurable retention period (1-365 days). For blobs, it preserves files, snapshots, and versions if they are deleted or overwritten. It is managed at the storage account level. For maximum protection, combine container soft delete, blob soft delete, and blob versioning. To restore items, use the "Show deleted" setting in the portal and execute an undelete operation. Keeping soft-deleted items increases storage costs and can slow performance if you have over 1,000 items.
Share snapshots are incremental, read-only copies of a file share. Azure Backup can automate snapshot creation and retention. You can retain up to 200 snapshots per share for up to 10 years. If a file share is deleted and soft delete is enabled, it enters a soft-deleted state, allowing you to restore the entire share and its snapshots. Soft delete for Azure Files operates at the share level only; to recover individual files, you must use share snapshots or Azure Backup. Standard shares in a soft-deleted state incur normal storage costs, while premium shares are billed at snapshot rates.
Lifecycle management policies use JSON rules to automatically transition or delete blobs based on criteria like age or last accessed time. If using last accessed time, you must enable access time tracking on the storage account. Rules can filter by prefix, blob type, or custom tags. The policy engine runs in the background, typically scanning once per day, and can take up to 24 hours to apply changes. To monitor execution, route the LifecyclePolicyCompleted event through Azure Event Grid. For troubleshooting, query Azure Monitor logs for the ObjectLifeCycleScanner user agent to find failures.
Blob versioning automatically saves a previous version of a blob each time it is modified. It works with blob soft delete to form a resilient safety net. When both are enabled, deleting a current version changes its status to a previous version, while deleting a previous version moves it to a soft-deleted state. You can restore data via an Undelete Blob operation or promote a specific version back to current using Copy Blob. You enable versioning at the storage account level. It increases storage consumption, so Microsoft recommends keeping fewer than 1,000 versions per blob. Use lifecycle management policies to transition old versions to cheaper tiers or delete them.
Prepare and test your skills
Prepare and test your skills
Service endpoints extend your virtual network's identity to the storage service, keeping traffic on Azure's private backbone. Private endpoints assign a private IP address from your virtual network directly to the storage account, blocking all public access. Private endpoints provide stronger data exfiltration protection but require manual management of private DNS records and incur extra cost.
The three types are: Service SAS (grants access to a specific resource like a container, signed with the storage account key), Account SAS (provides broader access across services), and User Delegation SAS (signed with Microsoft Entra credentials and is the most secure option).
Azure provides two keys (Key1 and Key2). To rotate safely without downtime, update applications to use Key2, regenerate Key1, then update apps to the new Key1, and finally regenerate Key2.
A stored access policy is a server-side template used to centrally manage groups of service-level SAS tokens. You define permissions and timeframes within the policy, and its key benefit is immediate revocation: if a token is compromised, you can invalidate all tokens linked to the policy by deleting it or setting its expiry to a past time.
StudyCerts
StudyCerts