Deploy and manage Azure compute resources
ARM Templates and Bicep Deployment Lifecycle
CoreInterpret, modify, deploy, export, and convert declarative infrastructure while reasoning about scope and dependencies.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
Declarative deployments let administrators reproduce Azure state, but safe changes require understanding parameters, resource IDs, dependencies, scope, and conversion limitations.
Must Know
- ARM templates use JSON; Bicep provides a concise declarative language that compiles to ARM template JSON.
- Parameters accept deployment-time inputs, variables derive reusable values, resources declare desired objects, and outputs return selected values.
- Resource symbolic names or IDs and dependencies determine ordering when one resource consumes another’s values.
- Deploy at the intended resource group, subscription, management group, or tenant scope and inspect what-if or deployment operations before diagnosing a failure.
- Exported templates and decompiled Bicep are starting points that require inspection; generated output is not guaranteed to reproduce every original design choice.
Compare and Distinguish
- ARM JSON vs Bicep: native JSON deployment document vs higher-level Azure declarative syntax compiled to ARM JSON.
- Parameter vs variable vs output: external input vs internal reusable expression vs value returned after deployment.
- Export vs decompile: derive a template from deployed resources or history vs translate ARM JSON syntax into Bicep.
- Declarative deployment vs imperative script: state description handled by Resource Manager vs ordered commands managed by the script author.
Scenario examples
- Scenario: The same storage pattern must deploy to test and production with different names. Think: Parameterize environment-specific inputs and keep shared expressions in variables.
- Scenario: A subnet deployment references a VNet created in the same file but starts with an invalid dependency. Think: Use a symbolic reference or explicit dependency that Resource Manager can resolve.
- Scenario: An existing resource group must become maintainable Bicep. Think: Export or obtain ARM JSON, decompile it, and then inspect and refactor the result.
Exam traps
- Bicep is not a separate deployment engine; Azure Resource Manager still performs the deployment.
- A syntactically valid file can fail because its API version, scope, property combination, policy, or dependency is invalid.
- Exported templates can contain generated names, defaults, or omissions and should not be treated as polished source.
Key takeaways
- Read declarative files by following inputs, resource identities, dependencies, properties, and outputs.
- Treat export and conversion as migration aids, then test the resulting source at the correct scope.
How it works
- Resource Manager validates the document, resolves expressions and dependency order, then invokes resource providers for each declared operation.
- Bicep compilation produces ARM JSON; modules organize reusable deployments without changing the underlying control plane.
Objects and administrative surfaces
- Deployment scope — tenant, management group, subscription, or resource group selected by the deployment command and file target scope.
- Template or Bicep file — parameters, variables, resources, modules, dependencies, conditions, loops, and outputs.
- Azure portal, CLI, or PowerShell — deployment submission, what-if preview, status, operation details, export, and conversion tools.
When to use it
- Use ARM or Bicep for repeatable, reviewable resource deployment and configuration.
- Prefer Bicep for authoring readability and retain ARM JSON when an existing integration or generated artifact requires it.
Security and governance implications
- Do not place secrets in plain parameter files or outputs; use secure inputs and managed secret references.
- The deploying principal still needs appropriate permissions at the target scope, and Policy remains effective during deployment.
How to reason about this
- Locate the failing deployment operation, read its provider error, then check scope, permissions, policy, API version, parameters, dependencies, and resource constraints.
- Use what-if to inspect proposed changes and compare the compiled JSON when Bicep behavior is unclear.
More detail
- Modify existing JSON or Bicep without breaking resource identifiers, parameter types, dependency references, or scope.
- Use portal, CLI, or PowerShell to submit deployments and understand that export or decompile output may require cleanup.
Ready for the quiz?
- Which construct should hold an environment-specific value supplied at deployment time?
- How can Resource Manager infer a deployment dependency?
- Why must a decompiled file be inspected before operational use?
Related objectives
- D3.1.S1 — Interpret an Azure Resource Manager template or a Bicep file
- D3.1.S2 — Modify an existing Azure Resource Manager template
- D3.1.S3 — Modify an existing Bicep file
- D3.1.S4 — Deploy resources by using an Azure Resource Manager template or a Bicep file
- D3.1.S5 — Export a deployment as an Azure Resource Manager template or convert an Azure Resource Manager template to a Bicep file