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!
Gauge your current knowledge
Gauge your current knowledge
Azure Blob Storage provides multiple layers of security to control who can access your data and what they can do with it. The main tools for securing containers include stored access policies, shared access signatures (SAS), and role-based access control (RBAC). Each tool serves a different purpose and can be used together for defense in depth.
A stored access policy lives on the server side and gives you centralized control over groups of SAS tokens. When you create a stored access policy, you can set a start time, expiry time, and permissions that apply to any SAS token linked to that policy. This matters because if a SAS token gets compromised, you can revoke the entire policy rather than changing individual tokens. The policy attaches to a container using the Set Container ACL operation, which requires authorization through the account's shared access keys.
A shared access signature (SAS) provides delegated, temporary access to specific resources. When you generate a SAS, you specify which container or blob it grants access to, what permissions the holder gets (read, write, delete), and when the token expires. SAS tokens are useful when you need to give external users or applications limited access without sharing your account keys. However, if a SAS token leaks, attackers can use it until it expires, which is why pairing SAS with stored access policies gives you the ability to revoke access immediately.
Role-based access control (RBAC) assigns permissions to users, groups, or applications at the storage account or container level. Common roles include Storage Blob Data Contributor (read/write) and Storage Blob Data Reader (read only). RBAC controls who can manage the storage account itself, while SAS controls delegated access to specific blobs. Both systems work together: RBAC determines what a principal can do overall, while SAS provides time-limited access for specific scenarios.
The AllowBlobPublicAccess property controls whether anonymous, unauthenticated users can read blobs in your storage account. You can enable or disable this property at the storage account level through the Azure portal, PowerShell, or CLI. Microsoft recommends keeping this disabled (set to false) unless your scenario explicitly requires public access, because anonymous access is a common vector for data exposure.
Immutability policies protect data from modification or deletion by placing containers in a Write Once, Read Many (WORM) state. This is critical for meeting regulatory requirements in industries like healthcare, finance, and legal where data must remain unaltered. You apply immutability policies at the container level, and they affect all blobs within that container unless scoped to specific blob versions.
Time-based retention keeps data protected for a specified period, ranging from one day to 400 years. The policy starts in an unlocked state, which allows you to test and modify it—you can shorten the retention period or delete the policy entirely. Once you lock the policy, it becomes permanent and meets legal standards; you can only extend the retention period, never shorten it. The data cannot be deleted or modified until the retention interval expires, even by the storage account owner.
A legal hold protects data for an unknown duration, such as during active litigation or an investigation. Instead of a time period, legal holds use alphanumeric tags to identify why the data is being held. The hold remains in effect until an administrator explicitly clears it, giving flexibility when you do not know how long protection is needed. Unlike time-based policies, legal holds have no expiration and provide tamper-proof storage until released.
Lifecycle management automates data movement between storage tiers to optimize costs. Azure Storage offers three tiers: Hot (frequently accessed), Cool (infrequently accessed), and Archive (rarely accessed). Lifecycle rules can automatically move older or rarely-accessed blobs to cooler tiers and delete them when they are no longer needed. For example, a rule might transition blobs to the Cool tier after 30 days and delete them after 365 days. This automation reduces storage costs without manual intervention.
Soft delete provides a safety net against accidental deletion. When enabled, deleted containers or blobs enter a soft-deleted state rather than being permanently removed. You define a retention period (1 to 365 days) during which soft-deleted items can be restored using the Undelete command. After the retention period expires, the items are permanently deleted. This feature protects against human error and ransomware attacks, but it does increase storage costs since deleted data still consumes space during the retention period.
A container is a logical organization unit that groups related blobs together, similar to a folder in a file system. Every container belongs to a specific storage account, and each storage account can hold an unlimited number of containers. Each container can store an unlimited number of blobs, which are the actual files (documents, images, backups, or any binary data).
Container names must follow specific rules: they must be lowercase, start with a letter or number, contain only letters, numbers, and dashes, and be between 3 and 63 characters long. These restrictions ensure compatibility across Azure's distributed systems and prevent naming conflicts.
When you create a container, you must set its public access level, which determines whether anonymous users can read the contents. The Private level blocks all anonymous access—only the storage account owner can read or list blobs. The Blob level allows anonymous users to read individual blobs if they know the blob's name, but they cannot list what files exist in the container. The Container level allows anonymous users to both read blobs and list the container's contents. Microsoft recommends defaulting to Private for security, and only using Blob or Container levels when you intentionally want public access.
You can attach metadata and tags to containers for organization and management. Metadata consists of key-value pairs that describe the container (such as department, owner, or project), while tags are simpler key-value pairs used for billing, filtering, and resource management. Both help administrators identify and categorize containers across large Azure environments, but tags are specifically designed for cost tracking and automation scenarios.
StudyCerts
StudyCerts