Self-Service Discovery Across a 60-Domain Data Estate
Adventure Works has 2 PB in OneLake across 60 domains. About 400 analysts use notebooks, SQL, and Power BI. They cannot find certified datasets, duplicate tables are common, and PII has spread into several analyst-created lakehouses. The governance team wants self-service without becoming a central bottleneck. Fabric domains, endorsement, sensitivity labels, and the OneLake catalog are available. Each domain has a data steward but no shared operating model. Analysts frequently copy data into personal workspaces because they do not trust the published tables.
1. Design an operating model for discovery and certification that scales beyond the governance team.
Read the worked answer
Make each domain accountable for its own products. The domain steward owns naming, documentation, quality checks, and endorsement status; the central governance team owns standards and audits, not every approval. Create one production workspace per domain with a small number of certified lakehouses and semantic models. Use Fabric domains to group workspaces so analysts can browse by business area in the OneLake catalog.
Use a two-tier endorsement model: Promoted for team-owned, usable items and Certified only for items that meet defined quality, ownership, and sensitivity requirements. Certification requires a named owner, documented refresh SLA, tested RLS, and a support contact. Publish a domain landing page listing certified items and known deprecated duplicates. This removes the central bottleneck while giving analysts a trust signal.
2. PII is appearing in analyst-created lakehouses. What technical and process guardrails would you apply?
Read the worked answer
Classify first: identify PII columns in source systems and apply sensitivity labels at the lakehouse or item level so labels travel with data used in Power BI. Restrict who can create lakehouses in production domains; give analysts a separate sandbox workspace with clear rules. For shared PII, publish a curated, labeled lakehouse with column-level security or a restricted view rather than allowing copies of raw tables.
Process guardrails matter as much as labels. Require a data-handling checklist before a sandbox item is promoted, monitor for copies of labeled data into unlabeled workspaces, and review access quarterly. Do not rely on analysts remembering policy; make the safe path the easy path by providing approved shortcuts and templates. Shortcuts still need access review because they can expose the underlying data.
3. An analyst needs to explore 18 months of application logs and join them to order data. Which Fabric experience would you recommend, and why?
Read the worked answer
Recommend KQL database or Eventhouse for the log exploration if the logs are high-volume, time-series, and queried by time range and text filters; KQL is designed for that pattern and is more efficient than scanning Parquet with Spark for ad hoc log searches. Keep the order data in the lakehouse and join through OneLake shortcuts or a materialized Gold table rather than copying raw logs into the lakehouse.
If the analyst needs heavy transformation, PySpark notebooks are appropriate; if the result is a recurring business report, move it to a semantic model. The judgment call is to match the experience to the query shape: KQL for logs and time-series exploration, Spark SQL for large joins and transformations, Power BI for governed reporting. Do not let a one-off exploration become an unowned production dataset.