This study companion uses one small sales dataset to connect data preparation, model design, measures and validation. It is an independent practice exercise, not an official Microsoft resource or a collection of exam questions. Use the current Microsoft DP-600 study guide to check the assessed skills before planning your exam preparation.
1. Define an outcome you can verify
Your task is to build a report that answers three questions: What is total sales revenue? How does revenue split by region? Does a product filter change the result as expected? Begin with a written definition: revenue is quantity multiplied by unit price, before tax, refunds and discounts. This deliberately small example excludes those adjustments so that you can calculate every result by hand. In a real project, agree the revenue definition with the business before modeling anything.
Create a scratch workspace for your practice and keep it separate from production assets. If your organization restricts workspace creation or you do not have suitable Fabric access, work through the modeling exercise in an environment you are authorized to use. A paid capacity is not necessary to understand the arithmetic in this example. Do not upload customer records or credentials into a training workspace.
2. Start with a five-row fact table
Save the following as a CSV file. The records are fictional and were created for this exercise. Each row represents an order line, not necessarily an entire order. That distinction determines whether counting rows would be a valid order-count measure.
OrderId,OrderDate,Region,Product,Quantity,UnitPrice
O1001,2026-10-01,North,A,2,50
O1002,2026-10-01,South,B,1,120
O1003,2026-10-02,North,B,3,120
O1004,2026-10-02,South,A,4,50
O1005,2026-10-03,North,A,1,50Inspect the file before loading it. Check the delimiter, header names, date format and whether numeric columns were interpreted as text. For this dataset, a successful load has five rows, five distinct order identifiers and eleven units. Record these checks in your notes so that later transformations cannot silently drop a row or multiply records.
3. Explain your storage and preparation choices
Write a short decision note comparing a Lakehouse-based path with a Warehouse-based path for this exercise. Consider who will maintain transformations, what languages the team uses, how the data arrives and what permissions are available. Do not choose a platform solely because a tutorial uses it. Consult the Microsoft data store decision guide for product-specific capabilities and current limitations.
Prepare a clean Sales table with consistent column names and explicit types. Add a validation step that rejects negative quantities for this particular exercise. Explain how a real returns process might require a different rule: a negative quantity can be a legitimate business event rather than bad data. Keep the raw input so that you can trace a transformed value back to its source.
4. Design the model before decorating the report
For a first pass, use the Sales table directly. For a second pass, create separate date, product and region dimensions and explain the grain of each table. Check that a dimension key appears once on the dimension side. A repeated dimension key can change relationship behavior and cause incorrect totals. Sketch the relationships and annotate the intended filter direction in your notebook.
Choose a semantic model storage mode based on the actual environment. Direct Lake is a product feature with requirements and limitations; do not assume that every Fabric table or report will use it automatically. Read the Direct Lake overview and record which configuration you used. This exercise does not claim a performance advantage for any mode.
5. Add measures with known answers
With a table named Sales and the numeric columns above, these illustrative DAX measures express the business definition. Validate them in your model before adapting them to another dataset.
Total Revenue = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])
Units Sold = SUM(Sales[Quantity])
Order Count = DISTINCTCOUNT(Sales[OrderId])The expected unfiltered results are revenue of 830, units of 11 and five distinct orders. North contributes 510 and South contributes 320. Product A contributes 350 and Product B contributes 480. If a regional total is larger than expected, inspect joins and relationships before changing the measure. If a visual ignores a filter, check the filter path and report interactions. These are arithmetic expectations for fictional rows, not measurements from a client project.
6. Keep a validation and security notebook
Create a table visual showing the raw order lines beside the measures. Apply one region filter at a time, then one product filter. Repeat the test with a blank product value and a duplicated input row in a separate copy of the data. Describe the failure you introduced, the result you expected and the result you observed. A useful learning note explains the diagnosis rather than merely recording that a refresh succeeded.
Test access with an authorized viewer account before sharing a report. Document which assets the viewer needs, what they can query and whether your scenario requires row-level restrictions. A report filter is not a security boundary. Use synthetic records throughout the exercise and do not grant broad workspace access simply to make a test pass.
7. Turn the exercise into a study plan
Finish with a one-page record containing the dataset grain, storage decision, transformation checks, model diagram, measure definitions, expected results and unresolved questions. Rebuild the example from your notes after a few days. If you cannot explain a choice without copying a tutorial, revisit that part of the workflow. Then map your remaining questions to the official study guide and continue with the DP-600 preparation guide. Completing this exercise does not guarantee exam success.
