DP-500 common mistakes
DP-500 · Understand the traps and how to avoid them.
When asked to secure a semantic model, the candidate applies row-level security roles only and ignores object-level and column-level security, so the answer leaves sensitive columns visible to every viewer of the dataset.
Candidates learn RLS as the default security control and stop there. They do not distinguish filtering rows from restricting which tables, columns, or measures a principal can read, and they forget that a single dataset serves many audiences with different need-to-know.
What to do instead
For each security scenario, write down two separate decisions: which rows each principal may see (RLS) and which objects/columns/measures each may see (OLS/CLS). Remember that OLS is configured per role in the model and that a member of multiple roles gets the union of permissions, so test with a user in two roles.
The candidate designs a star schema but leaves the fact table wide with descriptive text columns (customer name, product category, region), and then answers modeling questions as if that denormalized table were the dimension model.
Importing a flat reporting extract is the fastest path to a working report, so candidates never practice splitting it. They also conflate a single wide table with a proper star schema because both 'work' in a small demo.
What to do instead
Practice taking one flat extract and decomposing it into a fact table at a declared grain plus conformed dimensions with surrogate keys. Be able to state the grain of each fact table in one sentence and to explain why a snowflake or a bridge table is needed for many-to-many relationships.
When asked to choose between import, DirectQuery, and Direct Lake, the candidate picks one mode globally instead of per table, and ignores the implications for refresh, query folding, and composite-model restrictions.
Study material presents storage modes as a simple three-way choice. Candidates memorize definitions but never work through a mixed scenario where a large fact table needs near-real-time access while small dimensions should be imported.
What to do instead
For every storage-mode question, answer three things: latency requirement, data volume, and source capability (does it fold?). Then justify a composite model, noting which tables can be DirectQuery, that aggregation tables can serve as import, and what breaks when a DirectQuery source cannot fold a transformation.
The candidate treats deployment pipelines and workspace separation as interchangeable and cannot describe how to promote content from development to test to production without breaking connections or permissions.
Both features involve multiple workspaces, so candidates blur them. They also rarely have hands-on experience with pipeline stage rules or with parameterized data sources, so they answer from the feature name rather than from behavior.
What to do instead
Learn the division of labor: workspaces hold content and permissions, pipelines move that content between stages. Be able to explain stage rules that rebind a semantic model to a different database per stage, and why you parameterize connections rather than editing them by hand.
On monitoring questions, the candidate names a single tool (for example, query diagnostics or the capacity metrics app) as the answer to every performance problem instead of matching the tool to the layer being investigated.
Tool names are easy to memorize and hard to place. Candidates do not build a mental model of the layers (source, gateway, engine, visual, capacity) and therefore cannot say which signal each tool reveals.
What to do instead
Build a layer-to-tool map and rehearse it: gateway logs and gateway performance monitoring for connectivity and throughput, query diagnostics and Performance Analyzer for per-visual and per-query timing, Log Analytics and the capacity metrics app for capacity-level throttling and overload, and DAX Studio for engine-level query plans.
The candidate writes DAX that works but is slow, using iterators over large fact tables, nested CALCULATE with filters that cannot be pushed down, or bidirectional relationships used as a shortcut for filtering.
Correctness is validated by the numbers matching, so performance never gets tested. Candidates also reach for bidirectional cross-filtering because it makes a visual 'look right' without understanding the ambiguity and cost it introduces.
What to do instead
Before finalizing a measure, ask whether the filter can be applied at the column level rather than row by row, and prefer base-measure-plus-CALCULATE patterns over nested iterators. Treat bidirectional relationships as a last resort: justify them with a specific many-to-many need and prefer bridge tables or CROSSFILTER at the measure level.
The candidate answers data-governance questions by describing sensitivity labels alone and omits lineage, endorsement, and the distinction between technical and business metadata.
Labels are the most visible governance feature, so they dominate study time. Candidates do not connect labels to downstream enforcement (export restrictions, protection inherited by exported files) or to the catalog functions that let consumers find and trust data.
What to do instead
For each governance scenario, separate three concerns: classification (sensitivity labels and their protection behavior), discovery and trust (lineage view, endorsement promotion, certified versus promoted), and metadata ownership (who maintains descriptions and domain assignment). Be able to say what a label does to an exported file.
The candidate designs incremental refresh but cannot explain how the range parameters drive partition creation, and therefore misstates what happens on the first refresh or how to backfill history.
The feature is configured through a dialog, so candidates remember the checkboxes but not the underlying partition logic. They also miss that the parameters must exist in the model with the exact expected names and types before the policy is applied.
What to do instead
Be able to describe the mechanics: two datetime parameters define the range, the policy splits the table into historical and incremental partitions, the first refresh materializes history, and each later refresh rebuilds only partitions in the incremental window. State the query-folding requirement for the source.
The candidate assumes the semantic model is the only performance lever and proposes model changes for problems that actually originate in the source query, the gateway, or the visual layer.
Most practice happens inside the modeling tool, so candidates attribute every slow report to DAX or relationships. They do not consider how many visuals run per page, how high-cardinality columns inflate the model, or how a slow source query blocks refresh.
What to do instead
Diagnose in order: is the delay at refresh (source/gateway), at query time (model/DAX), or at render (visuals)? Reduce visual count per page, remove unused high-cardinality columns, and check whether the source query itself is the bottleneck before rewriting measures.
The candidate designs enterprise models without declaring granularity or handling slowly changing dimensions, then answers questions about historical accuracy by assuming the current dimension attributes apply to all history.
Sample datasets have clean, single-version dimensions, so the problem never appears in practice. Candidates also treat the dimension as a lookup rather than as a time-varying entity that needs versioning.
What to do instead
For every fact table, state the grain explicitly and identify which dimension attributes change over time. Then choose a strategy: type 2 versioning with effective dates and a current-row flag, or a fixed snapshot attribute in the fact. Explain how a report answers 'what was the customer's segment at the time of sale'.