DP-600 scenarios are mostly about deciding where a responsibility belongs. Data can be transformed in the lakehouse, warehouse, or semantic model. Security can be applied at workspace, item, model, column, object, or file level. Performance can fail in SQL, KQL, Direct Lake, DAX, or a visual. The strongest answer usually places the control in the earliest appropriate layer without duplicating business logic.
The scenarios below stay inside the current live DP-600 scope for October 4, 2026. Microsoft has announced an English update for October 19, so candidates sitting later should check the future guide.
Scenario one: several reports need the same business measure
Put the authoritative metric in the shared semantic model rather than recreating it in each report. Central ownership improves consistency and simplifies later changes.
If the logic is a reusable relational transformation rather than a semantic calculation, the warehouse or lakehouse may be the stronger layer.
Scenario two: a user needs one report but not the whole workspace
Use item-level access or app distribution rather than granting a broad workspace role. Collaboration rights and consumption rights are different requirements.
Then apply RLS or other model controls if the user should see only part of the data.
Scenario three: event data must be analyzed with low latency
Use a real-time path such as Eventhouse and KQL where the workload fits, rather than forcing every event into a batch warehouse before analysis.
The design can still integrate with OneLake and semantic models for broader analytical consumption.
Scenario four: a star schema is correct but DAX remains slow
Measure the expensive calculation, review iterators, filter logic, cardinality, and model relationships, and simplify the measure before changing storage mode.
The DAX layer should be optimized when evidence shows the bottleneck is semantic calculation rather than upstream query execution.
Scenario five: Direct Lake falls back and report latency increases
Investigate the conditions causing fallback and whether the model or source configuration can remain on the intended Direct Lake path. Do not assume Direct Lake always behaves like imported data.
Storage mode is an operational characteristic that should be monitored and understood.
Scenario six: an upstream table change may break several models
Use impact analysis and dependency knowledge before deployment. Coordinate the change, provide a compatibility path if needed, and update downstream owners.
A lakehouse or warehouse schema change is not local when many semantic models and reports depend on it.
Scenario seven: sensitive data should be hidden from one group
Choose the control that matches the requirement. RLS filters rows, column-level controls restrict columns, OLS can hide objects, and file-level permissions protect underlying files.
Sensitivity labels classify data but do not replace authorization.
Scenario eight: two environments drift because analysts edit production manually
Move the assets into version-controlled projects and deployment pipelines. Environment-specific differences should be explicit configuration rather than undocumented edits.
The Fabric and Power BI lifecycle becomes stronger when the intended state is reviewable.
Scenario nine: refresh takes too long because all history is reprocessed
Use incremental refresh when only recent partitions change and the model/data source support it. Reprocessing unchanged history wastes time and capacity.
The correct refresh design follows data-change behavior rather than a generic schedule.
Scenario ten: a warehouse query is slow but report DAX is simple
Optimize the warehouse or SQL query first: filtering, joins, aggregation, and physical design may be the real cause. Moving logic into DAX can make ownership worse.
Scenario eleven: a team wants to place every transformation in DAX because analysts know Power BI well. If the logic defines reusable relational cleansing, deduplication, or dimensional shaping, move it upstream into the warehouse or lakehouse. DAX should not become a substitute for a curated data layer simply because it is familiar.
Scenario twelve: a workspace contains certified content, but a user builds from an uncertified copy with different measures. Improve discoverability and reuse of the governed semantic model, and review endorsement and ownership. Certification is useful only when consumers can find the trusted asset and understand why it should be preferred.
Scenario thirteen: a report using Direct Lake performs well until a model feature forces fallback. Diagnose the condition, decide whether the feature is essential, and compare the trade-off. The best architecture may accept fallback for required functionality, or may redesign the model to preserve Direct Lake behavior. Performance and capability need to be balanced.
Scenario fourteen: a data team changes a Gold table name and dozens of reports break. The technical change was small, but dependency management failed. Use impact analysis, compatibility views, staged rollout, or coordinated model updates so shared data contracts are treated as interfaces rather than local tables.
Scenario fifteen: event data is copied into a warehouse every minute only so analysts can run KQL-style exploration. Re-evaluate whether Eventhouse or Real-Time Intelligence should own that workload and whether downstream BI needs can consume curated outputs later. Copying data by default can add latency and operations without improving the user need.
Scenario sixteen: an executive dashboard needs one measure in several models, and teams keep redefining it. Decide whether the business logic belongs in one shared semantic model or in a curated upstream table that several models consume. The answer should create one authoritative definition instead of synchronizing duplicated formulas manually.
Scenario seventeen: a user is blocked from a column in the semantic model but can still query the same field through underlying lakehouse access. Fix the lower-level data authorization or redesign the access path. Semantic security does not protect a separate physical access channel automatically.
Scenario eighteen: the test workspace is correct, but production uses different connections and a manually changed model property. Make those environment differences explicit in the deployment process and remove direct production edits. Lifecycle controls are strongest when production can be recreated from versioned assets and configuration.
Scenario nineteen: a semantic model refreshes all history and misses its window even though only recent data changes. Apply incremental refresh if the data source and model support it, and verify partition behavior. The fix should follow the data-change pattern, not simply schedule the same expensive operation earlier.
Scenario twenty: a query is fast in the warehouse, DAX is simple, but the page still feels slow because it has many interactive visuals. Reduce visual query workload and redesign the page. Performance is end to end; the responsible layer can be the report experience even when data and model are healthy.
Scenario twenty-one: a team stores a sensitive file in OneLake and relies only on a Power BI report to hide the field. Protect the underlying file or item path as well as the semantic experience. Users with direct data access can bypass report-level presentation, so the control should exist at the layer where the sensitive asset lives.
Scenario twenty-two: a deployment pipeline moves a model successfully, but the production data source points to the test environment. Treat data-source configuration as environment-specific deployment state and validate it before release. Successful artifact promotion does not prove that every connection is correct.
Scenario twenty-three: an analyst creates a fast local measure that conflicts with the shared certified metric. Remove or rename the duplicate and reinforce model ownership. Faster report development is not worth semantic drift when the organization expects one definition.
Scenario twenty-four: warehouse performance is good until a new view joins several large tables at full detail. Optimize or pre-shape the data in the relational layer rather than compensating with a more powerful semantic model. Upstream inefficiency should be fixed where it originates.
Scenario twenty-five: a real-time dashboard needs current events while monthly finance reporting needs stable historical logic. Use the appropriate Fabric engines and curate shared data where the use cases intersect. One analytical platform can support both without forcing both workloads into the same execution pattern.
Scenario twenty-six: a certified model is secure, but a deployment change removes an OLS rule. Add model-security validation to the release process. Governance should be tested during deployment just like schema and calculations, because a successful refresh does not prove that the access model remained intact.
Scenario twenty-seven: a business user needs access to a certified report but should not build new content from its semantic model. Grant only the consumption capability needed rather than broad build or workspace rights. Access design should follow the user’s task, not a one-size-fits-all role.
Scenario twenty-eight: a KQL query is efficient, but data arrives late from the source. Fix the ingestion or source-delivery path instead of rewriting KQL. Query performance and data freshness are different quality dimensions.
Scenario twenty-nine: a model uses composite sources and one remote table becomes unavailable. Design the report experience and monitoring so users can distinguish partial data failure from a complete model outage. Composite models create additional dependency paths that should be observable.
Scenario thirty: a deployment succeeds but an impact check reveals a heavily used downstream report will break. Delay or redesign the release rather than treating deployment success as the only criterion. Safe analytics change includes downstream compatibility.
Scenario thirty-one: a semantic model owner wants to change a certified measure definition without telling report authors. Treat the measure as a shared contract. Use versioned change, impact review, validation against known results, and communication so downstream users understand the semantic change rather than discovering it through conflicting numbers.
Scenario thirty-two: a lakehouse is technically available, but a workspace user cannot discover it through the expected catalog path. Check permissions, item visibility, ownership, and catalog metadata before rebuilding the asset. Discoverability failures can look like missing data even when the underlying tables are healthy.
The DP-600 mindset is layer-aware. For every scenario, identify source, storage, transformation, semantic model, security, deployment, and consumer behavior before choosing the fix.