Microsoft Fabric foundations
Not a scored domain — but every scored question assumes this material. If you are fluent in OneLake, capacities, the three storage engines and Delta Lake, most of the exam becomes a matter of elimination.
- Fabric architecture and the item taxonomy
- OneLake — the single logical lake, and how paths resolve
- Capacities, CUs, smoothing, bursting and throttling
- Lakehouse vs Warehouse vs Eventhouse — the single most tested decision
- Delta Lake internals and OneLake shortcuts
0.1 What Microsoft Fabric is
Microsoft Fabric is an end-to-end, SaaS analytics platform. It unifies data engineering, data integration, data warehousing, real-time intelligence, data science and business intelligence into one product, on one storage layer, under one capacity-based licence.
The word that matters for the exam is SaaS. You do not provision storage accounts, Spark clusters, integration runtimes or SQL pools. Contrast with Azure Synapse + ADF, where each of those is a resource you create and manage.
(unified SaaS analytics)"] --> OL["OneLake
single logical data lake"] F --> DE["Data Engineering
Lakehouse · Notebook · Spark Job"] F --> DF["Data Factory
Pipeline · Dataflow Gen2 · Airflow"] F --> DW["Data Warehouse
T-SQL analytics"] F --> RTI["Real-Time Intelligence
Eventstream · Eventhouse · Activator"] F --> DS["Data Science
Experiment · ML model"] F --> PBI["Power BI
Semantic model · Report"] OL --> D["Delta Lake / Parquet
open format, one copy of data"]
The tenancy hierarchy
Four levels, and questions about governance or security almost always turn on which level a setting lives at:
| Level | What it is | Who controls it |
|---|---|---|
| Tenant | One per Entra ID organization. Home of the admin portal and tenant settings. | Fabric administrator |
| Domain | A logical grouping of workspaces by business area (Finance, Sales). Enables federated governance and data-hub discovery. | Domain admin / contributor |
| Capacity | The compute pool (an F SKU) that a workspace is assigned to. All workloads in the workspace draw CUs from it. | Capacity admin |
| Workspace | The collaboration container holding items. Carries the four roles and the Git connection. | Workspace admin |
Caveat — domain ≠ capacity
A domain is a governance/organizational grouping; a capacity is a billing/compute assignment. They are independent: workspaces in one domain can sit on different capacities, and one capacity can host workspaces from many domains. Questions that mix the two are testing exactly this.
0.2 OneLake — the single logical data lake
OneLake is the "OneDrive for data": one lake per tenant, provisioned automatically, that every Fabric item stores into. There is exactly one, you cannot create a second, and you cannot delete it.
| Attribute | Detail |
|---|---|
| Default table format | Delta Lake (Parquet data files + _delta_log transaction log) |
| API surface | ADLS Gen2-compatible — anything that speaks ADLS Gen2 can address it (abfss://) |
| Hierarchy | Tenant → Workspace → Item → Tables/ and Files/ |
| Provisioning | Automatic with the tenant — no storage account to create |
| External data | Reached via shortcuts (ADLS Gen2, S3, GCS, Dataverse, S3-compatible) without copying |
| Encryption | At rest by default (Microsoft-managed keys) |
OneLake path anatomy
You will see this format in notebook code and in shortcut/pipeline configuration. Be able to read it:
abfss://<workspace>@onelake.dfs.fabric.microsoft.com/<item>.Lakehouse/Tables/<table>
abfss://<workspace>@onelake.dfs.fabric.microsoft.com/<item>.Lakehouse/Files/<folder>
# Workspace and item may be given as names or as GUIDs — GUIDs are stable
# across renames, so prefer them in production pipelines and shortcuts.Caveat — Tables/ vs Files/
In a Lakehouse, Tables/ holds managed Delta tables that appear in the SQL analytics endpoint and the object explorer. Files/ holds unmanaged files of any format (CSV, JSON, images, checkpoints) that do not appear as tables. Writing a Parquet file into Files/ does not create a queryable table — it must be a Delta table under Tables/, and it must be in the correct folder structure to be auto-discovered.
0.3 Capacity, CUs, smoothing and throttling
Fabric compute is bought as a capacity, measured in Capacity Units (CUs). Every operation — a Spark job, a T-SQL query, a Dataflow refresh, a pipeline run — consumes CU-seconds from the capacity the workspace sits on.
F SKUs and Spark vCores
The rule to memorize: 1 CU = 2 Spark vCores, with a 3× burst factor available on top.
| SKU | CUs | Base Spark vCores | Max with 3× burst | Typical use |
|---|---|---|---|---|
| F2 | 2 | 4 | 12 | Dev / test / learning |
| F4 | 4 | 8 | 24 | Small team |
| F8 | 8 | 16 | 48 | Small production |
| F16 | 16 | 32 | 96 | Medium production |
| F32 | 32 | 64 | 192 | Large production |
| F64 | 64 | 128 | 384 | Enterprise key threshold |
| F128 – F2048 | 128 – 2048 | 256 – 4096 | 768 – 12288 | Large enterprise |
Caveat — why F64 is the magic number
F64 (and above) is the threshold where free-licensed users can consume Power BI content in the workspace — below F64, every consumer needs a Power BI Pro licence. F64 is also the entry point for several premium capabilities. If a question mentions "users without Pro licences need to view reports", the answer involves F64+.
Smoothing, bursting and throttling
Fabric does not hard-stop you the moment you exceed your CUs. It applies three mechanisms in sequence, and the exam likes the ordering:
| Mechanism | What it does |
|---|---|
| Bursting | Temporarily uses more compute than the SKU provides so a job finishes faster. Spark bursts up to 3×. |
| Smoothing | Spreads the CU cost of that burst over time so short spikes don't trip limits. Background operations (pipelines, Spark jobs, refreshes) smooth over 24 hours; interactive operations smooth over 5 minutes. |
| Throttling | Applied only once smoothed usage has borrowed too far into future capacity. |
The throttling ladder, by how much future capacity has been consumed:
| Future capacity used | Stage | Effect |
|---|---|---|
| Under 10 minutes | Overage protection | Nothing — smoothing absorbs it |
| 10 – 60 minutes | Interactive delay | Interactive requests delayed ~20 s; background jobs unaffected |
| 60 minutes – 24 hours | Interactive rejection | Interactive requests rejected; background jobs still run |
| Over 24 hours | Background rejection | Everything rejected — the capacity is effectively stalled |
Diagnosing capacity pain
The Microsoft Fabric Capacity Metrics app is the answer whenever a question asks how to investigate CU consumption, find the noisiest item, or see throttling and carryforward. Remediation is: scale the SKU up, move the offending workspace to another capacity, or reschedule heavy background jobs off-peak.
Pausing a capacity
Pausing stops billing, but it also makes every item on that capacity unusable — reports won't render, scheduled jobs won't run. Any accumulated carryforward is settled at the moment of pause. A trial capacity runs 60 days and behaves like an F64 for feature-gating purposes.
0.4 The Fabric item taxonomy
Know which workload an item belongs to and, more importantly, what it is for. Distractors in this exam are usually real items used in the wrong role.
| Workload | Items | What you use them for |
|---|---|---|
| Data Engineering | Lakehouse, Notebook, Spark Job Definition, Environment | Spark-based storage and transformation; Environment packages libraries and Spark config for reuse |
| Data Factory | Data Pipeline, Dataflow Gen2, Copy job, Apache Airflow job, Mirrored database | Ingestion and orchestration; Airflow job is managed Apache Airflow for DAG-based orchestration |
| Data Warehouse | Warehouse, SQL analytics endpoint | Full read/write T-SQL, stored procedures, multi-table transactions |
| Real-Time Intelligence | Eventstream, Eventhouse, KQL database, KQL queryset, Real-time dashboard, Activator | Streaming ingestion, time-series storage and KQL analytics, event-driven alerting |
| Data Science | Experiment, ML model | MLflow-backed training and model registry |
| Power BI | Semantic model, Report, Dashboard | The BI serving layer over everything above |
Three items people confuse
Copy job — a simplified, standalone ingestion item for batch or incremental copy without authoring a whole pipeline. Environment — a reusable bundle of libraries + Spark properties + resources you attach to notebooks. Activator (formerly Data Activator / Reflex) — the no-code rules engine that watches a stream or report and fires actions or alerts.
0.5 Lakehouse vs Warehouse vs Eventhouse
This is the highest-frequency decision on the exam. All three store data in OneLake; they differ in engine, write path and workload shape.
stored procs, transactions"| WH["Warehouse"] Q1 -->|"Spark + SQL, files and tables
data science, unstructured"| LH["Lakehouse"] Q1 -->|"High-volume events
time-series, logs, sub-second"| EH["Eventhouse / KQL DB"] LH --> SEP["SQL analytics endpoint
auto-created, READ-ONLY"] WH --> XDB["Native cross-database queries
across Warehouses + Lakehouse endpoints"]
| Capability | Lakehouse | Warehouse | Eventhouse (KQL DB) |
|---|---|---|---|
| Primary engine | Apache Spark | T-SQL (distributed SQL engine) | Kusto / KQL |
| Storage format | Delta Lake | Delta Lake | Native Kusto storage, exposed as Delta in OneLake |
| T-SQL writes | ❌ Endpoint is read-only | ✅ Full INSERT / UPDATE / DELETE / MERGE | ❌ (KQL .ingest / update policies) |
| Stored procedures | ❌ | ✅ | Stored functions |
| Multi-table transactions | ❌ (per-table ACID only) | ✅ | ❌ |
| Unstructured files | ✅ Files/ section | ❌ Tables only | ❌ |
| Schema approach | Schema-on-read and on-write | Schema-on-write | Schema-on-write, with update policies |
| Ingestion latency | Batch / micro-batch | Batch | Seconds, streaming-native |
| Best persona | Data engineer, data scientist | SQL analyst, BI developer | Ops / IoT / security analyst |
Caveat — the read-only SQL analytics endpoint
Every Lakehouse automatically gets a SQL analytics endpoint. It speaks T-SQL, supports views, RLS/CLS and DDM, and is read-only for data — no INSERT, UPDATE, DELETE or MERGE against Lakehouse tables through it. If the requirement includes T-SQL writes or stored procedures, the answer is a Warehouse. This trap appears on nearly every DP-700 attempt.
Endpoint metadata lag
The SQL analytics endpoint syncs table metadata from the Delta log asynchronously. A table just written by Spark can take a short while to become visible or to reflect a schema change. If a question describes "the table exists in the Lakehouse but the SQL endpoint doesn't show it / shows stale columns", that is metadata sync lag — refresh the endpoint metadata rather than rewriting the data.
0.6 Delta Lake internals
Delta Lake is the default table format across Fabric. It is Parquet data files plus a _delta_log transaction log, and that log is what buys you ACID, time travel and change feeds.
(data files)"] L --> J0["00000000000000000000.json"] L --> J1["00000000000000000001.json"] L --> CP["00000000000000000010.checkpoint.parquet
(checkpoint every 10 commits)"]
| Feature | What it gives you | How |
|---|---|---|
| ACID transactions | Atomic, consistent, isolated, durable writes on a data lake | Optimistic concurrency over the transaction log |
| Time travel | Query the table as it was at an earlier version or timestamp | VERSION AS OF n / TIMESTAMP AS OF '…' |
| Schema enforcement | Rejects writes whose schema doesn't match | On by default |
| Schema evolution | Adds new columns on write instead of failing | .option("mergeSchema","true") |
| Change Data Feed (CDF) | Read row-level inserts/updates/deletes as a stream | Enable on the table, then .option("readChangeFeed","true") |
| MERGE | Upserts and SCD Type 2 in one atomic statement | MERGE INTO … WHEN MATCHED … WHEN NOT MATCHED |
| Deletion vectors | Marks rows deleted without rewriting whole Parquet files — much faster deletes/updates | Table property; OPTIMIZE later materializes the changes |
Table maintenance: OPTIMIZE, VACUUM, V-Order, Z-Order
Four operations that are constantly confused with each other. Learn the one-line distinction for each:
| Operation | Problem it solves | What it actually does |
|---|---|---|
| OPTIMIZE | Too many small files | Compacts small Parquet files into fewer larger ones. Does not delete anything. |
| VACUUM | Storage bloat from old file versions | Deletes data files no longer referenced by the log, beyond the retention window. Does not compact anything. |
| V-Order | General read speed | Fabric-specific write-time optimization — sorting/encoding inside Parquet files for fast reads by all Fabric engines. |
| Z-Order | Slow filtered queries on specific columns | Co-locates related values across files so data skipping can prune more. Applied as part of OPTIMIZE. |
-- Compact small files
OPTIMIZE gold_sales;
-- Compact AND co-locate by the columns you filter on most
OPTIMIZE gold_sales ZORDER BY (region, product_category);
-- Remove unreferenced files older than the retention window (default 7 days / 168 h)
VACUUM gold_sales;
VACUUM gold_sales RETAIN 168 HOURS;Caveat — the four classic Delta traps
1. OPTIMIZE ≠ VACUUM: one compacts, the other deletes. A "too many small files" symptom is always OPTIMIZE.
2. VACUUM's default retention is 7 days (168 hours). Vacuuming below that breaks time travel to those versions and can break concurrent readers — Spark blocks it unless you override the retention-check safety setting.
3. V-Order is within files at write time; Z-Order is across files at optimize time. They are complementary, not alternatives.
4. V-Order costs write throughput to buy read throughput. For write-heavy bronze/staging tables it is legitimate to disable it; keep it on for gold tables that get read constantly.
Don't over-partition
Partitioning helps only when partitions are large and queries filter on the partition column. Partitioning a modest table by a high-cardinality column (customer ID, timestamp to the second) creates the small-file problem you were trying to avoid. Fabric's guidance: prefer Z-Order / V-Order plus OPTIMIZE, and partition only large tables on a low-cardinality column such as date.
0.7 OneLake shortcuts
A shortcut is a pointer: it makes data stored elsewhere appear as a folder or table inside your Lakehouse without copying it. The data stays at the source and is read live.
| Shortcut target | Type | Notes |
|---|---|---|
| Another OneLake location | Internal | Cross-workspace and cross-item; lowest latency |
| ADLS Gen2 | External | abfss://; org account or SAS/service principal |
| Amazon S3 / S3-compatible | External | Cross-cloud |
| Google Cloud Storage | External | Cross-cloud |
| Dataverse | External | Power Platform data |
Caveat — what shortcuts do and don't do
Shortcuts are not copies, so: the source system's permissions apply in addition to OneLake permissions; external shortcuts carry higher read latency than native OneLake data; and shortcut data is not touched by OPTIMIZE or VACUUM — maintenance is the source's responsibility. Writes through a shortcut are possible for some target types but the classic exam framing is read-oriented virtualization.
Shortcut vs mirroring vs copy — one line each
Shortcut = point at the data where it lives, read it live, nothing is duplicated.
Mirroring = continuously replicate a source database into OneLake as Delta via CDC, near real-time, one-way.
Copy (pipeline / Copy job) = move a bounded batch of data on a schedule or trigger.
0.8 Languages and where they apply
| Language | Where it runs | Reach for it when… |
|---|---|---|
| PySpark | Notebooks, Spark job definitions | Large-scale or complex transformation, ML, streaming with joins |
| Spark SQL | Notebooks (%%sql) | Set-based logic over Lakehouse tables without leaving Spark |
| T-SQL | Warehouse (read/write), SQL analytics endpoint (read-only) | Warehouse transforms, stored procedures, RLS/CLS/DDM |
| KQL | Eventhouse / KQL database, KQL querysets | Time-series, logs, real-time aggregation and alerting |
| M (Power Query) | Dataflow Gen2 | Low-code transformation and broad SaaS connectivity |
| DAX | Semantic models | BI measures and semantic-model RLS |
What the exam actually asks
You are tested on choosing the language far more than writing it. "Transform data already landing in an Eventhouse" → KQL. "Analyst needs no-code with 150+ connectors" → Dataflow Gen2 (M). "Stored procedure required" → T-SQL in a Warehouse. Read the persona and the constraint in the stem before you look at the options.
0.9 Fabric vs the Azure data stack
| Dimension | Microsoft Fabric | Azure Synapse + Data Factory |
|---|---|---|
| Service model | SaaS — nothing to provision | PaaS — you create and manage resources |
| Storage | OneLake, automatic, one per tenant | ADLS Gen2 accounts you provision |
| Compute | Shared capacity in CUs (F SKUs) | Dedicated SQL/Spark pools, integration runtimes |
| Real-time | Eventstream + Eventhouse, built in | Event Hubs + Stream Analytics, separate services |
| Portal | One (app.fabric.microsoft.com) | Azure portal + Synapse Studio + ADF Studio |
| Governance | Built-in, with Purview integration | Purview deployed and wired up separately |
Scenario quick reference
| Scenario | Deciding constraint | Answer |
|---|---|---|
| Analysts must write stored procedures | T-SQL read/write | Warehouse |
| Engineers need PySpark and SQL over the same tables | Mixed engine | Lakehouse |
| Millions of IoT events, sub-second query | Time-series at scale | Eventhouse / KQL database |
| Query S3 data without copying it | No data movement | OneLake shortcut |
| Keep a near real-time replica of Azure SQL DB | Continuous CDC | Mirroring |
| Free-licensed users must view reports | Licensing threshold | F64 or higher capacity |
| Reads slowed by thousands of tiny files | Small-file problem | OPTIMIZE |
| Storage cost growing from old versions | Unreferenced files | VACUUM (respect 7-day retention) |
| Need yesterday's version of a table | Point-in-time read | Time travel (VERSION AS OF) |
| Reusable library set across notebooks | Dependency management | Environment |