AZ-305 Exam Domains and Weightings (Skills Measured as of April 17, 2026)

AZ-305 is weighted across four domains: identity, governance and monitoring at 25–30%, data storage at 20–25%, business continuity at 15–20%, and infrastructure at 30–35%. That set is dated April 17, 2026 on Microsoft's study guide. The passing score is 700 on a 1–1,000 scale.

The four domains

Domain	Functional groups	Weight
Design identity, governance, and monitoring solutions	3	25–30%
Design data storage solutions	3	20–25%
Design business continuity solutions	2	15–20%
Design infrastructure solutions	4	30–35%

Twelve functional groups in total, and forty-nine sub-bullets underneath them — our count, taken off the current page rather than remembered.

Two things about that table are worth saying out loud before we go through it.

The weights are ranges, not fixed numbers. Older summaries of this exam circulate with a single percentage per domain. If a source gives you exact figures for AZ-305 today, it is describing an outline that has been replaced — check the date on Microsoft's page rather than trusting the number.

Infrastructure is the largest single domain, and continuity is the smallest. That does not make continuity optional. Recovery objectives turn up inside infrastructure and storage scenarios too, because a compute or storage recommendation is often decided by a recovery number the business stated.

Domain 1 — identity, governance, and monitoring (25–30%)

Three functional groups sit here: designing solutions for logging and monitoring, designing authentication and authorization solutions, and designing governance.

What this area actually asks for is boundaries and evidence. Where does a rule get written so that it reaches everything it should — including subscriptions nobody has created yet? Which identity does a workload present when it asks for a resource? And once something has gone wrong, what did you collect, where did it land, and who can read it?

Governance questions in particular tend to turn on level rather than on mechanism. Two options can name the same control and differ only in where it is attached, and the scenario's stated requirement is what separates them.

Domain 2 — data storage (20–25%)

Three groups again: relational data, semi-structured and unstructured data, and data integration.

The published bullets ask you to weigh features, performance and cost while choosing — which is a useful signal about how the area is examined. You are rarely asked what a storage service is. You are asked which one a named organisation should use when it has told you about durability, residency, access frequency and budget.

Residency and durability sentences do a lot of work here. A requirement that data must not leave a country, or must survive the loss of a region, eliminates options before any feature comparison starts.

Domain 3 — business continuity (15–20%)

Two groups: backup and disaster recovery, and high availability.

This is the smallest domain and the one with the clearest deciding sentences, because it is the one where the business states numbers. A recovery point objective and a recovery time objective are both given to you, and the design has to produce them. When a stated objective and a mechanism's own timing disagree, one of them has to move — and it is usually the objective that was unrealistic.

Domain 4 — infrastructure (30–35%)

The largest domain, with four groups: compute solutions, application architecture, migrations, and network solutions.

Breadth is the difficulty here rather than depth. Almost every candidate service could run almost any workload you are shown, so technical capability rules very little out. What rules options out is narrower: how long a single execution runs, what a host bills for while nothing is happening, how much of the machine you need to control, and whether the traffic is HTTP.

The migration bullets are worth separate attention because they are phrased differently from the rest. Alongside recommending a migration, you are asked to evaluate one — which is a different task, and it means reading somebody else's plan for the step they left out.

What the outline does not tell you

Microsoft publishes the domains, the weight ranges, the functional groups and the sub-bullets under each. It publishes the passing score.

It does not publish a question count or a time limit for this exam, and we are not going to invent one. The scoring page explains why the score itself is worth understanding properly: scores are scaled from 1 to 1,000, a pass is 700 or above, and because the scale accounts for how difficult a given set of questions is, 700 is not 70% of the points.

Nor does the outline tell you what any individual item looks like. The domains describe the territory and the weights describe how much of it matters. Anything claiming to tell you what appears on the exam itself is not reading the outline — it is reading somebody's recollection, which is both unreliable and against the terms candidates agree to.

Using the weights when you plan

Our advice, marked as ours: plan against the top of each range for the areas you are weakest in, and against the bottom for the areas you already work in daily. A range exists because the exam form varies, and the version you sit could be at either end.

If you are coming from an operations background, the two domains that usually need the most new work are governance and continuity — not because they are harder, but because they are the ones where the right answer depends on a business number rather than on a technical capability.

Whatever you plan against, check the date on Microsoft's study guide page before you start. It is the one fact in this article most likely to change, and it is the fact everything else rests on.