Hand-written. All code and content in this project was written by me.

Why Infrastructure as Code

My goal was to stop clicking through the Azure Portal and start defining infrastructure in a file that can be versioned, reviewed, and rerun. A Bicep template enables exactly that.

How it works

The template does three things:

  • Provisions a Storage Account. Creates a StorageV2 account with Standard locally-redundant storage (LRS). The account name is generated dynamically using uniqueString(resourceGroup().id), which produces a globally unique name without manual input.
  • Enables static website hosting. The storage account is configured with public blob access, allowing Azure to serve HTML files directly from blob storage at a public URL.
  • Applies a delete lock. A CanNotDelete authorization lock is scoped to the storage account, preventing accidental deletion (including by the account owner) without first removing the lock.

What I learned

  • Declarative vs. imperative. Bicep templates describe what should exist; Azure figures out the ordering and dependencies.
  • Idempotency. Running the same Bicep file repeatedly is safe. If the resources already match the template, nothing changes, which makes redeployment a no-op rather than a risk.
  • Bicep building blocks. Parameters for values that change between environments (like region), variables for computed values (like the storage account name), resource blocks that map directly to Azure resource types, and outputs that surface useful values like the deployed site URL.
  • Azure CLI. Hands-on experience deploying and managing resources from the command line rather than through the portal.

Tech stack

  • Azure Bicep — declarative infrastructure template
  • Azure Storage Account / Blob Storage — static site hosting
  • Azure CLI — deployment and resource management
  • Azure Authorization Locks — resource protection