Make governance decisions at the right Azure scope
An Azure administrator does not make a governed environment safe simply by adding a policy or a role. The operator must know who is requesting a change, which resource scope owns it, what action is allowed, which separate controls may deny it, and how to verify the resulting state. The April 2026 AZ-104 skills outline includes managing identities and governance alongside storage, compute, networking and monitoring. This walkthrough concentrates on the governance decisions that affect all of those operational tasks rather than repeating the whole examination blueprint.
Consider a support team that wants to deploy a disposable application in a development subscription. It needs a resource group, one approved region, resource ownership tags, a narrow deployment identity and a way to examine failed changes. Before creating resources, write an acceptance contract: the environment must not permit unapproved locations; the team may modify only its resource group; and a later auditor must be able to identify the operation and its resulting cost. A pass means the effective controls were tested, not merely that the Azure portal shows a successful deployment.
Separate directory identity from resource authorization
Microsoft Entra ID manages user and group identities. Azure RBAC evaluates whether a principal may perform a management or supported data operation at a given resource scope. A user who can reset another person’s password is not automatically allowed to assign a role to an Azure subscription. Likewise, a Contributor at a resource group does not automatically become a tenant identity administrator. Work through Entra user administration as one boundary and Azure RBAC scope as another.
A role assignment consists of a principal, a role definition and a scope, with inheritance from applicable parent scopes. Management groups can organize subscriptions; subscriptions contain resource groups, which contain resources. Assigning a broad role to a management group has a much larger effect than assigning a necessary role to one resource group. Ask which action the application truly needs, whether a built-in role includes the required actions, and whether the data plane also uses a separate permission. Inspect effective assignments under the actual signed-in principal before widening scope.
For an access test, create two temporary principals or authorized test identities. Grant the first only the role required to view or update a test resource, and leave the other without that assignment. Confirm the first succeeds and the second is denied under the same scope and request. Record the role-assignment ID and any expected propagation interval. A denial should not be repaired by granting subscription Owner until the true failure stage has been identified.
Azure Policy, resource locks and RBAC enforce different constraints
Azure Policy evaluates resource configuration against assignments at the chosen scope. A deny policy can reject creation of a disallowed region even when the caller has sufficient Azure RBAC permission to create the resource type. An audit effect records noncompliance without necessarily blocking it, and some modifications or remediation workflows require a separately authorized identity. The Azure Policy workflow includes this distinction between definition, initiative, assignment, exemption, compliance evaluation and remediation.
A resource lock is not an access role. A ReadOnly or CanNotDelete lock can prevent operations that the caller’s role would otherwise permit, including changes to certain control-plane requests made by workloads. Locks inherit from applicable parent scopes and therefore need impact analysis before they are attached. Tags, by contrast, are metadata for ownership, automation or cost allocation; they do not prohibit an action by themselves. Budgets can alert recipients at thresholds but should not be described as a universal automatic shutdown switch for billable resources.
Run a small matrix on a disposable resource: first deny a proposed region through an inherited policy; then attempt a permitted deployment using a principal without the required role; finally apply a reversible lock and test the action it is intended to prevent. Capture the three different failure messages and their source. If your procedure cannot explain which control blocked which request, the operator has not completed governance QA. Never use a production subscription for a denial exercise without an approved change plan.
Diagnose a failed change without bypassing controls
Start from the error response, activity record and resource scope. For an authorization failure, inspect the principal, tenant, role and inherited assignments. For a policy denial, inspect the matching assignment and effect, its resource selectors, exemptions and compliance state. For a lock-related failure, identify the locked parent or child and the blocked operation. For quotas or unavailable resource SKUs, check the provider, region and limits rather than treating the issue as a governance misconfiguration.
Remediation is a separate operation. A policy assignment that can evaluate tags may still need a managed identity with scoped rights to modify existing resources. Approve that identity’s role before starting a task; record which resources can change and whether the effect applies only to newly created objects or also to existing ones. On completion, compare the intended properties, actual resource configuration and recorded compliance result. A task displaying “completed” is not sufficient if a source record remained noncompliant.
When a team asks to remove an apparently inconvenient control, document the business exception and evidence first. The smallest justified scope adjustment, a temporary approved exemption or a corrected deployment parameter is usually easier to audit than granting broad access or disabling an assignment for every subscription. This is a practical form of least privilege: preserve useful enforcement while allowing an authorized workload to meet a documented requirement.
Use Bicep and templates for reproducible governed deployment
Azure Resource Manager templates and Bicep describe resources declaratively. They can specify scopes, parameters, dependencies and properties, but valid syntax does not override RBAC, Azure Policy or service-provider restrictions. The Bicep change workflow demonstrates why an administrator should inspect what-if output, verify supported resource API versions and approve only the intended change before deployment.
Suppose an approved ticket requests adding a cost-center tag to a storage account. Exporting a complex existing template and deploying it unchanged can accidentally modify other properties, especially generated or read-only settings. Instead, identify the current schema, narrowly parameterize the requested field, run what-if and compare every proposed change with the ticket. Note any resource lock and any deny policy at the affected parent scope. If the tool reports unrelated replacement or deletion, stop rather than treating the result as an acceptable side effect.
Azure Blueprints (Preview) historically packaged role assignments, policy and deployment artifacts, but it is in phased retirement and is scheduled to retire January 31, 2027. Microsoft’s retirement guidance recommends deployment stacks for managed resource lifecycles and template specs for versioned artifacts. Do not teach creation of new Blueprints as a present AZ-104 administrator requirement or assume that migration leaves all prior deny-assignment behavior intact. Export and test existing definitions before the published retirement milestones.
Investigate storage and network failures at their own boundaries
A governance dashboard cannot tell you everything about a failed storage request. An account may be compliant with Azure Policy while denying a client through its firewall, a missing data-plane role, a malformed or expired SAS, or incorrect private DNS. The storage access controls provide separate checks for source network and authorization. Verify the exact endpoint, client identity, operation and returned error before changing either.
Similarly, a VM may show Running in the control plane while the guest process has stopped, a route leads to an unavailable appliance or an NSG blocks traffic. A successful deployment does not prove application reachability. Gather the DNS answer, effective routes, NSG rules, listener and return path. When the request involves a private endpoint, also verify the supported private-zone resolution path from the actual client network.
Use governance to define who may change those configurations and where, but use each service’s own diagnostics to determine what failed. Avoid inserting a more privileged role as a general fix for network or data-plane problems. Proper administration separates control-plane changes from data-plane operations, resource compliance from runtime behavior, and intended architecture from tested behavior.
Audit with the right logs, metrics and cost evidence
Azure Activity logs record management-plane operations and failures at the relevant subscription or resource scope. Azure Monitor metrics show selected performance and availability signals; Log Analytics stores queryable records from configured sources under its access and retention rules. Use Azure Monitor alerts when an owner needs a defined threshold, route and follow-up response. A generic “all resources healthy” dashboard is insufficient for diagnosing who denied a deployment or whether a new resource generated unexpected costs.
For an audit receipt, record the requested operation, actor or managed identity, timestamp, target resource ID, expected configuration, resulting state and relevant activity or diagnostic event. Do not store application secrets or personal data in widely readable logs. If a user requests privileged remediation, preserve the approval reference and the privilege scope. A source record should remain available to a reviewer who was not present during the original change; screenshots with no resource IDs, version numbers or time context rarely satisfy that need.
Cost management also needs an owner and a decision. Place suitable tags on billable resources, review observed spend versus forecast and route budget notifications to someone able to act. Azure Advisor recommendations are inputs, not universally correct commands: rightsizing an underused VM could affect reserved capacity, licensing, performance or availability. Before changing a resource, identify workloads, maintenance windows, recovery expectations and who will validate normal operation afterward.
Protect availability and recoverability independently
A policy-compliant deployment can still lose data. Availability zones and redundancy handle selected infrastructure failures, whereas backups preserve recoverable points for supported workloads. Azure Site Recovery can coordinate replication and failover where supported; it is not equivalent to a tested restore of a deleted document. The Recovery Services vault discussion helps distinguish supported workloads, regional boundaries, retention and security settings.
Use a disposable lab object to test one narrowly defined recovery procedure. Identify the protected resource, recovery point, identity allowed to restore, target location and evidence of functional success. An alert that no backup job failed cannot prove that a particular application or filesystem restored correctly. Record the time and scope of the test and mark mock steps clearly when no live Azure environment was used.
Worked exercise: govern a small storage change end to end
Imagine an approved request to create a private test storage account and allow one service identity to read a limited set of blobs. Start with a scoped resource group and an ownership tag. Decide where a location policy and data-retention policy should apply, and use a principal whose management role cannot affect other subscriptions. Draw the client network path, including private DNS where relevant. Before deployment, record the account configuration, allowed identities and expected denial for a second principal.
Use an ARM/Bicep definition to create the approved resource, with parameters for region and a suitably constrained name. Run a change preview and check whether any inherited policy, lock or quota will block creation. Once provisioned, assign the necessary storage data role at the narrowest practical resource boundary. The credential and network checks should remain separate: test a permitted read, a role-denied read from an allowed source, and a network-denied read using the same permitted identity where the service supports that test.
Enable only the monitoring you need to prove access and failures without exposing sensitive request material. Configure an alert to an appropriate test recipient, create a simple supported recovery point and restore a disposable object. Finally remove the lab through an authorized teardown procedure and check for billable resources left behind. The resulting evidence record should list requested properties, what-if results, actual configuration, negative tests, restoration result, cost exposure and cleanup confirmation.
For a review meeting, ask four questions: Did each actor have only the rights needed? Did the deployed configuration satisfy the intended Azure Policy? Were storage and network authorization separately tested? Could another administrator repeat the change or diagnose its failure from the recorded evidence? If any answer is unsupported, improve the relevant control before claiming the lab succeeded.
What this teaches an AZ-104 candidate
The useful learning outcome is the ability to classify and solve the right problem. Practice assigning scopes, reading policy results, explaining why a lock or deny assignment prevents a permitted-looking change, comparing data and management roles, and validating a controlled deployment through real evidence. These decisions connect governance to the other current AZ-104 domains without turning this article into another generic exam overview.
Use the AZ-104 credential and Microsoft’s current skills outline to confirm examination scope and active requirements. Product capabilities and region support can change, and the lab above is a proposed exercise, not a claim that the site deployed and measured an actual tenant. A defensible administrator knows both how to make a change and when not to proceed without clearer authority or evidence.