Skip to content
datastudyguides

DP-600 study guide

All 41 topics as a feed, in exam order. Swipe through a topic, say whether you know it, and answer its question. What you miss comes back later.

Loading the guide...

The route

What the guide covers

The topics follow the official skills outline of October 19, 2026, one study card per exam objective. Each links to its card, if you would rather look something up.

1 Maintain a data analytics solution

25-30%
  1. Workspace roles Use Admin, Member, Contributor, or Viewer to control access across every item in one Fabric workspace.
  2. Item permissions Use item permissions when access should apply to one Fabric item instead of every item in the workspace.
  3. Fine-grained access Restrict Fabric data by object, row, or column when item access is too broad for the audience.
  4. Sensitivity labels Apply Microsoft Purview sensitivity labels to classify Fabric items and carry protection through supported downstream content and exports.
  5. Endorse Fabric items Use Promoted for owner recommendations, Certified for reviewed quality, and Master data for authoritative organizational sources.
  6. Workspace Git control Commit workspace changes to Git, update the workspace from Git, and resolve same-item conflicts before synchronizing.
  7. PBIP projects PBIP stores the report and semantic model as readable text files, making Power BI projects easier to version with Git and CI/CD.
  8. Deployment pipelines Move Fabric item definitions through Development, Test, and Production while deployment rules adapt each target environment.
  9. Lineage and impact Use lineage to understand connections and impact analysis to see which downstream items or workspaces a change could affect.
  10. XMLA model management Use the XMLA endpoint with external tools to deploy, script, inspect, and refresh semantic models at fine granularity.
  11. Reusable Power BI assets Use PBIT for reusable report structure, PBIDS for a prepared connection, and shared semantic models for one governed model behind many reports.

2 Prepare data

45-50%
  1. Create a connection Create reusable Fabric connections for cloud or private-network sources, configure authentication, and share them with the right role.
  2. Catalog vs Real-Time hub Use OneLake catalog for Fabric items and governance; use Real-Time hub for streams, KQL data, and Fabric events.
  3. Ingest or access data Choose shortcut, mirroring, pipeline, dataflow, notebook, or eventstream based on copying, freshness, transformation, and streaming needs.
  4. Choose a Fabric store Choose the Fabric data store by workload, data shape, preferred engine, and whether transactional guarantees are required.
  5. OneLake integration Expose Eventhouse or Import semantic model data as Delta tables in OneLake so other Fabric engines can reuse one copy.
  6. Reusable T-SQL objects Use a view for a reusable query, an inline TVF for a parameterized query, and a stored procedure for multi-step data-changing logic.
  7. Enrich data Add derived values or reference context with SQL, PySpark, Power Query, or joins, depending on whether the result must be stored.
  8. Star schema Model measurable events in a fact table and descriptive context in dimensions connected by one-to-many relationships.
  9. Denormalize for analytics Flatten related dimension attributes into fewer tables so analytical queries need fewer joins and semantic models stay simpler.
  10. Aggregate data Filter rows first, group them, calculate aggregates, then use HAVING when a condition depends on the aggregate result.
  11. Join or merge data Choose the join type by which unmatched rows must survive; use MERGE when the target table itself must be inserted, updated, or deleted.
  12. Duplicates and NULLs Deduplicate intentionally, replace missing values only when a meaningful default exists, and test NULL with IS NULL or IS NOT NULL.
  13. Convert data types Convert columns early with CAST, TRY_CAST, CONVERT, or Power Query so joins, sorting, and downstream models use reliable types.
  14. Filter data Use WHERE for rows, HAVING for aggregate groups, and QUALIFY for window results, placing each filter at the earliest valid stage.
  15. Visual query editor Use the visual query editor for no-code, read-only shaping and the SQL query editor when you need full T-SQL control.
  16. T-SQL analytical flow Understand the logical order of WHERE, GROUP BY, HAVING, window functions, and QUALIFY to place filters correctly.
  17. KQL query pipeline Build KQL as a left-to-right pipeline: filter, shape, aggregate, rank, and optionally render the result.
  18. DAX queries A DAX query uses optional DEFINE, required EVALUATE, and optional ORDER BY to return and shape a table from a semantic model.

3 Implement and manage semantic models

25-30%
  1. Semantic model storage Choose Import, DirectQuery, Dual, or Direct Lake by freshness, scale, source, and performance requirements.
  2. Semantic model star schema Use dimensions for filtering and grouping, facts for measures, and clean one-to-many relationships between them.
  3. Relationships and bridges Prefer one-to-many relationships; use bridge tables for many-to-many dimensions and limit bi-directional filtering.
  4. DAX variables and iterators Use VAR to reuse results, X-functions for row-by-row logic, and window functions for ordered row sets.
  5. Calculation groups and parameters Reuse DAX patterns with calculation groups, preserve numeric values with dynamic formats, and let readers swap fields with field parameters.
  6. Large semantic models Enable large semantic model storage when a model must exceed the default size limit or benefit from faster XMLA write operations.
  7. Composite models Mix storage modes or DirectQuery sources only when one model must combine different freshness, scale, or source requirements.
  8. Query and visual performance Use Performance Analyzer to identify whether time is spent in DAX, DirectQuery, rendering, or other visual work before optimizing.
  9. Improve DAX performance Reduce repeated work with variables, prefer simple column filters, and move fixed calculations out of DAX when possible.
  10. Direct Lake framing and fallback Direct Lake refresh reframes table metadata; SQL-endpoint models can fall back to DirectQuery when a query cannot stay in Direct Lake.
  11. Direct Lake options Choose Direct Lake on OneLake for direct multi-item access without fallback, or the SQL-endpoint option when endpoint security and compatibility matter.
  12. Incremental refresh Partition large tables with RangeStart and RangeEnd so refreshes reload only the recent period instead of the complete history.