A Bicep deployment can finish successfully and still leave an Azure resource in a configuration the team did not intend. Imagine a request to add an ownership tag to a storage account. The administrator edits the Bicep file, previews a small change, and deploys it. Later, an application loses access because the deployed resource definition also changed a network property. The visible request was simple; the resource declaration was not.
That is the central skill in administering infrastructure as code: understand the existing resource, predict the full effect of the proposed definition, and verify the actual state after deployment. The published Microsoft AZ-104 objectives include interpreting, modifying, exporting and deploying ARM templates and Bicep files. The tasks are practical administrative responsibilities, not a requirement to memorize one command without understanding its effect.
Read the resource and its management boundaries first
Before modifying a template, identify the subscription, resource group, deployment identity, resource provider, location, resource name and existing dependencies. For a storage account, those dependencies may include private endpoints, DNS records, backup processes, application identities, network access restrictions and monitoring settings. An apparently harmless redeployment can affect consumers if a nondefault property is omitted or reset.
Ask who owns the resource definition. If a platform team maintains a shared Bicep module, a team-specific copy with different defaults is likely to create drift. If an Azure Policy assignment requires private access, changing the Bicep file to request public access will not make that policy disappear. Similarly, a resource lock or missing RBAC permission can prevent an otherwise valid deployment. These failures should be diagnosed at the Azure RBAC scope boundary, not disguised by granting an administrator subscription-wide Owner access.
Record the current resource configuration and an approved rollback plan. Exporting an ARM template may help reconstruct some properties, but it is not a complete application backup: service data, secrets, runtime dependencies and some generated or read-only settings require separate handling.
Know what Bicep and ARM JSON actually describe
An ARM JSON template describes Azure resources and their properties declaratively. Bicep is a more concise language for producing ARM deployments, with features such as symbolic resource names, parameters, modules and outputs. The resource provider still validates whether an API version, SKU, property combination and region are supported; valid Bicep syntax alone is not sufficient.
A declaration identifies a resource type and API version, a scope, a name, and the desired state. Parameters should express choices that genuinely vary by environment, such as a resource name or approved SKU. They should not become a convenient channel for plaintext credentials. Use supported secure references and service-managed identity where possible; review what gets written to deployment history and outputs.
Modules are useful when several deployments share a clear resource contract. They become harmful when a developer must open many files to discover which module sets public network access or which outputs expose a resource ID. Keep inputs, resource ownership, dependencies and output semantics explicit enough that another administrator can review the effect before a deployment runs.
Work through one change request instead of several disconnected exercises
Assume a team asks to add an owner tag to a test storage account. The existing Bicep definition also specifies a storage SKU, a minimum TLS version and private network restrictions. A safe review compares the entire current definition with the proposed one. The administrator must not interpret incremental deployment as a tag-only patch: Azure Resource Manager reapplies properties in a resource declaration, and omitted nondefault properties may be reset. Microsoft’s deployment-mode guidance explicitly warns about that behavior.
A simplified review checklist for the request is:
- Change intent: add or correct the ownership tag; leave all network, encryption, redundancy and identity settings unchanged.
- Resource identity: confirm subscription, resource group and storage account ID before planning a write.
- Template completeness: inspect every nondefault resource property, including properties unrelated to the tag.
- Governance: identify relevant role assignments, inherited Azure Policy restrictions and resource locks.
- Recovery: retain the preceding Bicep revision and a verified snapshot of the affected live configuration.
Do not copy the existing resource’s live access keys into a template simply because an export or portal screen exposes them elsewhere. The reviewed artifact should describe intended infrastructure state, not collect secrets.
Use what-if to interrogate the proposed change
At resource-group scope, an administrator can preview a Bicep deployment through the Azure CLI:
az deployment group what-if \
--resource-group rg-az104-lab \
--template-file main.bicep \
--parameters storageName=stexamplelab001The command is illustrative; no Azure environment has been accessed or tested for this article. Supply real parameters only through approved mechanisms, and verify that the deployment principal has the required permissions. Microsoft’s Bicep what-if documentation explains that the operation predicts changes without applying them, and that it can report incomplete analyses or unresolved expressions. Treat its output as evidence to inspect—not a guarantee that nothing will change.
For the tag request, a reviewer should expect a narrowly justified modification to the existing storage account, not a new account, an unrelated network change, or deletion of another resource. If what-if reports changes to properties that were not in the request, stop and reconcile the template with the live configuration. If it cannot analyze a nested or dynamically resolved property, document that uncertainty rather than marking the preview as clean.
The preview and final deployment are separate moments. Another administrator could change the resource between them. Preserve the approved source revision and repeat the comparison if the review window has expired or significant drift is detected. Use az deployment group create --confirm-with-what-if where it suits the approved workflow, but retain ordinary change-control authorization as well.
Diagnose failures by the layer that rejected the operation
A deployment can fail for reasons that look alike in an automation dashboard but require different corrections:
| Evidence | Likely boundary | Safe next step |
|---|---|---|
The principal lacks a required Microsoft.Resources/deployments or target-resource operation |
Azure RBAC | Inspect the identity, action and effective scope; request only the missing approved permission |
| A policy denies a resource location, SKU or public access setting | Azure Policy | Read the evaluated assignment and correct the intended configuration or use the documented exception process |
| The resource provider rejects a property or API version | Provider/schema compatibility | Check current resource documentation and supported property combinations |
| A locked resource cannot be updated or removed | Resource lock | Review the lock’s owner, scope and maintenance procedure |
| The deployment succeeded but the application cannot reach its dependency | Runtime/network/data plane | Compare actual resource settings, route, DNS, identity and service health with the prechange baseline |
Azure Policy and RBAC can both block a configuration change, but they are not the same authorization mechanism. Broadening access will not resolve a Policy-denied property, and altering the template cannot grant the deployment identity a missing role. Classifying the denial correctly is a more useful administrative skill than repeatedly rerunning a failed pipeline.
Verify the result and make rollback executable
After an approved deployment, compare the live resource with both the intended change and the what-if prediction. Confirm that the tag exists, that TLS and network restrictions remain intact, and that the dependent application still connects through its expected path. A green deployment status confirms the control-plane request completed; it does not prove the business application is healthy.
The change record should preserve the source revision, deployment scope, parameter sources without secrets, expected modification, what-if findings, actual resource properties, observed application checks and rollback owner. If an unintended property changed, restore the approved complete definition or follow the service-specific recovery process; do not assume that reversing one tag value automatically restores network access or dependent data.
Before accepting a Bicep change as ready for routine use, test a realistic failure in an isolated environment: a denied role assignment, an inherited Policy rejection, or a discrepancy between an exported template and current resource settings. The expected result is not a successful deployment at all costs. It is an accurate diagnosis, a controlled correction and clear evidence that unrelated production behavior was preserved.