ExamFinch.com My Study

Study guide

2.1 Implement and manage an analytics solution Overview

Practice this exam

DP-700 Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: DP-700 Orientation and Exam Strategy

1.1 Current DP-700 Exam Facts 1.2 Eligibility, Application, and Scheduling 1.3 Blueprint Domains and Weighting 1.4 Question Style and Score Report Thinking 1.5 Study Calendar and Practice Plan

2 Chapter 2: Implement and manage an analytics solution

2.1 Implement and manage an analytics solution Overview 2.2 Core Workflows and Decision Points 2.3 Scenario Practice for Implement and manage an analytics solution 2.4 Common Traps in Implement and manage an analytics solution 2.5 Practice Drills and Readiness Markers

3 Chapter 3: Ingest and transform data

3.1 Ingest and transform data Overview 3.2 Core Workflows and Decision Points 3.3 Scenario Practice for Ingest and transform data 3.4 Common Traps in Ingest and transform data 3.5 Practice Drills and Readiness Markers

4 Chapter 4: Monitor and optimize an analytics solution

4.1 Monitor and optimize an analytics solution Overview 4.2 Core Workflows and Decision Points 4.3 Scenario Practice for Monitor and optimize an analytics solution 4.4 Common Traps in Monitor and optimize an analytics solution 4.5 Practice Drills and Readiness Markers

5 Chapter 5: Final Review and Test Day

5.1 Timed Practice Strategy 5.2 Last-Week Review Map 5.3 Exam-Day Checklist 5.4 After the Exam and Next Steps

2.1 Implement and manage an analytics solution Overview

Key Takeaways Explain This Topic AI

This domain is 30-35% of DP-700 and covers workspaces, capacities, OneLake, domains, ALM (Git + deployment pipelines), security, and orchestration.

A Fabric tenant runs on capacity SKUs measured in Capacity Units (CUs); F64 is the threshold that unlocks free-viewer consumption and full Power BI Premium parity.

OneLake is the single, tenant-wide logical data lake; every workspace maps to a OneLake folder and all items store data in Delta-Parquet by default.

Items (lakehouse, warehouse, eventhouse, pipeline, notebook) live inside workspaces, which are grouped into domains for governance.

ALM in Fabric combines Git integration (developer inner loop) with deployment pipelines (release outer loop) across Dev, Test, and Prod.

Last updated: June 2026

How Microsoft Fabric Is Organized

Microsoft Fabric is a unified, software-as-a-service (SaaS) analytics platform that runs on top of a single logical data lake called OneLake . For DP-700, you must know the object hierarchy cold, because most questions are really asking "at which level is this setting or permission applied?"

The hierarchy from top to bottom is: tenant (your Microsoft Entra organization) holds one or more capacities ; capacities power workspaces ; workspaces contain items (lakehouses, warehouses, eventhouses, KQL databases, notebooks, pipelines, semantic models, reports); and workspaces are optionally grouped into domains for federated governance.

  • Object What it is Governs
  • Tenant The Entra organization Tenant admin settings, default capacity
  • Capacity A pool of compute (an F SKU) Which workloads can run, throttling
  • Domain A logical grouping of workspaces Federated governance, delegated settings
  • Workspace A collaboration container Roles, Git binding, deployment stages
  • Item A single artifact (e.g., lakehouse) Item permissions, sharing, OneLake data

A key SaaS principle: there are no servers to patch and no clusters to size by hand. You buy a capacity , assign workspaces to it, and Fabric meters the compute the workloads consume.

Capacities and SKUs

A Fabric capacity is a reserved pool of compute measured in Capacity Units (CUs) . SKUs are named with an F prefix and the CU/second allowance: F2 = 2 CU/s, F8 = 8, F64 = 64, scaling up to F2048 . Capacities are pay-as-you-go: you can scale them up or down, and pause them when idle so you stop being billed for compute (the F SKU is pausable; legacy P SKUs are not).

F64 is the magic threshold. At F64 and above you get full Power BI Premium feature parity, and free (non-Pro) users can view content in those workspaces. Below F64 (F2-F32), viewers still need Power BI Pro licenses, and several features are gated off, including the XMLA read/write endpoint , paginated reports, and email subscriptions.

Smoothing : Fabric averages bursty CPU usage over a rolling window so short spikes do not immediately throttle you.

Throttling : when sustained demand exceeds the SKU's CU allowance, Fabric delays interactive operations, then background jobs, then rejects requests.

Autoscale : an optional safety net that adds CUs on demand. It is cost-effective for rare spikes; if it fires daily, upgrading the SKU is cheaper.

Bursting : a single job can temporarily use more CUs than the SKU allows to finish faster, repaid by smoothing.

Many exam stems hinge on "viewers report they cannot open content for free" or "this feature is unavailable" — the answer is almost always "the capacity is below F64."

OneLake, Workspaces, and Domains

OneLake is the one logical data lake provisioned automatically for the whole tenant — "OneDrive for data." There is exactly one OneLake per tenant. Every workspace becomes a top-level folder in OneLake, and every data item (lakehouse, warehouse) gets a folder beneath it. All Fabric engines write open Delta Lake / Parquet by default, so the same physical files are readable by every engine without copies. Shortcuts let you reference data in another OneLake location, ADLS Gen2, Amazon S3, or Google Cloud Storage without moving or duplicating it.

Domains are a governance construct: a domain is a named grouping of workspaces (for example, Sales, Finance, HR). A Fabric admin assigns domain admins , who can in turn add or remove workspaces and delegate certain tenant settings down to the domain. Subdomains refine the grouping. Domains drive discoverability in the OneLake catalog and let business units self-govern.

The takeaway for the exam: OneLake is a storage layer (one per tenant), workspaces are the unit of collaboration and ALM binding, and domains are a governance overlay — do not confuse a domain (governance) with a capacity (compute).

Workloads, Items, and Where Compute Comes From

Fabric unifies several workloads under one capacity: Data Engineering (lakehouse, Spark notebooks), Data Warehouse (T-SQL warehouse), Data Factory (pipelines, dataflows), Real-Time Intelligence (eventstreams, eventhouse, KQL), Data Science (ML models), and Power BI (semantic models, reports). Every workload draws compute from the same capacity, so a heavy Spark job and a Power BI refresh compete for the same CU pool. That shared-pool design is why capacity sizing and smoothing matter: a single under-sized F SKU can throttle unrelated teams sharing it.

Each workload produces items . A lakehouse stores files and Delta tables and auto-generates a read-only SQL analytics endpoint plus a default semantic model . A warehouse is a fully transactional T-SQL store. An eventhouse/KQL database handles high-volume telemetry. A pipeline orchestrates; a notebook transforms; a dataflow Gen2 does low-code shaping. Knowing which item produces which capability lets you answer "which item should I create?" questions quickly.

Trial and licensing context

DP-700 also expects light awareness of licensing. A Fabric (Free) license lets a user create items only in a My workspace or a trial. A Power BI Pro or Premium Per User (PPU) license is required to share content when the capacity is below F64. At F64+ , content can be shared to free users. The Fabric capacity (the F SKU) is what actually powers non-Power-BI Fabric workloads; without a capacity assigned to a workspace, those Data Engineering and Warehouse items cannot run.

Keep these three things distinct: the per-user license (who can author/share), the capacity (what compute runs the workloads), and the workspace (where items live).