Azure resource management is easier to audit when permission, allowed configuration, and spending expectations are evaluated separately. Azure RBAC determines which principal may carry out an operation. Azure Policy evaluates resource state against assigned rules and can deny or audit noncompliant deployments. Budgets and cost alerts make spending observable; they do not automatically stop every resource deployment when a threshold is crossed. Treating those controls as one security setting leads to false expectations.<\/p>\n
Consider a team deploying test virtual machines across two subscriptions. Administrators must restrict permitted regions, require ownership tags, permit least-privileged operators, and alert finance when spending reaches a defined limit. The right design uses several controls at different scopes and includes a remediation path for older resources, not one all-powerful ‘governance’ role.<\/p>\n
The current AZ-104 blueprint<\/a> covers Azure Policy, locks, tags, subscriptions, management groups, cost alerts, budgets and Azure Advisor. Start the lab with an explicit desired result for each. A compliant deployment, a denied deployment, a missing-tag audit finding, and a cost notification are distinct test outcomes.<\/p>\n A management group provides a governance scope above subscriptions, which themselves contain resource groups and resources. Policy and role assignments can inherit down that hierarchy. Design a simple organization with a production management group and a testing management group. Put disposable subscriptions under the appropriate branch; do not build a deep tree that merely copies every team name into a new management group.<\/p>\n Management-group, subscription and resource-group scopes<\/a> govern inheritance, so the placement of a region restriction or operator role assignment changes which workloads it affects. Compare a policy applied to one test group with the same policy applied at subscription scope. A policy assigned too high can reject legitimate workloads; a privileged role granted too high enlarges the impact of a compromised account.<\/p>\n Before moving a subscription between management groups, inventory inherited policies, access assignments, platform capabilities and billing considerations. A move can change effective governance even when none of the subscription’s resources changes. Capture the intended post-move policy and role outcomes, then validate them rather than assuming a tree view proves the migration is safe.<\/p>\n A policy definition expresses a rule and its effect. An initiative groups related policy definitions so a compliance program can assign and report them together. An assignment connects the definition or initiative to a scope with parameters, exclusions, and possibly a remediation identity. Keep these concepts separate; an unassigned definition does not constrain running resources.<\/p>\n Start with a permitted-location policy and a tag policy. Test a new resource whose region violates the rule, another without the required tag, and a properly configured resource. Identify the applicable effect: deny, audit, append\/modify, or deploy-if-not-exists, when supported by the chosen policy definition. Do not say an audit effect blocks deployment or that remediation necessarily occurs merely because a compliance result is red.<\/p>\n Microsoft’s Azure Policy documentation<\/a> distinguishes state evaluation from Azure role authorization. A user may have permission to create a resource but be stopped by an applicable deny policy. Conversely, an allowed policy state does not grant a user permission to deploy. Include both combinations in the lab so the diagnostic tree cannot conflate them.<\/p>\n Compliance reports may evaluate both new and existing resources, but changing a policy effect or assignment does not necessarily rewrite an older resource immediately. Modify and deploy-if-not-exists patterns can use remediation tasks and managed identities with carefully scoped permissions. Check the exact effect’s supported behavior, identity requirements, and definition parameters; do not give every policy assignment Owner to avoid understanding its permissions.<\/p>\n Plan a missing-tag remediation on a disposable resource. The assignment should target only the intended scope and have an approved identity or role assignment for the change. Confirm the object changed and the evaluation state after the remediation cycle. If policy reports an unexpected failure, inspect the activity and policy events, permission on the managed identity, and exemptions rather than adding a broad administrator role.<\/p>\n Document exception governance. A policy exemption has a reason, owner, expiration or review decision and specific scope. Exempting the entire management group for one difficult VM defeats the original purpose. Use a narrow, reviewable exception and ensure the reader understands it is a governance decision, not a default fix for denied deployments.<\/p>\n Tags classify resources for ownership, environment or cost allocation. They do not create a security perimeter and may not propagate automatically to every child resource. Test a tag policy at the resource-group scope and inspect which resources actually receive or require the value. Keep the application owner’s identifier and cost center consistent so reports can be interpreted.<\/p>\n Resource locks protect against some accidental modification or deletion. They are not substitutes for least-privilege assignments and can interfere with operational deployments or backup integrations. ReadOnly and CanNotDelete have different consequences. Before assigning a subscription-level lock, test the effect on a service that needs to modify managed resources and create a documented exception or safe change procedure.<\/p>\n Practice diagnosing a blocked update through the layers: identity, role, inherited policy, resource lock, provider registration, and service quota. A denial caused by a lock should not be ‘fixed’ by creating another policy exemption. The existing RBAC topic complements this by focusing on the permissions calculation rather than resource-compliance evaluation.<\/p>\n Azure Cost Management budgets track spending against a configured threshold and can trigger notifications or actions through integrations. A budget by itself is not a universal automatic spending cap. When a budget warning fires, the team still needs an owner, cost breakdown, and a decision about scaling, shutting down, or redesigning resources. Test this behavior in a sandbox using planned thresholds without relying on real production costs.<\/p>\n Azure Advisor presents recommendations informed by observed resources. A recommendation to resize an underused VM may be useful, but changing a workload’s size can have consequences for performance, licensing, regional availability, or capacity reservations. Review business constraints before taking a recommendation as an absolute instruction. Keep a record of accepted and declined recommendations and their reasons.<\/p>\nOrganize subscriptions and management groups intentionally<\/h2>\n
Design Azure Policy definitions, initiatives, and assignments<\/h2>\n
Remediate existing resources without over-privileging automation<\/h2>\n
Use tags and locks for different reasons<\/h2>\n
Budgets, alerts, and Azure Advisor are signals, not spending switches<\/h2>\n