Azure governance becomes difficult when an environment grows beyond a few subscriptions and resource groups. Administrators are no longer making isolated configuration choices; they are deciding which rules should apply broadly, where exceptions belong and how to prove that deployed resources continue to satisfy organizational requirements. For the AZ-104 exam, Azure Policy is central to that job because it turns governance intent into rules that Azure can evaluate at scale.
The important distinction is that governance is broader than simply blocking a bad deployment. It includes organizing subscriptions, controlling access, enforcing standards, tracking compliance, protecting critical resources and understanding how assignments inherit through Azure’s scope hierarchy. Candidates who understand the relationship between management groups, subscriptions, resource groups, Azure RBAC and Azure Policy can reason through scenarios instead of memorizing portal steps.
Start with scope before thinking about policy definitions
Azure governance is hierarchical. A policy assignment at a management group can affect subscriptions beneath it, and a subscription-level assignment can affect its resource groups and resources. That makes scope one of the most important design decisions. A rule placed too low leaves gaps. A rule placed too high can create unintended restrictions across workloads that have different requirements.
Management groups are useful when several subscriptions need the same baseline. An enterprise may separate production, sandbox and regulated workloads into different branches so that policy and role assignments follow those operating models rather than the company’s reporting chart. This keeps governance connected to technical and compliance needs. The broader Microsoft Azure infrastructure certifications path builds on the same idea: administrators need to understand how individual resources fit into an operating model that can be managed repeatedly.
Inheritance is powerful because it reduces duplication, but it also makes troubleshooting more subtle. A resource group administrator may see a policy effect that was assigned several scopes above. The correct troubleshooting habit is to inspect the assignment scope, definition or initiative, parameters, exemptions and compliance result rather than assuming the resource-group configuration is the whole story.
Azure Policy evaluates resource state against declared rules
An Azure Policy definition describes a condition and an effect. The condition identifies resource properties that matter, while the effect determines what Azure should do when those properties meet the condition. Effects can audit resources, deny deployments, append or modify selected properties, deploy supporting resources when required, or mark resources as noncompliant for later remediation.
The exam value lies in choosing the effect that matches the requirement. If the organization first wants visibility into resources that lack required tags, an audit effect is less disruptive than an immediate deny. If every new resource must use an approved region, deny may be appropriate. If a required monitoring component can be deployed automatically, a deployment-oriented effect may be a better fit than simply reporting noncompliance.
Policy therefore supports both prevention and continuous assessment. Existing resources can be evaluated against a new assignment, and administrators can review compliance rather than assuming governance begins only at creation time. This is one reason Azure Policy is not a substitute for change management: policy supplies technical enforcement and evidence, while the organization still needs a process for approving standards and exceptions.
Initiatives make a governance baseline easier to operate
A large environment quickly accumulates many policy definitions. Assigning each one separately creates administrative noise and makes it harder to understand the baseline that a scope is supposed to follow. An initiative groups related policy definitions so that they can be assigned and evaluated as a set.
An initiative might combine requirements for allowed regions, diagnostic settings, resource tagging and particular security configurations. Parameters let the same initiative adapt to different scopes without cloning definitions. A production branch can have stricter values than a development branch while both still use the same overall governance design.
This is a recurring AZ-104 decision pattern: prefer reusable structure over one-off configuration. The administrator is expected to operate an Azure estate, not merely configure a single resource successfully. Initiatives, management groups and parameterized assignments make governance easier to understand and maintain when the environment changes.
Policy and RBAC solve different problems
Azure Policy and Azure role-based access control are often mentioned together because both can be assigned at scopes in the Azure hierarchy, but they answer different questions. RBAC asks who is allowed to perform an action. Policy asks whether the resulting resource state is permitted or compliant with organizational rules.
A user can have Contributor access and still be blocked by a policy that denies deployment outside approved regions. Conversely, a perfectly compliant resource configuration does not grant anyone permission to change it. Strong administration uses both layers: RBAC limits authority, and Policy limits acceptable state.
This distinction also matters when diagnosing failures. An authorization error points toward identity, role assignment or scope. A policy-denied deployment points toward the applicable policy assignment and its effect. Treating every denied action as an RBAC issue wastes time and can lead administrators to grant broader permissions that do not solve the actual problem.
Resource locks protect critical resources from accidental change
Resource locks provide another governance control. A CanNotDelete lock can prevent accidental deletion while still permitting changes that are otherwise authorized. A ReadOnly lock is more restrictive because management operations that require writes are blocked. Locks inherit to child resources, so administrators need to understand both where a lock was assigned and what operations a service actually performs behind the scenes.
Locks are not a replacement for RBAC or Policy. They are useful protection against accidental management-plane changes by already-authorized users. A production resource may be correctly configured by policy and accessible only to a small operations group, yet still benefit from a deletion lock because an accidental removal would have serious consequences.
AZ-104 scenarios often become easier when each control is given a distinct purpose: RBAC for authorization, Policy for resource standards, locks for protection against destructive management actions, and tags for organization and cost or operational metadata.
Tags are useful only when the organization can rely on them
Tags help classify resources by owner, application, environment, cost center or another operational dimension. Their value appears when the metadata is consistent enough for reporting, automation and cost analysis. Optional tags that are entered differently by every team provide much less governance value.
Policy can help enforce the presence of tags or apply selected tag behavior at scale. Administrators should still design the taxonomy carefully. Too many required tags make deployments cumbersome, while vague labels make the data unreliable. The best tagging model starts with a small number of fields that support real business or operational decisions.
Tags also do not replace the Azure resource hierarchy. A tag can describe a resource as production, but it does not give that resource the governance inheritance that a production management-group structure provides. Metadata and scope complement each other.
Exceptions should be explicit rather than hidden
Real environments need exceptions. A legacy workload might temporarily require a configuration that the current baseline prohibits, or a security test might require a resource in a location that normal workloads do not use. The mature response is not to weaken the policy for everyone. It is to document and scope the exception.
Azure Policy exemptions can make that distinction visible in compliance reporting. Administrators should know why the exception exists, who owns it and when it should be reviewed. This keeps the baseline meaningful because nonstandard resources are treated as deliberate deviations instead of mysterious compliance noise.
A strong governance program also uses staged rollout. Audit a new rule first, understand the impact, remediate existing resources and only then move to stronger enforcement where appropriate. That sequence reduces production surprises and produces better evidence for the teams affected by the change.
Use compliance results as an operational signal
Policy compliance is useful only when administrators act on it. A dashboard full of noncompliant resources does not make the environment safer by itself. Teams need to distinguish expected exemptions from configuration drift, investigate new failures and use remediation when an effect supports it.
At scale, governance should answer practical questions: Which subscriptions are drifting from the baseline? Which resources violate a control? Was the rule inherited from a management group or assigned locally? Is the resource exempt? Does remediation require identity permissions? Those questions connect Azure Policy to day-to-day administration.
The wider cloud architecture certification landscape tends to push these decisions upward into design, but AZ-104 keeps the focus on implementation and operation. The administrator must be able to apply the hierarchy, read the result and correct the environment without breaking workloads that have legitimate differences.
Think in layers for AZ-104 governance scenarios
When an exam scenario combines several controls, work from the top down. First identify the scope: management group, subscription, resource group or resource. Next identify whether the problem is authorization, policy compliance, accidental-change protection, metadata or cost management. Then choose the service designed for that job.
For candidates who want the broader administrator context, the site’s Azure Administrator certification coverage places governance alongside storage, compute, networking and monitoring rather than treating it as a separate specialty. That framing matches real Azure operations. Governance is the layer that keeps all of those technical domains manageable as the estate grows.
The strongest mental model is simple: organize scopes intentionally, grant only the access people need, declare the resource standards that matter, protect critical assets and review compliance continuously. Once those relationships are clear, Azure Policy questions stop looking like a list of effects and start looking like operational decisions.