AZ-DEV-120: Azure Blob Storage for .NET Developers

Note: This lab pre-provisions an empty resource group at start — allow up to 3 minutes for it to become ready before beginning the exercises.

Create Anchorline's first Blob Storage account (GP v2, RA-GZRS, Hot) yourself using the Azure CLI. Grant your lab user Storage Blob Data Contributor at container scope, upload a file to prove auth works, then read the file back from the -secondary read endpoint to confirm RA-GZRS is live. Finish by modelling the four line items in a storage bill and identifying the biggest cost lever.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

Generate a large local file, upload it once with default single-connection settings and once with 8 parallel × 8 MiB blocks, and measure the throughput delta. Then switch to an append blob and observe how concurrent appends behave with multiple writer processes.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

Deploy the Anchorline SAS-issuer API. Verify the Web App's identity has Storage Blob Data Contributor + Storage Blob Delegator, POST to /api/upload/prepare to receive a user-delegation SAS URL, PUT a file directly to that URL, then break the Storage Blob Delegator role assignment and observe the failure signature.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

Grant yourself the required roles, upload a document with metadata + tags, seed 100 synthetic docs, then query by tag (year = '2026' AND documentType = 'invoice') to verify server-side index behavior. Confirm metadata is NOT queryable.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

Seed a set of documents, manually tier a few to prove the SetAccessTier API works, then attach a cascade lifecycle policy (Cool at 30 days → Cold at 90 → Archive at 180 → Delete at 2555). Finally simulate a rehydration.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

Enable static website hosting on the storage account, deploy the Anchorline SPA to $web with per-file cache-control headers (immutable for hashed assets, no-cache for HTML), and confirm the strategy by inspecting HTTP headers with curl. Then simulate an asset update by uploading a new hashed filename and observing browser-side cache behavior.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

The pre-provisioned storage account has change feed, versioning, and soft delete enabled. Generate change traffic (upload, overwrite, tier, delete a few blobs), wait for the change feed to batch, then read the changes with the .NET ChangeFeedClient. Finally, overwrite a blob and recover the previous version.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

Grant yourself Blob Data Owner. Scaffold a per-tenant folder tree using the DataLakeServiceClient. Inspect and modify POSIX ACLs on a directory. Perform an atomic directory rename and confirm it's fast even with data underneath.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

Seed 10 audit blobs, prove soft-delete + versioning recovers a deleted or overwritten blob, then layer a legal hold on top and observe the compound protection. Immutability policies are covered conceptually only — locking one strands the storage account for the entire retention window, so we teach the concept via the agent's narrative rather than by running the CLI.