AZ-900: Shared Responsibility and Governance

Azure Fundamentals becomes much easier when shared responsibility and governance are treated as one connected idea. Shared responsibility explains which tasks remain with the customer as services move from on-premises infrastructure to IaaS, PaaS, and SaaS. Governance explains how an organization turns its remaining responsibilities into repeatable controls across subscriptions, resource groups, identities, policies, costs, and compliance requirements.

The current AZ-900 explicitly includes the shared responsibility model within cloud concepts and assigns 30–35% of the July 20, 2026 blueprint to Azure management and governance. That makes this more than introductory vocabulary: it is the mental model that connects service selection to accountability.

The practical skill is understanding that connection. It does not attempt to summarize every AZ-900 service. Instead, it shows how responsibility changes with cloud service type and how Azure hierarchy, RBAC, Policy, resource locks, tags, cost tools, and compliance capabilities help an organization govern what it still owns.

Shared responsibility changes by service model

On-premises environments place responsibility for physical facilities, hardware, networking, operating systems, applications, identities, and data largely on the customer. Cloud services redistribute some of those responsibilities to the provider. In IaaS, the provider manages physical infrastructure while the customer still manages operating systems, applications, configurations, identities, and data. PaaS removes more platform management, while SaaS leaves the customer focused heavily on identities, access, data, configuration, and appropriate use.

The exam-friendly mistake is to memorize a static chart without understanding the principle. Responsibility follows control. If the customer can configure, grant access to, classify, upload, or expose something, the customer generally retains responsibility for making that decision safely. Provider responsibility does not eliminate customer accountability for how the service is configured and used.

Responsibility is shared even when operations are managed for you

Cloud services can be fully managed from an infrastructure perspective and still require strong customer governance. A managed database may remove patching of the database engine, but the customer still decides who can access data, which network paths are open, what data is stored, how retention works, and whether configuration satisfies organizational requirements. Managed services reduce operational burden; they do not outsource business accountability.

This distinction is why security and governance remain customer concerns across IaaS, PaaS, and SaaS. The exact technical tasks change, but identity, data classification, access, legal obligations, and appropriate configuration remain. AZ-900 questions often reward reasoning from the service model rather than choosing a product merely because it carries the word “managed.”

Azure hierarchy gives governance a scope

Azure resources live inside resource groups and subscriptions, and subscriptions can be organized under management groups. That hierarchy matters because governance controls can apply at different scopes and inherit downward. An organization can therefore set broad expectations at a management-group level while allowing more specific implementation inside subscriptions and resource groups.

Good hierarchy design follows organizational needs such as business units, environments, regulatory boundaries, billing ownership, or operating models. It should not become unnecessarily deep. The point is to create scopes that align with responsibility so policy, access, and cost management can be applied consistently. Azure path becomes more advanced, but the same hierarchy remains fundamental.

RBAC defines who can act within that scope

Azure role-based access control associates identities with roles at a defined scope. A role determines permitted actions; the scope determines where those permissions apply. Assigning a broad role high in the hierarchy can therefore have much larger impact than assigning a narrower role to one resource group.

Least privilege means granting only the access required to perform a job and choosing an appropriate scope. It also means reviewing access as responsibilities change. Governance is weakened when every administrator receives Owner rights because it is convenient. AZ-900 does not require deep RBAC engineering, but candidates should understand that access control is a governance mechanism for translating responsibility into authorized action.

Azure Policy expresses rules for resource configuration

Azure Policy evaluates resources against defined conditions and can audit, deny, modify, or otherwise help enforce organizational requirements depending on the policy effect. This is different from RBAC. RBAC asks whether an identity is allowed to perform an action; Policy asks whether the resulting resource configuration satisfies a rule.

Together they address different failure modes. An administrator may be authorized to deploy resources but still be prevented from deploying them in an unapproved region or without required settings. Policy initiatives can group multiple definitions into a broader control set. The important fundamentals concept is that governance should not rely only on people remembering standards manually.

Resource locks protect against destructive changes, not bad design

Resource locks can reduce the risk of accidental deletion or modification by applying Delete or ReadOnly protection at a scope. They are useful when a resource is critical and routine administrative actions should not casually change it. Locks are not substitutes for RBAC, Policy, backups, or architecture.

A poorly configured resource can remain poorly configured while locked, and authorized users with sufficient permissions can remove locks before making a change. The value is an additional operational safeguard that forces deliberate action. This illustrates defense in depth at a governance level: different controls address different types of mistakes and abuse.

Tags and cost controls make ownership visible

Tags can capture metadata such as cost center, owner, application, environment, or data classification. They help organize reporting and automation, but tags are only useful when their meaning is governed and their use is consistent. A free-form tag scheme that every team interprets differently does not create reliable accountability.

Azure cost-management tools, budgets, pricing information, and tags help organizations connect consumption to responsibility. Governance therefore includes financial discipline as well as security and compliance. Cloud resources can be provisioned quickly, which makes visibility and ownership especially important; without them, waste and unmanaged resources can grow faster than traditional procurement processes would allow.

Compliance evidence needs more than a policy statement

Organizations may use Azure Policy, Defender for Cloud, Microsoft Purview, logs, configuration records, and other evidence sources to understand whether environments align with standards and obligations. Governance connects these technical signals to the organization’s compliance processes. A tool can report configuration state, but management still has to decide what requirements apply and how exceptions are handled.

This is where the AZ-900 scope helps: governance is not a single Azure service. It is a combination of hierarchy, identity, policy, cost controls, compliance capabilities, and operational processes that make cloud use accountable.

Good governance makes cloud speed sustainable

The purpose of governance is not to stop teams from using cloud services. It is to create safe boundaries within which teams can move quickly. Clear subscription ownership, reusable policy, appropriate RBAC, standard tags, cost visibility, and well-defined exceptions reduce the number of decisions each deployment team must reinvent.

That operating model also clarifies shared responsibility. The provider manages the services it owns; the customer governs how those services are selected, configured, accessed, funded, and monitored. When responsibilities are visible and controls are placed at the right scope, the organization can use cloud speed without losing accountability.

Governance also needs an exception process. Policies that are too rigid can encourage teams to bypass them, while policies with undocumented exceptions become meaningless. A mature model defines who can approve an exception, what business reason is required, how compensating controls are recorded, and when the exception expires or must be reviewed. Even at AZ-900 depth, this illustrates why governance is an operating process rather than a collection of Azure features.

Management groups and subscriptions can also be used to separate environments with different ownership or compliance needs. Production, development, regulated workloads, and sandbox experimentation may require different guardrails. The design should reflect real responsibility boundaries rather than an arbitrary folder-like structure. When hierarchy mirrors the organization’s accountability model, inherited policy and access become easier to reason about.

Monitoring closes the loop. Azure Monitor, Service Health, Advisor, cost tools, and compliance views provide signals about health, change, spend, and configuration. Governance determines who watches those signals, which thresholds require action, and how findings become remediation work. Visibility without ownership produces dashboards; visibility with ownership produces management.

For AZ-900, shared responsibility explains the boundary of ownership and governance explains how the customer manages its side of that boundary. Service models change the technical tasks, but they do not remove responsibility for identity, data, configuration, cost, and compliance decisions.

The most useful exam mental model is therefore simple: identify who controls the decision, identify the Azure scope where that decision applies, then choose the governance mechanism that fits—RBAC for authorization, Policy for configuration rules, locks for destructive-change protection, and management/cost/compliance tools for ongoing visibility.

Governance should also define how resources are retired. Deleting unused resources can reduce cost and attack surface, but removal must respect data-retention, legal, backup, and dependency requirements. A resource lifecycle that includes creation, ownership, review, change, and retirement is more useful than governance that focuses only on deployment-time approval.

A final governance habit is periodic review of who owns each subscription and resource group. Ownership changes as projects end and staff move roles. Without review, access, cost responsibility, and exception ownership can drift apart, leaving resources technically functional but managerially orphaned.