1.3 Microsoft Fabric Platform Fundamentals

Fabric Is One SaaS Platform

Quick Answer: Microsoft Fabric is a software-as-a-service (SaaS) analytics platform. Every analytics artifact — lakehouse, warehouse, eventhouse, semantic model, notebook, data pipeline, and report — is a typed item that lives in a workspace, stores data in OneLake, and runs on a purchased capacity. There are no separate servers to provision.

Understanding this architecture is foundational because nearly every DP-600 question assumes you know where data physically lives and which item a task belongs in. "Choose between different data stores" is an explicit skill in the Prepare data domain.

OneLake: One Copy of Data

OneLake is the single, tenant-wide logical data lake automatically provisioned with Fabric. Exam-critical properties:

• One per tenant. Like OneDrive for files, every organization gets exactly one OneLake. It removes data silos and means storage location is logical, not a separate account you create.
• Open format. Tabular data is stored in Delta/Parquet, so it is readable by Spark, T-SQL, KQL, and Direct Lake semantic models without conversion or copying.
• Hierarchical addressing. Data is addressed by tenant > workspace > item > folder/table, similar to a file path.
• Shortcuts. A shortcut is a virtual reference that surfaces external storage (Amazon S3, Azure Data Lake Storage Gen2, Google Cloud Storage, or another Fabric workspace) inside OneLake without copying the data. This keeps a single logical lake across many physical sources and is the correct answer whenever a scenario says "make data available without duplicating it."

Workspaces: The Collaboration and Governance Unit

A workspace is the container that holds Fabric items and is the boundary for collaboration, security, capacity, and lifecycle:

• Items (lakehouse, warehouse, semantic model, report, etc.) are created inside a workspace.
• Workspace roles grant baseline access to its contents, layered from most to least privileged.
• A workspace is assigned to exactly one capacity, which supplies its compute.
• Git integration and deployment pipelines operate at the workspace level — making the workspace the natural dev/test/prod boundary tested under "Maintain the analytics development lifecycle."

Capacities: The Compute Engine

A capacity is the pool of purchased compute that powers all workloads in its assigned workspaces. Capacities are sold as Fabric SKUs (for example F2 through large F-series such as F64, where the number is the count of capacity units). All Fabric engines — Spark, SQL warehouse, KQL, semantic-model query — draw from the same shared capacity, so a heavy Spark job can throttle report queries on the same SKU. F64 and above unlocks free Power BI content consumption for report viewers (no per-user Pro license), a common cost-decision question. Capacity sizing therefore affects every workload, not just one engine.

Item Types You Must Recognize

The single most-tested distinction is lakehouse vs. warehouse: the lakehouse SQL analytics endpoint is read-only (writes happen via Spark/notebooks or dataflows), while the warehouse supports full read/write T-SQL with multi-table transactions. Pick the lakehouse for data-engineering and unstructured/Spark workloads, and the warehouse when analysts need to run INSERT/UPDATE/DELETE in pure T-SQL.

Choosing a Data Store: A Decision Guide

Because "choose between different data stores" is an explicit exam objective, internalize this quick decision flow rather than memorizing isolated facts:

• Files, semi-structured data, or Spark/notebook transforms? Use a lakehouse. It stores raw and curated Delta tables and exposes a read-only SQL endpoint for analysts.
• Analysts who write T-SQL and need transactional INSERT/UPDATE/DELETE? Use a warehouse. It is the only Fabric SQL store with full write support and multi-statement transactions.
• High-velocity event, log, or IoT telemetry needing sub-second time-series queries? Use an eventhouse / KQL database and query with KQL.
• A governed layer for Power BI report consumption? Build a semantic model and query with DAX, ideally in Direct Lake mode over OneLake tables.

Every one of these stores writes to OneLake in open Delta/Parquet, so the same physical data can be reached by multiple engines without copying — a recurring theme in scenario questions.

Why Architecture Knowledge Earns Marks

A large share of DP-600 questions are phrased as "a team needs X without doing Y — which item or capability?" The right answer almost always hinges on three platform truths covered above: (1) data lives once in OneLake and is virtualized elsewhere via shortcuts; (2) the workspace is the unit of security, capacity, and dev/test/prod lifecycle; and (3) the capacity SKU is shared by every engine, so sizing is a cross-workload and a cost decision.

When a scenario mentions duplicating data, think shortcut; when it mentions promoting or securing content, think workspace; when it mentions performance or licensing trade-offs, think capacity. Anchoring each question to one of these three concepts turns vague scenarios into fast, defensible answers and prevents the classic mistake of reaching for a deployment pipeline or a semantic model when a simpler, in-place capability is the intended solution.