You can develop, but can you develop for the cloud? Harness your development skills and learn how to create robust solutions for Microsoft Azure, aiming for your Microsoft Certified: Azure Developer Associate certification!
Gauge your current knowledge
Gauge your current knowledge
Azure Blob Storage organizes blob data using system-defined properties and user-defined metadata. System-defined properties represent standard HTTP headers that control how the web handles the file. These headers include Content-Type to define the MIME type, Cache-Control to direct client caching, and ETag to uniquely identify the current file version. In contrast, user-defined metadata consists of custom name-value pairs created by developers to categorize files for custom business workflows. These custom metadata pairs must follow HTTP header naming rules, have a combined size limit of 8 KB, and do not change how the blob behaves.
To read these values, an application uses the Azure SDK or the REST API to fetch blob properties. Calling BlobClient.GetProperties() returns a response object containing both system headers and the metadata dictionary. When updating system headers, developers use BlobClient.SetHttpHeaders() and must provide the full header set because any omitted properties will be cleared. Similarly, calling BlobClient.SetMetadata() completely overwrites the existing metadata collection. To preserve existing metadata or headers during an update, you must first read the current values, merge your changes, and then save the updated collection.
Developers implement optimistic concurrency control to prevent users from accidentally overwriting each other's changes. When an application attempts to update a blob, it includes the blob's original ETag in an If-Match conditional header. If another process has modified the blob in the meantime, the ETag will not match, causing Azure to return a 412 Precondition Failed error. Access to these properties and metadata is managed through Azure Role-Based Access Control (RBAC). Users need the Storage Blob Data Reader role to read these settings, while the Storage Blob Data Contributor role is required to write or modify them.
The SDK provides specialized clients to manage storage accounts, containers, and individual files. Developers interact with BlobServiceClient for account-level tasks, ContainerClient to organize folders, and BlobClient to manage individual files. To authenticate securely, applications utilize DefaultAzureCredential to connect via managed identities instead of risky account keys. The SDK includes helper methods such as createIfNotExists and upload to write data, and listBlobs, download, and delete to manage resources. Transient network issues are automatically resolved using a built-in exponential backoff retry policy, while bulk data movements can be accelerated using AzCopy.
Applications interacting with Azure Cosmos DB use the SDK to manage schema-free JSON documents and database containers. Developers initialize CosmosClient as a singleton to maintain connection pools, while using CosmosDBManagementClient for administrative control-plane changes. You can create containers using CreateContainerIfNotExistsAsync and manage individual items using CreateItemAsync, ReadItemAsync, or UpsertItemAsync. Performance is governed by Request Units (RUs), which you can programmatically scale using ReplaceThroughputAsync to match changing workloads. If an application exceeds its provisioned RUs, the SDK throws a CosmosException to signal rate-limiting, which the app handles using retry logic.
The Azure Tables SDK provides a unified model to access both Azure Table Storage and Azure Cosmos DB for Table using structured entities. Every entity must define a PartitionKey to determine its physical storage location and a RowKey to act as a unique identifier within that partition. This unique key pair forms a clustered index, which makes point queries highly efficient. To perform bulk updates, developers use Entity Group Transactions (EGTs) to group up to 100 operations into a single atomic unit. All operations in an EGT must share the same partition key, ensuring they either all succeed or all roll back together.
Azure Blob Storage offers four access tiers to balance storage costs with data access speed. The Hot tier is optimized for active data and has low transaction fees but high storage costs. The Cool and Cold tiers offer cheaper storage for data that is infrequently accessed or modified. The Archive tier provides the lowest storage cost but is offline, meaning it has the highest access costs and requires several hours to retrieve data. Developers can transition blobs manually using the Set Blob Tier API, or automate the process to avoid early deletion charges.
A lifecycle management policy uses rule-based JSON documents to automate the movement and deletion of blob data. Each rule contains a filter set to target specific blobs and an action set to move or delete them. Filters can target data based on prefix matches, blob types, or blob index tags. Actions include migrating files to cheaper tiers (such as TierToCool or TierToArchive) or permanently deleting them when they are no longer needed. These rules run automatically as a background process once per day, and new changes can take up to 24 hours to execute.
Before reading data stored in the Archive tier, you must first perform a process called rehydration to return the blob to an online tier. You can rehydrate data using either Standard priority, which can take up to 15 hours, or High priority, which can complete in under an hour for an extra cost. To prevent automated policies from immediately archiving a newly rehydrated blob, you should apply a minimum age condition to the policy rules. For regulatory compliance, organizations can also configure immutable storage using time-based retention or legal holds. This enforces a Write Once, Read Many (WORM) state that prevents any modification or deletion of business-critical data.
The Azure SDK provides specialized client libraries to perform CRUD operations on Azure Blob Storage. To manage your resources, you interact with three core classes: BlobServiceClient fo…
The Azure SDK provides specialized client libraries to perform CRUD operations on Azure Blob Storage. To manage your resources, you interact with three core classes: BlobServiceClient fo…
Azure Blob Storage allows you to attach custom name-value pairs called user-defined metadata to your blobs. Unlike system properties such as file size or creation date, metadata consists of …
Azure Blob Storage allows you to attach custom name-value pairs called user-defined metadata to your blobs. Unlike system properties such as file size or creation date, metadata consists of …
Azure Blob Storage uses lifecycle management to automatically move data between different storage tiers. These policies help save money by moving older data to cheaper tiers like Cool or **Archi…
Azure Blob Storage uses lifecycle management to automatically move data between different storage tiers. These policies help save money by moving older data to cheaper tiers like Cool or **Archi…
StudyCerts
StudyCerts