Azure Resource Manager
Azure Resource Manager is the deployment and management layer for everything in Azure. Every action — through the portal, CLI, SDKs, or a template — goes through ARM, which authenticates it, applies RBAC and policy, and orchestrates the change. Understanding ARM is understanding how all of Azure is actually operated underneath the tools.
Its practical face is infrastructure as code. You declare the resources you want in an ARM template or in Bicep, and ARM makes reality match the declaration — repeatably, reviewably, and without click-by-click portal work. Managing production infrastructure by hand in the portal, rather than through ARM-based code, is the anti-pattern this service exists to retire.
Resource Model and Resource Groups
Every Azure resource lives in a resource group, which is a management and lifecycle boundary — resources that share a group typically share a fate (deleted together) and a set of access and policy assignments. ARM organizes the world as subscriptions containing resource groups containing resources, and that hierarchy is where RBAC, policy, and billing attach.
ARM Templates and Bicep
Infrastructure is declared either in ARM templates (JSON — verbose and powerful) or in Bicep (a concise domain-specific language that compiles to ARM JSON). Bicep is the modern authoring choice: far more readable, with modules and type checking, for the same underlying deployment. New infrastructure-as-code should be written in Bicep unless an existing investment dictates JSON.
Deployment Modes
ARM deploys in incremental mode (add and update the declared resources, leave others alone) or complete mode (make the resource group match the template exactly, deleting anything not declared). Incremental is the safe default; complete mode is powerful and dangerous — running it with an incomplete template deletes resources you forgot to include.
Access, Tags, and Locks
Because all operations flow through ARM, it is where RBAC role assignments, resource tags (for cost allocation and organization), and resource locks (CanNotDelete or ReadOnly, to prevent accidental changes) are applied. A delete lock on a critical resource group is a cheap, effective guard against the fat-fingered deletion that ARM would otherwise dutifully execute.
Bicep — Concise, readable DSL with modules and type checking; compiles to ARM JSON. The modern authoring choice for new IaC.
ARM templates (JSON) — The underlying declarative format — verbose but fully capable. Use it where an existing JSON investment or tooling requires it.
- Managing production infrastructure by hand in the portal instead of as ARM-based code, losing repeatability and review.
- Running a complete-mode deployment with an incomplete template, deleting resources that were simply omitted.
- Authoring new infrastructure as verbose ARM JSON when Bicep would be far more readable and maintainable.
- Putting unrelated resources with different lifecycles in one resource group, so a group-level delete takes out too much.
- Skipping resource locks on critical resources, leaving them one mistaken click from deletion.
- Neglecting tags, then being unable to allocate cost or identify ownership across the estate.
- Manage infrastructure as code through ARM, not by hand in the portal.
- Author new infrastructure in Bicep for readability, modules, and type checking.
- Use incremental deployment mode by default; reserve complete mode for when you intend to prune to the template.
- Group resources by shared lifecycle so a resource-group operation affects the right set.
- Apply delete or read-only locks to critical resources and groups.
- Tag resources consistently for cost allocation, ownership, and organization.
Knowledge Check
What is the risk of a complete-mode ARM deployment?
- It makes the resource group match the template exactly, deleting any resource not declared in it
- It only adds brand-new resources to the group and never updates or deletes any of the existing ones
- It bypasses RBAC and Azure Policy checks for every resource in the group
- It cannot deploy more than one resource in a single template run
Why choose Bicep over ARM template JSON for new infrastructure?
- It is a concise, readable DSL with modules and type checking that compiles to the same ARM JSON
- It deploys through a separate, faster control plane that is wholly independent of the ARM REST API
- It is the only template format that can target Azure resource groups at all
- It bypasses the need for RBAC permissions when you deploy
What is a resource lock used for?
- Preventing accidental deletion or modification of a critical resource (CanNotDelete or ReadOnly)
- Encrypting a resource's own stored data at rest using a customer-managed key held in Azure Key Vault
- Restricting which Azure regions a resource is permitted to be deployed into across the group
- Granting a specific user access to manage the resource
You got correct