DP-600 quick review

Memory hook: Access to the room is different from access to every record.

Must remember

Workspace roles determine collaboration powers across a workspace. Give consumers only the access they need; a broad editing role is not a substitute for a carefully secured app or shared item. Item permissions grant access to a particular lakehouse, warehouse, report or semantic model. Build on a model enables creating downstream content; it is different from merely viewing a report.

Data authorization must cover each path. SQL grants and row/column restrictions protect the SQL interface; file access through OneLake is another path. Semantic-model row-level security filters records; object-level security hides protected model objects. Model RLS applies to consumers under the supported role rules, not as an effective boundary against workspace administrators/editors. Test with the intended identity and its real combination of roles.

Sensitivity labels classify information and can preserve protection in supported export scenarios. Labels do not replace every data-engine permission. Endorsement signals trust: promotion and certification help consumers find approved content, but neither repairs incorrect calculations. Certification is governed by the tenant's configured authority.

Prefer groups over numerous direct user grants. Trace a consumer from report to model to source, including delegated versus fixed connection identity. A report can load while one visual fails because its underlying model or source permission differs. Inspect lineage and audit changes, and validate file, SQL, model and export paths independently.

Choose under exam pressure

Traps

• A sensitivity label is not a universal SQL/file access control.
• Workspace editing access can defeat assumptions made for read-only model consumers.

Practise this topic

Memory hook: Version the definition; validate the environment and data separately.

Must remember

Git integration tracks supported workspace item definitions, not a complete backup of every data row, credential or runtime state. Use branches, reviewed changes and clear workspace ownership. A Power BI project (.pbip) separates report/model definitions into files suitable for version control; inspect diffs and exclude secrets and local transient files.

Deployment pipelines promote supported items between stages. Check dependencies, environment-specific connections, parameters, ownership, permissions and refresh behavior after deployment. A successful promotion does not prove that a report now reads the correct production source. Impact analysis follows downstream dependencies from changed dataflows, lakehouses, warehouses and models so affected owners can test.

The XMLA endpoint supports supported semantic-model management and external tooling. Read versus read/write settings, capacity/licensing and permissions matter. Treat a scripted model change as a production deployment with review, validation and recovery planning; it is not a shortcut around governance.

A .pbit template packages reusable report/model/query structure without imported data. A .pbids file describes a supported data-source connection starting point; it is not a full report. Shared semantic models centralize definitions so multiple reports use the same measures. Reuse reduces conflicting business logic, but a bad central change can affect many consumers.

Before release, compare row counts, key measures, role behavior and refresh results with a known baseline. Keep a rollback definition and know whether the underlying schema/data change is reversible. Version control alone cannot undo destructive source-data changes.

Choose under exam pressure

Traps

• Git history does not contain all source data or credentials.
• A deployment pipeline does not validate business totals automatically.

Practise this topic

Memory hook: Choose the engine for the work, then decide whether to copy.

Must remember

A lakehouse suits Delta tables, files and Spark-based engineering with a SQL analytics endpoint for supported queries. A warehouse suits relational T-SQL warehousing and transactional data manipulation. An Eventhouse/KQL database suits time-oriented events, logs and interactive exploration. Select the store by query pattern, transformation tools and operational needs, not by the word lake alone.

Discover governed assets in OneLake catalog and streaming/event sources in Real-Time hub. Discovery does not grant access. Connections bind a source and authentication method; gateways may be needed for sources outside directly reachable cloud paths. Separate author credentials from the identity used for unattended execution.

Ingestion copies data into a destination on a schedule or continuously. A shortcut exposes supported existing storage without maintaining another full copy. Mirroring replicates supported operational changes with its own source/type/latency constraints. Shortcuts still require permissions, and their performance/availability can depend on the referenced source.

OneLake integration can expose supported Eventhouse data in Delta format for other analytical engines. Check enablement, availability latency and supported data types. Semantic-model OneLake integration exposes supported model-table data for downstream reuse; it does not mean exported rows include every interactive measure, report filter or security behavior.

Use the lakehouse SQL endpoint for its supported read/query surface; do not assume it permits warehouse-style table DML. Keep transformations in the appropriate engine, then verify the published schema and freshness before building dependent models.

Choose under exam pressure

Traps

• A shortcut is not a backup of the source.
• A visible catalog item is not proof of data access.

Practise this topic

Memory hook: Fix the grain before fixing the formula.

Must remember

Declare what one fact row represents. Build dimensions with stable unique keys and facts with validated foreign keys. Denormalizing descriptive attributes can simplify analytical queries, but repeating measures across joined rows can inflate totals. Aggregate only to a grain that still answers the required questions.

An inner join keeps matches; a left join preserves all left-side rows and reveals missing matches with nulls. Union/append stacks compatible rows; it does not enrich columns by key. Duplicated dimension keys can multiply fact records. Compare row counts and aggregates before and after joins, and decide explicitly whether duplicates are invalid or represent legitimate repeated events.

Treat null, empty text and zero separately. Convert types with attention to locale, precision and invalid values. Filter early when it preserves correctness and reduces processed data. Adding a derived column can simplify later modeling, but agree on time zone, rounding and business definitions first.

Views provide reusable query definitions; functions package supported reusable computations; stored procedures encapsulate supported procedural operations. Availability and write capability depend on the Fabric engine. Parameterize approved operations and avoid embedding environment-specific secrets. A view is not automatically a stored copy or a performance cache.

For slowly changing dimensions, choose whether to overwrite attributes or preserve historical versions with effective dates and surrogate keys. A fact must resolve to the intended historical dimension row. This is particularly important when a customer changes region: yesterday's revenue should follow the agreed historical or current-region reporting rule.

Choose under exam pressure

Traps

• Joining on nonunique keys can silently inflate totals.
• Replacing every null with zero changes business meaning.

Practise this topic

Memory hook: Same question, different execution and context.

Must remember

SQL works with relational rowsets: WHERE filters input rows, GROUP BY forms groups and HAVING filters grouped results. A left join followed by a right-table predicate in WHERE can unintentionally eliminate unmatched rows. Count records and distinguish COUNT(*) from counting a nullable expression.

KQL uses a tabular pipeline. Start from the correct table, apply a selective time filter, project needed columns and summarize at the required grain. For example, Events | where Timestamp > ago(1d) | summarize Total=count() by bin(Timestamp, 1h) counts events by hour. The pipe passes a result to the next operator; it is not a shell command.

DAX queries operate over a semantic model and its relationships. EVALUATE returns a table expression; SUMMARIZECOLUMNS can group dimensions and evaluate measures. Existing filter context and measure logic affect the result. A model measure may disagree with raw SQL because its business definition, relationships, security or date role differs.

The Visual query editor builds supported SQL queries interactively. Inspect generated operations and validate the same joins, filters and aggregation semantics you would in hand-written SQL. A graphical canvas does not eliminate cardinality mistakes.

Investigate mismatched totals in a fixed sequence: source snapshot/freshness, permissions, row grain, joins, filters, data types, then calculations. Avoid changing the formula until you know which layer introduced the discrepancy. Test one small known dataset so each expected row and total can be explained.

Choose under exam pressure

Traps

• SQL row filters and group filters occur at different logical stages.
• The same metric name does not prove identical definitions across engines.

Practise this topic

Memory hook: Facts measure events; dimensions describe them.

Must remember

Define the grain of each fact table before choosing relationships. A sales-line table and a monthly budget table have different grain; blindly joining them can multiply values. Dimensions contain descriptive attributes with a unique key, while fact tables contain foreign keys and measures. A star schema makes filtering and aggregation easier to reason about.

Relationship cardinality describes uniqueness: one-to-many commonly links a dimension’s unique key to repeated fact keys. Cross-filter direction controls propagation. Prefer clear single-direction paths where they meet the need; bidirectional filtering can create ambiguity and surprising totals. Many-to-many designs require careful bridge/grain decisions, not just clicking a convenient setting.

Only one relationship between the same tables can be active for a given straightforward path; inactive relationships can be invoked by appropriate calculations such as USERELATIONSHIP. Role-playing dates such as order date and ship date can use separate dimension instances or carefully designed measures with inactive relationships.

Build a complete common date table with unique, contiguous dates over the needed range and configure it appropriately for time intelligence. Sort month names by month number, hide technical keys from report consumers, set data categories/formats and use hierarchies where they aid navigation. A date column with missing days or duplicate timestamps is not automatically a valid date dimension.

Calculated columns are evaluated for rows and stored in Import models; calculated tables materialize model expressions on refresh. Measures evaluate in query context. Choose a column for a relationship/grouping attribute, and a measure for an aggregation that should respond to slicers.

Choose under exam pressure

Traps

• Different fact grain can cause double counting.
• Bidirectional filtering is not a universal fix for a broken model.

Practise this topic

Memory hook: A measure answers the current filter context.

Must remember

SUM(Sales[Amount]) aggregates a column; SUMX(Sales, Sales[Quantity] * Sales[UnitPrice]) iterates rows and evaluates an expression. Row context identifies a current row; filter context defines the allowed set of rows. They are different, and relationships/filter propagation affect the result.

CALCULATE evaluates an expression with modified filter context and can perform context transition from row context. REMOVEFILTERS removes selected filters; KEEPFILTERS intersects rather than replacing the relevant existing filter. Avoid clearing more context than the denominator requires. DIVIDE handles a zero/blank denominator with a chosen alternate result. Variables improve readability and can avoid repeated expression evaluation within their scope.

Time-intelligence measures require a suitable date model and the correct relationship/date context. Year-to-date sums are useful for flows such as sales; balances are often semi-additive because summing month-end balances across time is meaningless. Decide whether the requirement is closing balance, average balance or a different business definition.

Quick measures generate DAX that still needs review. Calculation groups reuse calculation patterns across measures with precedence/format considerations. Visual calculations operate on the visual’s result structure and are not interchangeable with reusable model measures in every scenario.

Use Performance Analyzer to separate visual rendering and query time, then inspect DAX queries and model design. Remove unnecessary columns/rows, reduce high-cardinality text and use suitable types/grain. Excessive bidirectional relationships, expensive iterators over large tables and overly complex visuals can all contribute. A smaller model often helps, but aggregating away required detail changes analytical capability.

Choose under exam pressure

Traps

• A total is evaluated in its own context; it may not be the sum of visible row results.
• Calculated columns do not recalculate for every slicer interaction in an Import model.

Practise this topic

Memory hook: Refresh defines visibility; storage mode defines the query path.

Must remember

Import loads data into the model; DirectQuery queries a supported source; Direct Lake reads supported Delta data from OneLake. Composite models combine supported storage/source configurations. Choose according to freshness, size, source load, latency and security requirements, then test actual behavior.

Direct Lake on OneLake accesses OneLake directly and does not fall back to DirectQuery. Direct Lake on SQL analytics endpoint uses that endpoint for discovery/security integration and can fall back for supported cases when fallback is enabled. SQL views, security requirements or guardrails can change the path. Do not diagnose every Direct Lake slowdown as an Import refresh issue.

Direct Lake framing updates which table data the model references; loading needed columns into memory is a separate operation. Automatic updates, explicit refresh and source availability affect freshness. Capacity limits and model design still matter even when there is no traditional full Import copy.

For Import incremental refresh, define a date/time partitioning policy with appropriate range parameters and source filtering. Historical and refresh windows have different purposes. Confirm folding or efficient source execution; otherwise a partitioned policy may still scan too much data. Detecting changes is not the same as universally detecting every hard deletion.

Large semantic-model storage format supports larger models on appropriate capacity; it does not fix excessive cardinality or inefficient DAX. Measure visual/query duration, refresh time, memory pressure and capacity contention. Remove unnecessary columns, use suitable types and grain, simplify relationships and optimize the expensive query before buying capacity.

Choose under exam pressure

Traps

• Direct Lake does not mean unlimited memory or zero freshness management.
• Increasing capacity can hide an inefficient query without correcting it.

Practise this topic

Memory hook: Reuse a calculation without losing its context.

Must remember

DAX variables name intermediate results within an evaluation scope; they improve clarity and can avoid repeated work. They are evaluated where defined, so moving a variable outside an iterator can change meaning. Iterators such as SUMX create row context, while CALCULATE changes filter context and can perform context transition.

Table filters define the rows available to a calculation. Prefer the narrowest correct filter instead of clearing an entire model for a denominator. Information functions such as ISINSCOPE distinguish hierarchy scope and can support meaningful subtotal behavior. SELECTEDVALUE needs an alternate result when there is no single selected value.

Window functions such as OFFSET, INDEX and WINDOW navigate ordered/partitioned model rows. Specify the relation, ordering and partitioning deliberately; a previous row is not necessarily the previous calendar day. Ties and missing periods must match the business definition.

Calculation groups apply reusable transformations across measures, such as time comparisons. Precedence matters when multiple groups apply. Dynamic format strings preserve numeric values while changing presentation; converting a measure to text with FORMAT changes how downstream visuals can use it. Field parameters let report users switch selected fields/measures without duplicating every visual.

Many-to-many relationships need a deliberate bridge and filter direction. A composite model introduces source/storage boundaries that can change performance and supported semantics. Test totals, subtotals, role behavior and representative slicer combinations, not just the first visible row. A total is a fresh evaluation in total context, not necessarily a sum of displayed cells.

Choose under exam pressure

Traps

• A variable is not re-evaluated every time its name appears.
• A previous ordered row and previous date are different requirements.

Practise this topic