Domain 1: Maintain a data analytics solution
- Workspace roles (Admin, Member, Contributor, Viewer) grant increasing capability; assign the least-privilege role that meets a requirement.
- Item-level permissions let you share a single lakehouse, warehouse, semantic model, or report with granular access such as Read, ReadData, ReadAll, or Build.
- Row-level security (RLS) is defined as roles with DAX filter rules on a semantic model; dynamic RLS uses USERPRINCIPALNAME() to filter by the signed-in user.
- Column-level and object-level security (CLS/OLS) hide specific columns or tables per role; a warehouse also enforces column security through T-SQL GRANT and DENY.
- OneLake data access roles apply folder and file-level security inside a lakehouse, complementing workspace and item permissions.
- Microsoft Purview sensitivity labels classify Fabric items and propagate downstream to exports; labels can be mandatory and inherited.
- Endorsement marks trusted content as Promoted or Certified (and master data), surfacing it in the OneLake catalog for discovery.
- Fabric domains group related workspaces for delegated governance, domain admins, and a default sensitivity label.
- Git integration connects a workspace to Azure DevOps or GitHub so you can commit, update, branch, and resolve conflicts on supported items.
- A Power BI Desktop project (.pbip) stores the report and semantic model as source files (TMDL and PBIR), making them friendly to version control.
- Deployment pipelines promote content across development, test, and production stages, with deployment rules so each stage points at the right data source.
- The XMLA endpoint lets you deploy and manage semantic models with tools such as Tabular Editor, SSMS, and the ALM Toolkit.
- Reusable assets include Power BI template (.pbit) files, data source (.pbids) files, and shared semantic models that thin reports connect to live.
- Impact analysis and lineage view reveal downstream dependencies across lakehouses, warehouses, dataflows, and semantic models before you make a change.
Domain 2: Prepare data
- A data connection with the right credentials is required to reach a source; on-premises and network-isolated sources need a gateway, while a managed private endpoint or workspace identity secures Azure connectivity.
- The OneLake catalog and the Real-Time hub help you discover existing data, endorsed items, and streaming sources across the tenant.
- OneLake shortcuts reference external data in place (ADLS Gen2, Amazon S3, Google Cloud Storage, Dataverse, or internal OneLake) without copying it.
- Dataflows Gen2 use Power Query (M) for low-code ingestion and transformation with staging and configurable output destinations.
- The data pipeline Copy activity moves data between supported sources and sinks and can stage, map, and parameterize the load.
- Spark notebooks (PySpark or Spark SQL) ingest and transform data and write managed Delta tables with saveAsTable, using append or overwrite modes.
- Database mirroring continuously replicates supported sources such as Azure SQL Database and Snowflake into OneLake as Delta.
- Choose the right store for a workload: a lakehouse for files and Spark, a warehouse for full T-SQL transactions, an eventhouse or KQL database for real-time telemetry, and a Fabric SQL database for OLTP.
- A star schema of fact and dimension tables (with surrogate keys and sensible grain) is the target model for a lakehouse or warehouse.
- In a warehouse you create views, scalar and table-valued functions, and stored procedures, and build tables with CREATE TABLE AS SELECT (CTAS).
- Data quality work includes removing duplicates, resolving missing or null values, converting column data types, and filtering rows.
- You query with T-SQL through the read-only SQL analytics endpoint or the writable warehouse, using joins, aggregations, and window functions.
- You query telemetry with KQL on an eventhouse using operators such as where, project, summarize, and make-series.
- The Visual Query Editor offers a no-code Power Query experience, and DAX queries (EVALUATE with SUMMARIZECOLUMNS) explore a model; keep Delta tables efficient with OPTIMIZE, V-Order, and VACUUM.
Domain 3: Implement and manage semantic models
- A semantic model can use Import, DirectQuery, Direct Lake, or Dual storage mode; choose based on data volume, freshness, and performance needs.
- Direct Lake reads Delta-Parquet from OneLake directly into memory and reframes when the source changes, combining import-like speed with query-time freshness.
- Direct Lake can fall back to DirectQuery when a capacity guardrail (such as rows scanned) or an unsupported feature is hit; Direct Lake on OneLake and on the SQL analytics endpoint differ in how they read and honor security.
- A star schema with a single cross-filter direction is preferred; bidirectional filtering is used sparingly because it can cause ambiguity and slow queries.
- Relationships can be one-to-many, one-to-one, or many-to-many; a bridge table resolves many-to-many cardinality.
- Only one relationship between two tables is active at a time; USERELATIONSHIP activates an inactive relationship inside a measure, which supports role-playing dimensions.
- DAX variables (VAR and RETURN) improve readability and avoid re-evaluating the same expression.
- Iterators such as SUMX and RANKX operate row by row; CALCULATE performs context transition so a row context becomes a filter context.
- Time intelligence functions such as TOTALYTD and SAMEPERIODLASTYEAR require a contiguous date table that is marked as a date table.
- Calculation groups, dynamic format strings, and field parameters reduce measure sprawl and make reports more flexible.
- Composite models mix Import and DirectQuery or Direct Lake sources, and aggregation tables redirect queries to a smaller summarized table for speed.
- The large semantic model storage format supports models beyond the default size limit and enables read-write XMLA operations.
- Incremental refresh partitions a model by a date range using RangeStart and RangeEnd parameters and can detect data changes to refresh only what changed.
- Optimization tools include Performance Analyzer to break down visual timings, DAX Studio and VertiPaq Analyzer to profile queries and model size, and reducing cardinality to shrink memory.
DP-600 exam tips
- Know the storage-mode decision cold: Import vs DirectQuery vs Direct Lake vs Dual, and exactly what makes a Direct Lake query fall back to DirectQuery.
- Be able to pick the correct security layer for a requirement: workspace role, item permission, row/column/object-level security, or a OneLake data access role.
- Practice reading SQL, KQL, and DAX queries; the exam expects you to choose the right language for a scenario and predict the result.
- Study deployment pipelines and Git integration together: stages, deployment rules, the .pbip project format, and how source control and promotion fit.
- Master DAX evaluation context: row context vs filter context, context transition with CALCULATE, and when a marked date table is required for time intelligence.
Study guide FAQ
What is the difference between DP-600 and DP-700?
DP-600 (Fabric Analytics Engineer) focuses on preparing and serving data and on building and optimizing semantic models with DAX and Direct Lake. DP-700 (Fabric Data Engineer) focuses on data engineering: ingestion pipelines, Spark, and Real-Time Intelligence. The two exams overlap on Fabric fundamentals but target different roles.
What is Direct Lake in Microsoft Fabric?
Direct Lake is a semantic model storage mode that reads Delta-Parquet tables directly from OneLake into memory. It delivers import-like query speed with near-real-time freshness and no scheduled data refresh, and it falls back to DirectQuery when it meets a capacity guardrail or an unsupported feature.
How many questions are on DP-600 and what score do I need to pass?
Expect roughly 40 to 60 questions in a mix of single and multiple choice, hotspot drop-downs, drag-and-drop, and ordered-list items. You need a scaled score of 700 out of 1000 to pass.
Which domain should I focus on most?
Prepare data is the largest area at 45 to 50 percent, so prioritize lakehouse and warehouse transforms and querying with SQL, KQL, and DAX. Then split your remaining study time between maintaining the solution (security, governance, and lifecycle) and implementing semantic models (DAX, storage modes, and optimization), each about 25 to 30 percent.