Microsoft AZ-104: Policy, Locks, and Resource Governance

Azure governance questions on Microsoft AZ-104 are not really about memorizing three unrelated features. Azure Policy, resource locks, role-based access, tags, management groups, and compliance reporting all answer different parts of the same administrator question: how do you let teams operate at scale without losing control of the environment?

The current AZ-104 study guide expects administrators to manage Azure resources and governance as part of day-to-day operations. The important skill is knowing which control solves which problem. A policy can evaluate or enforce resource standards. A lock can prevent control-plane deletion or modification. RBAC determines who can perform actions. Tags add classification and management context. Using one as a substitute for another creates weak governance and often confusing troubleshooting.

Start with the governance hierarchy before choosing a control

Azure resources exist inside a hierarchy that can include management groups, subscriptions, resource groups, and individual resources. Governance controls can be assigned at different scopes and inherited downward. That makes scope design as important as the policy definition itself.

An administrator who assigns a restrictive control at a subscription may affect hundreds of resources and multiple teams. The same control assigned to one resource group has a narrower blast radius. Before choosing a scope, identify the administrative boundary, the resources that genuinely share the requirement, and whether exceptions will be necessary.

AZ-104 sits inside a broader Microsoft Azure certifications, but governance remains central to the administrator role. The job is not simply creating resources; it is operating subscriptions in a controlled and supportable way.

Azure Policy evaluates resource state against organizational rules

Azure Policy compares resources and actions with policy definitions. Microsoft provides built-in definitions, and organizations can create custom definitions when their rules are more specific. Related definitions can be grouped into initiatives so a compliance requirement can be managed as a coherent set rather than a loose collection.

Effects are where exam scenarios become practical. Some policies audit a condition without blocking deployment. Others deny noncompliant changes, append or modify information, deploy supporting configuration, or mark resources as noncompliant. The best effect depends on whether the organization is discovering a problem, preventing it, or remediating it.

Azure Policy at scale depends on assignment scope, initiatives, exemptions, remediation, and operational impact—not merely writing a JSON condition.

Compliance state is evidence, not the same thing as prevention

The Azure Policy compliance view helps administrators see which resources satisfy assigned rules and which do not. That reporting layer matters because a governance program needs visibility even when the organization intentionally begins with audit-only controls.

A noncompliant resource may predate the policy, may be exempted for a justified reason, or may require a remediation task. A policy that can remediate future deployments does not automatically prove that all existing resources are fixed. Administrators need to understand the difference between evaluating state, blocking a request, and bringing a resource into compliance.

This distinction appears in scenario questions. If the requirement is “identify resources without a required tag,” audit may be enough. If the requirement is “prevent deployment outside approved regions,” a deny effect is more appropriate. If the organization must add a configuration to existing resources, remediation becomes part of the answer.

Resource locks protect the control plane from accidental change

Azure resource locks are intentionally blunt. A Delete lock (CanNotDelete) allows authorized users to read and modify a resource but prevents deletion. A Read-only lock prevents updates and deletions through the Azure control plane. Microsoft notes that locks override the permissions a user otherwise has for those control-plane operations.

Locks can be applied at subscription, resource-group, or resource scope and are inherited. That inheritance is powerful and risky. A lock placed too high in the hierarchy can block operations on child resources that an administrator did not intend to protect.

Locks apply to control-plane operations, not the data plane. A Read-only lock on a database resource can prevent management changes while applications continue reading and writing data through the service’s data endpoint. AZ-104 candidates should be able to recognize that distinction because “read-only” does not mean all business data becomes read-only.

Policy, locks, and RBAC solve different governance problems

RBAC answers who can perform an action. Azure Policy answers whether a resource state or requested configuration satisfies a rule. A resource lock answers whether certain control-plane changes should be blocked even for someone who would otherwise be authorized. Combining them creates defense in depth, but combining them carelessly creates operational friction.

Suppose a platform team wants developers to deploy resources only in approved regions, while protecting one production database from deletion. RBAC can grant the developers the deployment permissions they need. Azure Policy can deny disallowed locations. A Delete lock can protect the critical database. Trying to meet all three requirements with RBAC alone would produce a more complicated and less expressive permission model.

When diagnosing an authorization or deployment failure, identify which control made the decision. A user may have the correct role and still be denied by policy. A user may be allowed by both role and policy but blocked by a lock. Troubleshooting is faster when governance layers are evaluated separately.

Tags and naming standards become useful when governance consumes them

Tags can represent ownership, environment, cost center, application, data classification, or another operational attribute. On their own, tags are metadata. Their value increases when policy enforces required tags, cost reporting groups resources by tag, automation selects resources based on tags, or support teams use tags to identify responsible owners.

A strong governance design avoids turning tags into an uncontrolled dictionary. Decide which keys are mandatory, what values are valid, who owns the taxonomy, and how inherited or missing metadata is handled. Policy can then audit or remediate the standard.

Naming standards work similarly. They are most useful when they make resources recognizable without embedding sensitive or unstable information. Policy can help enforce aspects of a naming convention, but the rule should support operations rather than exist only because a template says every organization needs one.

Exceptions and remediation are part of mature governance

Real environments contain legacy resources, temporary migrations, vendor requirements, and controlled exceptions. A governance model that assumes every resource can immediately satisfy every new rule often pushes teams toward disabling controls entirely.

Azure Policy exemptions provide a way to record why a resource or scope is not currently evaluated against an assignment. That exception should be governed: identify the owner, reason, duration, and compensating control. The existence of an exception mechanism is not permission to bypass standards casually.

Remediation should also be tested. A policy effect that changes deployed resources can have operational consequences. Administrators should understand the target scope, required managed identity or permissions, and how a remediation task affects existing resources before applying it broadly.

Policy initiatives are especially useful when one business requirement maps to several technical checks. A security baseline might require diagnostic settings, approved locations, encryption-related configuration, and restrictions on public exposure. Grouping related definitions makes assignment and compliance reporting easier to reason about than managing each rule independently.

Governance also has an operational rollout problem. A new deny policy that is correct in principle can block legitimate deployments if the organization has not discovered its current exceptions. A safer sequence is often to evaluate existing state, understand the noncompliance, test the rule on a narrower scope, remediate or document exceptions, and only then increase enforcement. The exam may not ask for a complete enterprise rollout plan, but this logic helps distinguish audit, deny, exemption, and remediation scenarios.

Finally, remember that permissions to manage governance objects are themselves governed. Being able to create a resource does not imply being able to remove a lock or change a policy assignment. When a scenario includes an administrator who “should have access,” separate permission to operate the resource from permission to change the control that constrains it.

A useful final check is to mentally remove each control and predict the consequence. Without RBAC, who could act? Without Policy, which nonstandard resources could still be deployed? Without the lock, what accidental operation becomes possible? Without tags, which operational or cost question becomes harder to answer? This “control removed” exercise exposes cases where two features are being treated as duplicates even though they protect different dimensions of the environment.

Prepare for AZ-104 by translating requirements into the right governance layer

Build short scenarios and force yourself to name the control before configuring anything. “Only approved regions” points toward Policy. “Prevent accidental production deletion” points toward a lock. “Allow the operations team to restart VMs but not manage networking” points toward RBAC. “Report resources by owner and cost center” points toward tags plus enforcement.

Then add conflicts. What if a user has Contributor but the resource is locked? What if a policy audits rather than denies? What if a lock exists on the resource group instead of the resource? What if the policy is assigned at a management group and the administrator is only looking at the subscription?

The AZ-104 governance objective is ultimately about choosing and operating controls at the correct scope. If you can explain the decision path—from hierarchy to assignment to enforcement to exception—you are preparing for the administrator judgment the exam is designed to measure, not just memorizing where Azure displays each feature.