Cloud governance becomes difficult the moment a team can create resources faster than someone can check them. For the Microsoft AZ-900 exam, the important skill is not memorizing a collection of Azure logos. It is recognizing which control answers a particular management question: who can change a resource, what configurations are allowed, how an organization groups its assets, and what evidence shows that the controls work. Those distinctions also matter when a small pilot grows into several subscriptions owned by different teams.
Consider a retailer whose marketing team launches a customer analytics service. The deployment is technically successful, but its resources are scattered among subscriptions, nobody owns the monthly charges, and a database was created in a region the company never approved. None of these problems requires an exotic attack. They arise because deployment permissions, organizational standards and financial accountability were treated as the same thing. Azure provides separate mechanisms for each, and AZ-900 expects candidates to tell them apart.
Governance starts by naming the decision
An effective governance design asks a concrete question before choosing a product. If the issue is that a developer can delete a production virtual machine, examine identity and authorization. If the issue is that even an authorized developer should not create resources in a restricted location, examine configuration policy. If the issue is that nobody knows which department owns the workload, examine resource organization and metadata. Trying to solve all three with a naming convention only creates a more neatly named problem.
Azure role-based access control, or Azure RBAC, gives principals permissions to perform management operations at defined scopes. It is a relationship among a security principal, a role definition and an assignment scope. The same person might be permitted to manage a development resource group while only viewing production resources. When a scenario asks who may perform an action, the first question is often which role is assigned and how widely the assignment reaches. The broader principles of role-based access control extend well beyond Azure, but Azure’s resource hierarchy determines the impact of each assignment.
Azure Policy addresses a different problem. A policy definition expresses a desired rule about resources; an assignment applies it to a scope, sometimes with parameters or exclusions. Policy effects differ: some evaluate and report noncompliance, while others can deny certain deployments or modify supported properties. Policy is not simply an authorization role with another name. A user might have permission to deploy a resource but still be blocked because the requested configuration violates an assigned policy.
Resource locks are narrower again. A lock can prevent specified deletion or modification operations at a scope, helping defend an important asset against inadvertent changes. A lock does not decide whether an application query can read confidential records, and it is not a substitute for backups or monitoring. For AZ-900, the useful mental move is to identify the failure the business fears: an unauthorized person, an unacceptable configuration, or an accidental management operation. Each has a different primary control.
Design the hierarchy before it becomes a maze
An Azure tenant can contain management groups, subscriptions, resource groups and individual resources. These are not interchangeable folders. Management groups help apply governance across multiple subscriptions. Subscriptions are administrative and billing boundaries with their own limits and access management. Resource groups organize resources for management, deployment and lifecycle operations. Individual resources—such as virtual machines, storage accounts and databases—exist within resource groups and can have separate settings and assignments.
Imagine a global company running production environments in Europe and North America. It may use management groups to place common security and location restrictions across relevant subscriptions, rather than repeat those assignments manually. It may then separate production from experimentation through subscriptions or resource-group design according to operational needs. Assigning an Owner role high in that hierarchy would create broad authority, while assigning a more limited role to one application resource group can contain the impact of a mistake.
Inheritance is powerful because it reduces repetitive administration; it also makes scope errors expensive. A policy or role assignment inherited from a parent can affect many descendants, including resources created later. When troubleshooting an unexpected deployment failure, check assignments at higher scopes instead of assuming that the local resource group has the only relevant configuration. Conversely, do not use a broad management-group exclusion to fix one team’s narrow exception when a smaller, documented solution is available.
Tags add business context to resources: cost center, owner, environment, workload, data classification or project identifier. Their exact design depends on the organization’s operating model. Tags are useful for cost reporting and inventory queries, but a tag is not an authorization boundary. Writing Environment=Production on a resource does not stop a user from deleting it. Policies can help enforce required metadata, while RBAC and locks address different aspects of protection.
Resource groups also deserve deliberate lifecycle thinking. A resource group provides a practical management unit, including a clear deletion boundary; grouping unrelated production and test components together makes routine cleanup risky. Some applications legitimately span several resource groups because network foundations, shared services and business workloads have different owners. A good organization balances logical grouping with who operates, pays for and retires each component. There is no exam rule that every application must fit perfectly inside one resource group.
Deployment tools do not replace governance
Azure portal gives an interactive path to create and manage resources. Azure Cloud Shell provides a browser-accessible command environment, while Azure CLI and Azure PowerShell support scriptable administration. These tools differ in interface and ecosystem, not in whether governance applies. A deployment performed by a script is still subject to the relevant identity permissions and policy restrictions. Automation can consistently reproduce a bad configuration as easily as a good one.
Azure Resource Manager is the control-plane deployment and management framework behind Azure resources. ARM templates define declarative deployments, and infrastructure as code allows teams to review intended infrastructure in version control before it is applied. A declarative file describes a target state rather than a sequence of manual clicks. That approach can improve repeatability and review, but someone still has to decide acceptable regions, resource types, identities, diagnostics and spending constraints.
A retailer might keep production database configuration in an infrastructure repository, require code review for changes, and run predeployment validation in its delivery pipeline. The repository is valuable because it records intent; Azure Policy adds a separate guardrail when changes reach the platform. If a template tries to deploy an unapproved resource type, policy may intervene even after the code was merged. The controls are complementary: a review process catches design mistakes, while platform enforcement reduces reliance on a reviewer noticing everything.
Azure Arc extends management capabilities to eligible resources outside Azure, including certain servers and Kubernetes environments. It does not mean an on-premises machine magically becomes an Azure virtual machine with identical service characteristics or billing. Its governance value is in bringing supported inventory, policy and management experiences across a more complex estate. For an organization with factories, remote offices and cloud workloads, this can reduce the number of isolated operational views without erasing the real differences between environments.
A related distinction appears when moving from fundamentals to Microsoft AZ-104. AZ-900 candidates should recognize the purpose of portal, command tools, Resource Manager, infrastructure as code and Arc. AZ-104 work requires deeper implementation and operational troubleshooting. Knowing that two tools deploy resources does not mean they serve the same workflow or require the same administrator skill.
Compliance requires more than a policy assignment
Compliance starts with a business or regulatory requirement, not with the name of an Azure service. An organization may need to know where sensitive data lives, whether deletion is controlled, who can access financial records, and how it will prove adherence to a retention policy. Azure Policy can assess resource configurations, but it cannot by itself decide whether every field inside an application database was classified correctly or whether employees are using the data for an authorized purpose.
Microsoft Purview addresses data governance, discovery and related compliance capabilities across supported environments. Its role differs from Azure Policy’s resource-configuration focus. A team may use Purview-related capabilities to identify or classify data, while Azure Policy enforces specified controls on deployed resources. Neither eliminates the need for application owners to understand what information they collect and why. Labels, catalogs, retention rules and enforcement boundaries need actual owners and maintenance.
Take a healthcare analytics service. A policy may restrict certain resource deployments by region, but a compliant region alone does not guarantee appropriate access to patient information. The application still needs identity controls, permissions, secure data movement, monitoring and retention handling. A dashboard reporting no Azure Policy violations is therefore useful evidence for one control set, not a universal certificate that the entire workload is secure or lawful.
Exceptions should be treated as decisions that expire or can be reviewed, rather than invisible loopholes. Some environments have legitimate technical limitations that call for a documented exception, compensating control and owner. Others have inherited exclusions that nobody remembers granting. The operational question is whether an auditor or incident responder can explain what was allowed, why it was allowed, and who accepted the resulting risk.
Good governance remains readable to the people operating it. If every project requires a different set of unexplained tags or dozens of contradictory policy assignments, teams will start treating controls as obstacles. A small, coherent baseline with clear ownership is easier to enforce than a giant catalogue of rules that cannot be tested. The fundamentals exam rewards the ability to choose the proper control, not the ability to recite every possible policy effect.
Monitoring turns policy into accountability
Azure Advisor, Azure Service Health and Azure Monitor have different jobs. Advisor surfaces recommendations for supported workloads and resource configurations. Service Health describes issues, maintenance and advisories relevant to Azure services or subscriptions. Azure Monitor collects and analyzes telemetry from resources and applications, including metrics, logs and supported traces. Confusing these tools leads to predictable mistakes: a cost optimization suggestion cannot substitute for an application latency alert, and a platform outage notice cannot explain every application bug.
Suppose an online shop’s checkout time rises sharply after a deployment. Azure Monitor telemetry can help determine whether response times, failed requests or resource pressure changed. Application Insights supports application-oriented telemetry and troubleshooting within the Azure Monitor family. Service Health may help assess whether a broader service incident is relevant. Advisor’s recommendations might identify opportunities to improve reliability or cost over time, but the immediate incident needs evidence from the workload itself.
Log Analytics and Azure Monitor alerts allow teams to examine collected log data and respond to defined conditions. Monitoring quality depends on what was actually instrumented and where the signals are sent. An empty dashboard can indicate a healthy system, a missing diagnostic setting or a broken collection pipeline. Operators should know which events matter to a business service and confirm that alert rules reach someone empowered to act.
Governance monitoring should also follow changes in privilege and configuration. A resource created in the wrong subscription, a broad role assignment or a missing required tag may be a more useful signal than another low-priority CPU graph. Combine policy evaluation, inventory reporting and change visibility to detect drift from approved operating practices. The goal is not to collect every available event forever; it is to retain sufficient, protected evidence to make decisions and investigate incidents.
Read AZ-900 scenarios by asking what fails
A good AZ-900 practice scenario usually hides the important verb inside an ordinary business request. If the requirement says ‘prevent deployments outside approved regions,’ think about Azure Policy. If it says ‘allow engineers to manage only their team’s resources,’ think about Azure RBAC and assignment scope. If it says ‘reduce accidental deletion,’ evaluate resource locks. If it says ‘compare the configuration of many subscriptions,’ investigate hierarchy, policy and inventory rather than trying to infer control from labels alone.
The same discipline helps with management tooling. A question that emphasizes repeatable declarative provisioning points toward Resource Manager and infrastructure as code. A question about managing eligible systems running outside Azure may involve Azure Arc. A question about investigating service health is not the same as one about querying an application log. These are classifications of real operational work, not a bag of similar-sounding Azure products.
For a final review, take one representative workload and trace its lifecycle: which subscription contains it; what roles can change it; what policies constrain it; how its resources are tagged and deployed; what data governance requirements apply; and which monitoring signals show problems. If any of those answers is missing, you have found a management gap worth understanding. That exercise does more for AZ-900 readiness than memorizing a list of products without knowing which responsibility each product addresses.