The Microsoft Azure Fundamentals (AZ-900) exam tests pricing, service level agreements and governance in its management and governance domain, weighted at 30 to 35%: the factors that drive Azure cost, the pricing and total cost of ownership calculators, Microsoft Cost Management, tags, SLAs and the service lifecycle, and the governance tools Azure Policy, resource locks and management groups.
Last updated October 2026.
The AZ-900 study guide's third skills area, Describe Azure management and governance, carries 30 to 35% of the exam. That is almost the weight of the Azure architecture and services domain (35 to 40%) and more than cloud concepts (25 to 30%), yet it is the domain self-study plans treat as a footnote, because it covers tools most candidates have never opened: calculators, cost reports, policies and locks rather than virtual machines and storage accounts.
The depth bar is the same as the rest of the exam. Task statements ask you to describe a tool or concept and pick the one that fits a stated need, never to configure it. For every item below, the preparation is a one-line job description and the scenario phrases that point at it.
Domain names and weight ranges from the official Microsoft AZ-900 study guide, as summarised in the complete AZ-900 guide.
Pricing questions start from the consumption-based model the cloud-concepts domain introduces: you pay for what you provision and use, as operating expenditure, instead of buying hardware up front as capital expenditure. The management domain then asks what moves the bill. At exam depth the factors are what you deploy (the service and its size), how much you use it, and the tier you choose for it, with Blob Storage access tiers trading lower storage cost for slower or dearer retrieval as the standard example.
Two structural points recur. The subscription is the billing boundary: costs roll up to it, which is why organisations use separate subscriptions for separate teams or environments. And tags are the cost-attribution tool: a department or project label on each resource lets the bill be split by something other than subscription.
Every tool question in this domain hides a need, and each need maps to one tool. The table is the whole list the cluster's AZ-900 posts return to:
| Tool | The one-line job | The scenario phrase |
|---|---|---|
| Pricing calculator | Estimate the cost of a planned workload before anything is deployed | "Estimate the monthly cost of the proposed solution" |
| Total cost of ownership (TCO) calculator | Compare the cost of running on premises against the same workload on Azure | "Show the saving from migrating the datacenter" |
| Microsoft Cost Management | Analyze what has actually been spent, and set budgets and alerts on it | "Identify which resources drove last month's increase" |
| Tags | Label resources for organisation and cost attribution | "Report spend by department" |
| Azure Policy | Enforce rules about what resources may look like across a scope | "Ensure every resource is deployed to an approved region" |
| Resource locks | Protect a specific resource from accidental deletion or modification | "Prevent anyone deleting the production database" |
| Management groups | Organise many subscriptions so policy and access apply at scale | "Apply the same rule to all 40 subscriptions" |
Tool names and roles as the AZ-900 study guide lists them under the management and governance domain. Scenario phrases are ours, written to match how exam items describe a need without naming the tool.
A service level agreement is Microsoft's commitment to a level of availability for a service, expressed as a percentage of uptime, with service credits if it is missed. AZ-900 does not ask you to recall any individual service's figure. It asks you to reason about how SLAs combine.
That is the composite SLA idea: an application that depends on several services is only as available as all of them together, so its overall SLA is lower than the SLA of any single component. Adding a dependency lowers the composite figure; adding redundancy (a second instance in another availability zone, for example) raises it. Questions describe an architecture and ask which change improves or worsens the overall availability, and the direction is what you need, not the arithmetic.
Alongside SLAs the domain lists the service lifecycle: a feature in preview is released for evaluation and feedback and is not yet the fully supported version, while general availability is the production release. The exam phrase to watch is "production workload": a preview capability is the wrong answer for one, however well it fits the feature list.
Governance items lean on the resource hierarchy from the architecture domain: resources sit in resource groups, resource groups belong to a subscription, and subscriptions can be organised under management groups. Azure Policy and access are applied at a level of that hierarchy and inherited downwards, which is why "apply once, cover everything" scenarios point up the tree to a management group, while "only this one resource" scenarios point down to a lock.
The distractor pair worth drilling is Azure Policy versus resource locks: Policy governs what resources are allowed to look like across a scope (allowed regions, required tags, permitted sizes), while a lock protects an individual resource from being deleted or changed. The core Azure services post covers the same pair from the services side.
Management and governance items almost never name the tool in the stem. They describe a need, often with a time direction in it, and the time direction is the tell: before deployment is the pricing calculator or the TCO calculator (the TCO calculator when on-premises hardware is in the comparison), after deployment is Cost Management. "Prevent" and "accidental" point at a lock, "ensure" and "comply" across many resources point at Policy, "by department" or "by project" points at tags, and "across all our subscriptions" points at management groups. Six connections, and the domain's tool questions are largely solved.
The management and governance domain, 30 to 35% of AZ-900, covers Azure Policy, resource locks, tags, and management groups for governance, alongside the cost tools (the pricing calculator, the total cost of ownership calculator, and Microsoft Cost Management), service level agreements, and the service lifecycle. All are tested at describe-the-tool depth, not configuration.
The pricing calculator estimates what a planned Azure workload will cost before you deploy it. The total cost of ownership calculator compares the cost of your existing on-premises infrastructure against running the same workload on Azure. A scenario that mentions current datacenter costs or migration savings points at the TCO calculator.
A composite SLA is the overall availability of an application that depends on several Azure services, and it is lower than the SLA of any single service it uses. AZ-900 tests the direction, not the arithmetic: adding a dependency lowers the composite SLA, and adding redundancy raises it.
Azure Policy enforces rules about what resources may look like across a scope, such as allowed regions or required tags. A resource lock protects one specific resource from accidental deletion or modification. "Prevent anyone deleting this" is a lock; "ensure every resource complies" is Policy.
Certified has no AZ-900 course yet. The complete Azure Fundamentals guide covers all three skills areas, the format and passing score, and how to prepare, with the official study guide as its source.
Read the complete AZ-900 guide →