Bicep is Azure's declarative infrastructure language. You describe the desired Azure resources; Azure Resource Manager calculates dependencies and applies the deployment. Bicep compiles to ARM template JSON, removing much of the verbosity while preserving native Azure resource-provider support.
Lab: 45 minutes · Cost: Bicep/ARM deployment has no separate charge; declared resources do · Creates: resource group, storage account, and optional diagnostics.
You state what should exist, not a sequence of portal clicks. Re-running a well-designed template with the same inputs converges on the same declared configuration. Azure still cannot automatically make every change safe; changing a name may replace a resource, and data-plane content is often outside ARM.
Choose a current stable API version supported by the resource. Newest is not automatically safest; preview APIs need explicit justification.
Ways to build
Choose the Azure tool you want to use. The underlying resource stays the same.
Review what-if. It can contain noise and cannot predict every data-plane or runtime consequence, but it is an important gate.
Split by stable ownership and reusable capability, not one file per resource. Example:
Publish mature modules to a private Bicep registry with versions. Keep environment differences in parameter files, but never commit secret parameter values.
Set targetScope to resourceGroup, subscription, managementGroup, or tenant. A subscription deployment can create resource groups and call modules at those group scopes. Use existing resources to reference shared infrastructure without trying to own its lifecycle.
Bicep infers dependencies when one resource references another. Use explicit dependsOn only when no reference expresses the real relationship. Conditions create optional components; loops create collections. Avoid a boolean forest that turns one template into many untestable architectures.
Mark sensitive parameters with @secure(), but remember values can still reach target resource configuration and deployment operations. Prefer managed identity and Key Vault references. Never put listKeys() results in outputs. Limit who can read deployment history.
Incremental resource-group deployment adds/updates declared resources and generally leaves undeclared resources. Complete mode has destructive behavior and requires great care. Azure deployment stacks provide managed-resource tracking and controlled deny/delete behaviors for supported scenarios. Test deletion semantics in a disposable subscription.