Azure / Intermediate: managed services and governance / Lesson 12

Bicep, desired state, and reviewable change

Treat infrastructure as a versioned contract with scope, parameters, dependencies, and a reviewed change plan. Separate syntax, what-if analysis, policy, deployment, and successful workload behavior.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain declarative resources and versioned API assumptions.
Review changes and destructive consequences before deployment.
State what offline validation cannot prove.

Desired state is an input to a management system

Bicep is a declarative language for Azure Resource Manager deployments. A file describes resources, properties, parameters, modules, and dependencies under a target scope. It is not a sequence of shell clicks, and source control alone does not approve the resulting change. Resource provider API versions and feature support are part of the contract. Reuse should preserve ownership and scope rather than hiding privileged operations inside an opaque module. Separate secret references and protected parameter handling from ordinary outputs. A syntactically plausible template can still fail policy, quota, permissions, provider registration, capacity, or regional availability checks.

Read a declaration without deploying it

The illustrative fragment declares a storage account candidate with a parameterized name, HTTPS-only transport, minimum TLS setting, and disabled blob public access. Its LRS choice does not establish zone or regional recovery, and the fragment omits a complete identity, private networking, lifecycle, and backup design. The API version is an explicit example, not a claim that it is the newest. This course neither compiles Bicep nor calls ARM, what-if, or deployment APIs. Treat the expected observation as a reading of the authored declaration, not provider validation or proof the resource can be created in a particular subscription.

bicep Unexecuted Bicep fragment with stated omissions

targetScope = 'resourceGroup'
param storageName string
param location string
resource data 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageName
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
  }
}

Expected output

illustrative storage declaration only; not compiled or deployed

All names and parameters require future service-aware verification. The fragment does not create resources, prove private access, or provide a price.

A change plan is evidence to review, not approval

Review additions, modifications, replacement risks, removals, and effects on existing data. What-if analysis can help describe predicted changes under its documented limitations, but it still needs authorized access and does not guarantee successful deployment or complete workload behavior. Unknown or provider-specific results need interpretation. A policy-compliant resource can still expose the wrong data or miss a recovery requirement. Keep the intended target scope, identity, parameters, and artifact version with the reviewed plan so implementation cannot silently switch to another environment after approval. No what-if operation is run in this course.

Use a small model to expose change-review questions

The offline comparison detects that a synthetic desired region differs from the recorded model. It does not know whether Azure would modify, recreate, reject, or otherwise handle the corresponding resource; that depends on the actual resource type and property contract. Label such a difference as requiring review rather than assuming it is an in-place safe edit. JSON shape checks and arithmetic are useful early feedback, but they cannot validate Azure schema, policy, quotas, drift, or permissions. Never turn the word unchanged in a local model into proof the live environment matches it.

python Offline desired-state comparison

recorded = {"region": "region-a", "public_access": False}
desired = {"region": "region-b", "public_access": False}
changed = sorted(key for key in desired if desired[key] != recorded.get(key))
print(",".join(changed))
print("review required" if changed else "no modeled change")

Expected output

region
review required

The model reports a difference only. It makes no Azure replacement or deployment prediction.

Reproducibility includes configuration and recovery

Keep source, module versions, parameters, service assumptions, and access approvals traceable to the intended environment. Define drift handling and how out-of-band emergency changes are reconciled. Deleting a deployment record does not mean the managed resources disappear, and reverting source does not necessarily restore deleted data. Rollback must distinguish code/configuration changes from irreversible data effects. A future authorized process should validate the resulting resource state and user outcome, not only a successful control-plane operation. This course makes no infrastructure changes and provides no executable cloud command; its examples remain reference-only design material.

Common errors and fixes

A what-if result is treated as guaranteed successful deployment

Why it happens: Predicted management changes are confused with complete execution.
How to fix it: Review limitations and verify authorized implementation outcomes separately.
Prevent it next time: Keep scope, identity, parameters, and artifact version tied to review.

A region edit is assumed nondestructive

Why it happens: Property differences are interpreted without the resource contract.
How to fix it: Inspect actual resource update/replacement behavior before approval.
Prevent it next time: Flag data and dependency consequences in the change plan.

Secrets are placed in outputs or ordinary source parameters

Why it happens: Infrastructure metadata is treated as harmless public text.
How to fix it: Use protected handling and reviewed secret-reference designs.
Prevent it next time: Review logs, plans, outputs, and source for sensitive exposure.

Check your understanding

1. What does the offline region difference establish?

Show worked solution

It establishes that the two literal models differ at region and require review. It does not predict Azure update semantics, resource replacement, availability, or cost. Determine those from the actual resource/API contract and an authorized change process; preserve data-recovery implications explicitly.

2. Why is a successful ARM operation not the whole acceptance test?