Fabric DP-700 cheat sheet

Workspace role order is Admin > Member > Contributor > Viewer. Contributor can create items and write data but cannot manage workspace permissions or add members.

OneLake uses a hierarchical path per item: onelake:////... ; every Fabric item stores its data under its workspace and item folder.

A workspace must be assigned to a Fabric capacity before its items run. SKUs range from F2 (smallest) to F2048, measured in capacity units.

Lakehouse = Spark + Delta tables + an auto-generated, read-only T-SQL SQL analytics endpoint. Warehouse = full T-SQL DML, multi-statement transactions, stored procedures, views.

Shortcuts store no data copy; deleting a shortcut never deletes the source. Shortcuts may chain but circular references are blocked.

Deployment pipelines map stages (Development/Test/Production) to workspaces and copy item definitions forward; deployment rules override per-stage connections and parameters. Not every item type is supported.

Promotion endorsement requires write permission on the item; certification requires approval by a tenant-designated security group. Both render as badges in search results.

Purview sensitivity labels applied to Fabric items are inherited by downstream items that Fabric can trace through lineage.

Git integration connects a workspace to an Azure Repos or GitHub branch; only supported item types are tracked, and changes flow via commit and update operations.

Copy job is a standalone no-code item for bulk and incremental movement between sources and destinations; a Copy activity is the pipeline-level equivalent for orchestrated runs.

Dataflow Gen2 is built on Power Query Online and can write results to lakehouse tables, warehouse tables, KQL databases, and Azure SQL.

Core pipeline activities: Copy, Notebook, Dataflow, Stored Procedure, Lookup, Get Metadata, ForEach, If Condition, Until, Wait, Set Variable, Web.

Eventstream sources include Event Hubs, IoT Hub, Kafka, CDC feeds, and sample data; destinations include lakehouse, KQL database, derived stream, and custom endpoint.

Delta maintenance: OPTIMIZE compacts small files (optionally with Z-ORDER); VACUUM removes unreferenced files with a default retention threshold of seven days.

Incremental load patterns: watermark column comparison, Fabric CDC, or database mirroring - full reloads are reserved for initial or corrective loads.

Spark notebooks default to PySpark and can mix languages with cell magics such as %%pyspark, %%sql, and %%scala; attach a lakehouse to read and write Delta tables.

V-Order is a write-time Parquet optimization enabled by default in Fabric Spark; it improves read throughput, particularly for Power BI Direct Lake models.

Schema drift is handled in Delta by merge-schema options during writes; without it, new columns fail the write or are dropped.

The Monitoring hub lists activity runs, item runs, and refreshes across workspaces with status, duration, and error text, filterable by workspace, item, and time range.

The Fabric Capacity Metrics app reports compute and storage consumption per workspace and item, plus overload and throttling signals for the capacity.

Capacity smoothing spreads short compute spikes across a 24-hour window so brief peaks above the limit do not immediately cause rejection.

Throttling escalates in stages: interactive delay, then interactive rejection, then background rejection, once smoothed utilization stays over capacity.

Warehouse tuning: create or update statistics on join and filter columns after large loads; the optimizer relies on them to estimate cardinality.

Query insights surfaces the longest-running and most frequent warehouse queries with plans and resource usage, and flags missing statistics.

Frequent small writes cause Direct Lake framing to degrade; run OPTIMIZE and keep V-Order enabled. When guardrails are exceeded, the model falls back to DirectQuery.

Spark tuning: enable autoscale and dynamic allocation, watch shuffle size and partition skew in the Spark UI, and read Spark Advisor hints after notebook runs.

KQL tuning: apply time filters first, use materialized views for repeated aggregations, and rely on query caching for repeated identical queries.