Azure Resource Manager is the management layer behind many Azure changes. Whether an administrator uses the portal, Azure CLI, PowerShell, Bicep or an ARM template, the request is evaluated at a defined management scope and processed through Azure resource providers. That shared layer explains why identity, Azure RBAC, Azure Policy, resource groups, locks and deployment history can govern different Azure services without each service inventing a separate administration model.
For Microsoft AZ-104 Exam, the practical question is not merely how to deploy a resource but how to make a change safely: who is allowed to request it, which policy constrains the configuration, where dependencies exist, what the operation actually changed and how a team can review the result. ARM manages infrastructure requests; it is not a replacement for the application or data services the infrastructure runs.
Understand what happens between a request and a resource
A fictional university is moving a departmental research web service into Azure. An administrator applies a deployment declaring an App Service instance, storage resources and a monitoring workspace. Resource Manager receives the requested definitions at the relevant scope, evaluates applicable permissions and policies, and coordinates operations through the registered resource providers. A successfully completed deployment says the infrastructure operations were accepted; it does not guarantee that the research application will start, that its database credentials work or that students can reach it.
This distinction separates Azure’s control plane from the resource’s data plane and runtime. An operator may have authority to configure a storage account while lacking permission to read protected blobs. A network deployment can succeed while application traffic is denied. A role assignment can exist while a policy blocks an attempted resource configuration. Diagnose these as separate enforcement questions rather than treating “Azure returned an error” as a single category.
The management API offers consistency across many services, but specific resource types still have their own properties, limits and behavior. A plan should identify the relevant resource provider and supported API version. A template copied from an old course can fail or create an unintended state when its resource type, regional availability or property schema no longer matches the current service.
Choose the scope that matches the administrative responsibility
Azure has management groups, subscriptions, resource groups and resources. Settings applied to a broader scope can affect the descendants of that scope, subject to the particular control and its rules. A university may use a management group for campus-wide governance, subscriptions to separate billing and delegated administration, resource groups to manage related workloads, and resource-level permissions for tightly scoped duties.
A resource group is a management container, not a statement that every resource inside it runs in the same Azure region. The group’s location holds its metadata. Resources belonging to it may be deployed to different supported regions. Treating the group’s location as a workload placement rule can lead to misleading assumptions about resiliency and data residency.
Choose group boundaries with lifecycle and responsibility in mind. Resources that are often deployed or retired together may belong in one group; resources whose lifecycle is independent may need separate groups. Deleting a resource group initiates deletion of its contained resources, so a group used as a temporary playground should not also contain a shared production database simply because both support the same demonstration.
A workload may legitimately depend on resources in other groups. The university’s web application can live in a departmental resource group while an approved monitoring workspace is managed by a central platform team. Cross-group dependencies should be explicit, and permissions should not be expanded across the whole subscription merely because two resources communicate.
RBAC, policy and locks are distinct control mechanisms
Azure RBAC determines which management operations a principal may perform at a scope. Microsoft Entra ID supplies the cloud identity and authentication context for many such principals. The existence of a valid identity does not grant every role, and an application managed identity may need different data-plane permissions from the human who deploys its resources.
Azure Policy evaluates resource configuration against rules assigned at applicable scopes. An administrator with adequate Contributor permissions may still be unable to create a resource in a disallowed region or enable a prohibited public endpoint. The correct response is to inspect the policy and intended standard, not grant subscription-wide Owner privileges to try to bypass it.
Resource locks can help prevent accidental deletion or modification through the management plane. A CanNotDelete lock is different from a ReadOnly lock: the first is focused on deletion, while the second may block otherwise legitimate updates. Locks can interfere with automation and some service operations, so they require testing and ownership. They do not replace data-plane authorization or protect every individual record inside a resource from application-level deletion.
For the university, define one test identity that can update only the departmental web application, a policy that restricts an unsafe configuration, and an appropriate protection for a shared long-lived resource. Then verify a permitted update, a policy denial and an attempted prohibited deletion separately. Three controls are effective only when each produces the intended result.
Use tags for classification, not as an automatic security boundary
Tags are key-value metadata useful for identifying ownership, environment, workload or cost center. The university might tag resources with department, cost owner and service. A resource-group tag is not automatically inherited by its contained resources merely because they belong to the group; tag inheritance or propagation needs a deliberate policy or management process where it is required.
Tags also do not themselves grant Azure RBAC access or define an isolated network. A useful tag naming standard should specify who may change tags, how values are reviewed and which cost or inventory reports depend on them. A label that says “production” does not enforce production security unless another approved control actually uses and verifies the value.
Cost reporting may group expenses by tags, but missing or inconsistent tags can create misleading budget totals. Before basing decisions on a report, check whether the relevant resource types are tagged consistently, which costs are attributed and what resources escaped classification. Metadata is evidence for accountability only when it is maintained.
Describe infrastructure as desired state with ARM or Bicep
ARM JSON templates and Bicep define resource declarations, parameters, outputs and relationships in a repeatable way. A deployment can be targeted to supported scopes, with dependencies determining the order in which related resources are provisioned. Bicep compiles to ARM template JSON rather than being an unrelated management system.
For the research application, the team can declare an App Service plan, web app, storage and monitoring configuration rather than perform every step manually. Parameters can vary permitted region, resource names and size by environment, while modules can separate reusable components. Avoid hardcoding secrets or overly broad identity assignments simply to make the deployment run unattended.
Use ARM template deployment principles to understand the infrastructure result, not just the syntax. Idempotent desired-state behavior helps reduce accidental configuration drift, but a repeated deployment is not a complete rollback mechanism. A resource’s properties may be updated, a prior change may have altered state, and dependent services may have their own migration or recovery requirements.
The template should support ordinary change review. A reviewer needs to see which resources may be created, changed or deleted, which identities and policies will apply, and what other services the workload needs. A release that is syntactically valid but exposes storage publicly or increases privileges beyond the approved standard should fail governance review.
Use what-if previews and deployment evidence with appropriate caution
ARM deployment what-if can show proposed infrastructure differences before execution, helping reviewers see what may change. It is a preview of management operations, not a complete proof that the application will remain healthy or every data-plane permission will work. Some resource-provider behaviors or complex expressions can affect preview accuracy, so interpret the output with current platform documentation and appropriate tests.
After deployment, inspect the operation record and effective configuration. A failure can arise because the principal lacks permission, the requested configuration conflicts with Azure Policy, a resource provider rejects a property, or a dependency is missing or unavailable. The evidence should lead to the relevant layer rather than an indiscriminate role escalation or a blind template retry.
A safe change record includes the approved intended state, reviewed preview, execution result, relevant identifiers, and a test of the workload after the change. If the web application uses a private storage endpoint, validate the path from the actual application environment. If it uses a managed identity, verify both the intended authorization and an explicitly prohibited read.
Use an appropriate monitoring signal to detect configuration effects. Azure Monitor and platform activity records can expose different parts of the change, but a management success event does not prove that all user transactions complete. Correlate it with service metrics, application logs and an end-to-end operation when the risk warrants it.
Govern deployment and runtime as separate parts of one service
Resource Manager can help organize an Azure environment, but the service behind it still requires patching, scaling, backup, access review and failure response. A VM deployment defines compute and related infrastructure; the guest application must still be configured and maintained. A storage deployment creates a resource; the data access model and historical recovery protections must still be tested.
The distinction becomes visible in Azure compute operations. An administrator can apply a correct VM definition and still encounter a stopped service, incorrect guest firewall or unavailable backend. Those failures belong to the operating environment, not necessarily the ARM deployment itself.
Business ownership also persists beyond the first successful release. Who can approve a new region, broadening public exposure, changes to resource locks or exceptions to required tags? Who reviews the cost of a larger VM and who owns rollback after a damaged deployment? These responsibilities make governance practical rather than a template comment.
Diagnose one failed change by locating the enforcement point
Suppose the university attempts to deploy a web app into a region outside the authorized list. The management request is rejected even though the deployment identity has Contributor on the resource group. Inspect the policy assignment and requested location before altering any role. Next suppose the approved deployment succeeds but the app cannot read its database. Now investigate the application’s identity, data permission, endpoint and runtime configuration instead of reopening the policy question.
Finally, imagine the team removes the disposable resource group after testing and discovers a shared resource was mistakenly included. The incident reveals a lifecycle and management-scope problem, not a need to disable every deletion safeguard. A better design separates durable shared resources from temporary workloads and makes deletion review part of the release process.
The value of Azure Resource Manager is the consistency with which it organizes and governs infrastructure change. An administrator who understands scope, RBAC, policy, locks, tags, declarative deployment and effective-state verification can make safer decisions across services. The management plane tells the team what Azure accepted; responsible operation still has to prove that the resulting workload behaves as intended.