AZ-ADMIN-120: Bicep Fundamentals for Azure Infrastructure

Bicep is Microsoft's declarative DSL for provisioning Azure resources — the modern successor to ARM JSON. In this ~35-minute AI-guided lesson you'll learn what Bicep is, why it exists, and exactly what happens between saving a .bicep file and seeing resources appear in your subscription. You'll walk through the transpile-and-submit pipeline (Bicep source becomes ARM JSON becomes an Azure Resource Manager deployment), map the four deployment scopes (resource group, subscription, management group, tenant) to the resources that legally live at each, and pick the correct deploy command from Azure CLI or Azure PowerShell for the scope you want. You'll also see the VS Code Bicep extension surface — IntelliSense, quick-fix, the Bicep Visualizer, the Deployment Pane — and the decompile flow for migrating existing ARM JSON into Bicep. By the end of this lesson you will be able to explain how Bicep relates to ARM JSON, trace a .bicep file through the transpile pipeline into deployed Azure resources, identify which scope a given resource type deploys at, and choose the correct CLI or PowerShell command to deploy a template at each scope.

Make your Bicep files reusable across environments. In this ~35-minute AI-led lesson you will use parameters with decorators (@allowed, @minLength, @secure) to gate inputs; use variables to compute derived values without cluttering the caller; use outputs to hand values to the pipeline or a downstream module; and compose parent-child module trees drawn from local paths, the Azure Verified Modules public registry, and a private ACR-hosted module registry. You will also see how modules can target a different scope than the parent, so a subscription-level parent can deploy a resource-group-scoped storage account.

Bicep gives you three lever sets that lift a template from one-off script into production-grade infrastructure code: loops that deploy N resources from one declaration, the if expression that skips a resource on demand, and the targetScope keyword that lets a single file target a resource group, a subscription, a management group, or the whole tenant. In this ~35-minute lesson we walk through for iteration and filtered loops, if-based conditional deployment, implicit vs explicit dependencies (and why the compiler almost always figures it out for you), the existing keyword for read-only references to resources this file doesn't own, and the mechanics of the four deployment scopes plus the exact CLI command each one takes. By the end you will read and write Bicep that scales, filters, references, and deploys across the entire Azure control plane.

Not every resource your Bicep file touches is one it should create. Existing storage accounts, Key Vaults, and virtual networks already exist — you just need to reference them without redeploying. This lesson teaches the existing keyword for read-only references (including cross-resource-group scoping), the getSecret() and listKeys() pattern for pulling secrets from Key Vault at deploy-time with the @secure() parameter contract, and the private-endpoint + private-DNS-zone pattern that lets a client's mystorage.blob.core.windows.net request resolve to a private IP inside your VNet. You'll learn to distinguish private endpoints from private links and service endpoints — three terms that get conflated but do different things. By the end you'll be able to compose Bicep files that consume shared infrastructure safely, wire secrets in without exposing them, and stand up private connectivity without opening the storage account to the public internet.

You have a Bicep file that works. Now you need to ship it — safely, repeatably, and without the 3 a.m. call because a production storage account vanished. This lesson teaches you the three tools that make that possible: what-if to preview what a deploy will actually change; deployment stacks to treat a set of resources as a unit that resists accidental deletion; and CI gates (bicep build, bicep lint, PSRule.Rules.Azure, Pester) that stop bad templates before they reach Azure. You'll leave able to preview a deploy end-to-end, protect a stack with deny-settings, and gate a merge on a linter — the mechanics of Bicep at production altitude.