Domain weights

Elena likes to plan with numbers. On the afternoon after the diagnostic she opens a spreadsheet with Hana and asks a practical question: if Hana has about 90 hours of exam preparation between March 1 and her exam on Friday, June 11, 2027, how should those hours be spent? The answer depends on two things: how much of the exam each skill group is worth, and how well Hana already knows each group. The study guide gives the first. The diagnostic gives a rough measure of the second.

This lesson explains what the published weights mean and what they do not mean, shows how the skills are spread across the three groups, and builds a study plan from the weights and Hana's results. It ends with the limits of any such plan.

What a weight range means

Each skill group in the study guide has a weight range, such as 35 to 40 parts in 100. The range describes roughly what share of the exam's points comes from that group. It is a range rather than a single number because each candidate gets a different set of questions, and the share varies from one set to another. The ranges for DP-800 add up to between 95 and 110, which shows they are approximate: on any given exam, the actual shares add to exactly 100.

A weight is about points, not about the number of questions. If some questions are worth more than one point, a group could have fewer questions and still carry its share of the points. A weight also says nothing about how hard the group's questions are. A small group with tricky questions can cost more marks than a large group a candidate knows well.

How the skills are spread

Weights become more useful when they are compared with the number of skills in each group. The study guide lists every skill under an area. Counting them gives a sense of how thinly the weight is spread.

Two lessons follow. First, the AI group has almost as many listed skills as the others, so although its total weight is lower, each AI skill carries about as much as a security or deployment skill. A candidate cannot afford to skip AI topics on the grounds that the group is the smallest. Second, the design group has the fewest skills for its weight, so each design skill is worth slightly more. Many of those skills are T-SQL features a working developer already uses, which is good news for Hana.

The counts are only a guide. Some skills, such as 'Implement vector search', are broad and could produce several questions; others, such as 'Design and implement SEQUENCES', are narrow. But the exercise makes a point Elena repeats often: the outline is a checklist. If a skill is listed, it can be asked. If it is not listed, it is unlikely to be.

Turning results into a plan

A diagnostic set is too small to measure Hana's knowledge precisely, but it is good enough to set priorities. Elena's method gives each group a 'need' score, equal to its midpoint weight multiplied by the share of questions Hana got wrong. A heavy group where she does poorly gets the most need; a light group she knows well gets the least. The hours are then shared in proportion to need.

weights = {"Design and develop": 37.5, "Secure, optimize and deploy": 37.5, "AI capabilities": 27.5}
correct = {"Design and develop": (14, 19), "Secure, optimize and deploy": (12, 19), "AI capabilities": (7, 12)}
hours_available = 90

need = {}
for group, weight in weights.items():
    right, asked = correct[group]
    need[group] = weight * (1 - right / asked)

total_need = sum(need.values())
for group in weights:
    share = need[group] / total_need
    print(f"{group:28} need {need[group]:5.2f}  hours {hours_available * share:4.1f}")

Design and develop           need  9.87  hours 25.3
Secure, optimize and deploy  need 13.82  hours 35.4
AI capabilities              need 11.46  hours 29.3

The result gives secure, optimize and deploy about 35 hours, AI capabilities about 29 and design and develop about 25. The order surprises Hana a little: she expected AI to come first. But secure, optimize and deploy is both large and weak, and its need score is the highest. AI is weaker still, but its lower weight pulls it into second place. Design gets the least because she already does well there, but 25 hours is still a serious amount of time.

Elena then adjusts by judgment. MSAZ-301, which Hana will finish in February, covers the AI group in depth, so by March her AI result should already be better. Elena keeps the hours roughly as calculated anyway, because the AI features are new and change often, and practice with the exact functions named in the outline is worth the time. She moves two hours from design to CI/CD with SQL Database Projects, which Hana has used only once.

Areas inside a group

The same thinking works one level down. In the secure, optimize and deploy group, Hana's diagnostic answers were strong on encryption and permissions, which she studied in the security clinic, and weak on SQL Database Projects and Data API builder configuration. So within that group's 35 hours, Elena puts more than half into the CI/CD and integration areas. In the AI group, she puts most of the time into intelligent search, the largest area, with ten listed skills: choosing between full-text, vector and hybrid search, vector indexes and their metrics, approximate and exact search, and reciprocal rank fusion.

The plan is written as a table with one row per area, the hours, the source (MSAZ-300, MSAZ-281, MSAZ-301 or documentation) and a practice method. It is not a schedule by date; lesson 11 builds the dated timeline. It is a budget: how much effort each part of the outline deserves.

What weights cannot tell you

Weights describe the exam as a whole. They do not say which questions Hana will get, how hard they will be, or how many points each is worth. A candidate can study exactly by the weights and still meet a set of questions that leans toward the area they know least. That is why the target is a margin above the pass mark in every group, not a high average.

Weights also hide the fact that groups overlap. A question about securing a Data API builder endpoint belongs to the secure, optimize and deploy group, but it may also need knowledge of stored procedures from the design group. A RAG question in the AI group may turn on converting rows to JSON with FOR JSON, a T-SQL skill. Studying by group is a convenient way to organize time; the exam itself tests a joined-up understanding.

Finally, a small diagnostic is noisy. Seven correct answers out of twelve could easily have been five or nine on a different day. Elena will measure again with larger practice sets in April and May and adjust the plan then. The plan is a starting point, not a forecast.

Updating the budget after each practice set

A study budget is only useful if it changes when the evidence changes. Elena and Hana agree a simple routine for after each larger practice set in phase 2. First, score the set by group and by area, not just in total. Second, write the result for each area next to its planned hours. Third, move hours from any area scoring 85 in 100 or better to any area scoring below 70 in 100, in blocks of two hours, so that the total stays the same. Fourth, write down why each wrong answer was wrong, using the distractor patterns from lesson 9, because an area that scores poorly through misreading needs a different fix from one that scores poorly through not knowing the feature.

The routine has a limit. If an area is weak because Hana has never used the feature, extra reading will help less than ten minutes of hands-on work. For CI/CD with SQL Database Projects, the fix is to build and deploy a small project twice; for Data API builder, it is to write a configuration file from scratch and run it locally against the test database. Elena's rule of thumb is that one hour of doing is worth two of reading for any area where the exam asks for configuration or code.

The budget also has a floor. No area drops below three hours, however well it scores, because a single practice set can flatter an area by chance and because every listed skill can still be asked. The floor keeps strong areas warm while the weak ones get most of the time.