Azure Governance for AZ-104: Policies, Locks and Budgets
Azure Governance for AZ-104: Policies, Locks and Budgets
A team can have permission to deploy an Azure virtual machine and still be unable to create it. Another team can own a resource group and still be prevented from deleting a storage account. A third can stay within every technical policy and run past its monthly cloud budget. These are not variations of one access-control problem. They are different administrative controls doing different jobs.
The AZ-104 exam tests the judgment to distinguish those controls. Microsoft’s April 2026 administrator objectives include resource roles and scope, management groups, subscriptions, Azure Policy, locks, tags and cost management. Rather than memorizing isolated screens, build one governed workload and deliberately make it violate each kind of constraint.
A subscription is a management boundary, not a substitute for design
Imagine a retailer with separate production and development subscriptions. A management group can organize those subscriptions under common governance. Within each subscription, resource groups provide useful lifecycle and permission scopes for an application or environment; an individual resource remains the most targeted scope. Roles and policy assignments can inherit from broader scopes, so a restriction placed at a management group may affect a new production resource group even though no one configured it locally.
Decide the boundaries before granting privileges. A team responsible for one application normally does not need subscription-wide Owner. Its deployment identity may need Contributor on a designated resource group, while an access administrator controls role assignments. That separation lets operators change infrastructure without also giving them power to expand everyone else’s access. Review inherited assignments as carefully as direct ones: troubleshooting only at the resource-group level can conceal a policy or role inherited from above.
Resource groups do not automatically establish an isolated security perimeter or guarantee that every dependent service lives together. A resource group has a location for its own metadata; contained resources can be in supported locations of their own. Use grouping to clarify ownership, deployment lifecycle, cost analysis and cleanup, while making networking and identity boundaries explicit where they actually matter.
RBAC answers who may act; Azure Policy answers which configurations comply
Azure role-based access control evaluates a principal, a role definition and a scope. Its purpose is authorization: may this operator create a virtual network, read a resource or update a virtual machine? Azure Policy and RBAC act at different stages. Policy can reject a configuration even when the caller is authorized to submit it. A Contributor assignment cannot override a valid deny policy simply because it allows the underlying resource action.
Suppose the organization requires approved Azure regions and a particular tag on production storage accounts. The deployment identity may be fully authorized to create storage, but a policy with the deny effect can prevent an out-of-region account. That is not an identity failure. The Activity Log and deployment details should indicate a policy evaluation problem. Granting Owner to make the error disappear is both ineffective and dangerous. Correct the requested configuration or have the governance owner review an exemption through the organization’s change process.
In the opposite case, a policy could report the proposed resource as compliant while the principal still lacks permission to create it. Start troubleshooting by identifying the exact operation, the authenticated principal, the scope and the applicable role definition. Only then inspect policies and resource settings. Keeping those questions separate is one of the most useful habits in AZ-104 administration.
Policy effects have different operational consequences
An audit policy provides visibility without stopping the relevant resource operation. A deny policy rejects non-compliant create or update requests. A modify policy can change specified properties during evaluation, subject to its rule and identity requirements; a deployIfNotExists policy can deploy related resources such as diagnostic settings under an appropriately configured managed identity. Those effects are not interchangeable just because they appear together in a policy initiative.
A sensible rollout uses an audit-style assignment to understand current compliance before enforcing a disruptive restriction. Suppose a policy aims to attach diagnostics to all supported virtual machines. Ask what resources it examines, how existence conditions are evaluated, which identity has the rights for remediation, and what happens to already-deployed machines. Marking a resource non-compliant does not necessarily remediate it. The administrator may need a remediation task and appropriate permissions to reach the intended state.
Test policy at the narrowest useful scope before inheriting it broadly. Capture a deployment that should be accepted and another that should fail. Verify the reported assignment and effect, rather than concluding that an error code alone proves the cause. That evidence protects teams from an expensive surprise when a development policy becomes production-wide.
Resource locks guard management actions, not every byte of data
Azure resource locks can be applied at subscription, resource-group and resource scopes. A CanNotDelete lock prevents authorized users from deleting the locked resource through management operations while still permitting permitted changes. A ReadOnly lock is more restrictive for management operations. Locks inherit through their applicable resource hierarchy, and the most restrictive effective lock matters. They apply even to people with high Azure RBAC privileges until the lock is removed by someone authorized to manage locks.
A critical trap is believing a lock on a storage account makes every blob undeletable. Azure distinguishes the management plane from the storage data plane. A lock can prevent management-plane deletion of the storage account without necessarily stopping an appropriately authorized data-plane request to delete a blob. Protecting business records therefore needs data retention, versioning, soft delete or immutability features as appropriate—not just a lock icon in the portal.
Locks also have operational side effects. A read-only lock can interrupt management operations that monitoring or another service must perform; a delete lock on a group containing Azure Backup-managed resources can interfere with cleanup of restore points. Practice in a disposable environment: apply the lock, test the specific update or delete request, review the failure and remove it through a controlled change. Do not copy a production-level lock policy into a lab without a tested exit path.
Tags and budgets improve accountability but do not enforce spending limits by themselves
Tags help people identify environment, owner, service and cost center, but a naming convention is not the same as enforced governance. Decide which tag keys are required and how values will remain consistent. A policy can audit or enforce tag requirements; a separate policy may be needed to inherit or modify tags under defined conditions. Do not assume that a tag on a resource group magically appears on every child resource.
A budget is a visibility and notification mechanism. Azure Cost Management can notify designated recipients when actual or forecast spending crosses configured thresholds, but a standard budget alert does not automatically stop consumption. If a development lab runs expensive resources overnight, receiving an alert is not the same as having a service-level shutdown policy. A sound cost control combines ownership, tags, budgets, resource scheduling and someone accountable for responding.
Test both an actual-spend threshold and a forecast threshold in the context where budgets are supported. Explain the delay between resource usage and available cost data to stakeholders: a budget is not a real-time circuit breaker. When a project moves subscriptions or adds shared network components, revisit which costs the budget includes rather than assuming the original scope still represents the application’s full cost.
Run one realistic governance lab
Create a disposable resource group named for a test workload and document its subscription, owner and region. Give an operator group a scoped role that allows routine deployment, while retaining role-assignment control separately. Add an Azure Policy assignment that restricts a configuration, such as permitted locations or required metadata, then attempt a non-compliant deployment. Capture the actual policy assignment responsible for the denial. Repeat the deployment after correcting only that configuration.
Next, apply a CanNotDelete lock to a test resource and attempt a management-plane deletion as an authorized operator. Record how the result differs from the earlier policy denial. Add an owner and environment tag to the resources and inspect the policy compliance view. Create a budget for the appropriate cost scope and define a notification recipient. This lab does not require risking production workloads; its purpose is to demonstrate cause and effect in a system you can safely dismantle.
Finish by assigning a narrower role than you initially used and checking whether the operator can still perform the required maintenance. Remove the lock, clean up test resources and document the order of removal. A useful laboratory record contains the identity, scope, requested action, observed error, root control and corrective action—not only screenshots of successful configurations.
Diagnose a failed deployment before changing permissions
When a deployment fails, first establish the caller and requested operation. A 403 error can come from authorization or from another policy-based restriction, so inspect the deployment’s detailed failure before assuming the cause. If the caller is permitted, check the effective policy assignments, including inherited management-group restrictions. Then test whether the resource is subject to a lock, whether the requested SKU or location is supported and whether the subscription has an applicable quota.
For example, an application owner changes a storage account redundancy setting and receives a failure. The correct explanation might be that the selected account type or region does not support the requested combination. It would be poor administration to broaden RBAC or exempt governance rules without investigating service capability first. Different Azure failures can look similar in a condensed portal notification; examine the underlying operation and resource provider response.
A good incident note explains the least disruptive correction and any required approval. Fixing the wrong layer can turn an ordinary deployment issue into a persistent security exception.
Distinguish directory administration from Azure resource governance
Microsoft Entra roles control directory activities such as user and group management. Azure resource roles control operations against resources under Azure Resource Manager. A user administrator in the directory does not automatically become an Azure subscription Owner, and an Azure resource Contributor does not automatically gain broad authority to manage tenant identities. For a detailed practical boundary, the existing Azure RBAC and Entra role discussion deals with the separate scope and identity systems.
The difference matters when a new employee joins an operations group. The identity team may handle account lifecycle and self-service password reset settings; the subscription administrator grants or removes access to defined resource scopes. Combine the two controls deliberately. If a request crosses the boundary, document the two distinct authorizations instead of granting a convenient but overpowered role.
Close changes with evidence, ownership and a tested rollback
A governance configuration is not complete when the portal displays a green deployment notification. Record the policy version and scope, the role assignment’s reason and owner, any lock exceptions, budget alert recipients and the expected response to a threshold event. Test that a compliant deployment succeeds and a deliberately non-compliant one fails in the predicted way. If a later requirement changes, the team needs to know which policy assignment should be modified rather than disabling controls blindly.
Strong AZ-104 preparation asks the same questions an experienced administrator asks during a change review: What can this identity do? What configurations are prohibited? What could be deleted? Who notices unexpected spending? How would we reverse an overly restrictive setting? Those are separate responsibilities, and knowing how they interact is more valuable than memorizing which portal blade contains each setting.
- Category: Certifications Microsoft
- Tags: AZ-104
