2.1.2. Workspaces, Domains, and Capacity

💡 First Principle: Think of Fabric's hierarchy like a corporate office building: capacity is the building itself (power, space, utilities), workspaces are individual offices where teams do their work, and domains are floors that group related departments. Without proper organization, you'd have Finance analysts accidentally accessing HR's sensitive data, or development tests consuming production compute resources.

Consider a large enterprise with Finance, Marketing, and Operations departments. Each needs isolated workspaces for their data projects, but executives need cross-departmental reporting. Without domains and workspaces, you'd either over-share (security risk) or over-isolate (collaboration nightmare).

Capacity

• Concept: The compute and storage engine behind Fabric workloads—like the building's power supply
• SKUs: F2, F4, F8... F2048 (scaling compute units)
• Key Settings:
  • Burst handling for peak loads
  • Autoscale Billing for Spark (optional pay-as-you-go Spark compute outside the capacity's CUs)
  • Region selection
• Assignment: a workspace must be assigned to a capacity (a Fabric F SKU, or trial / Premium P) before its Fabric items—lakehouses, notebooks, Direct Lake semantic models—can run; a Pro or shared-capacity workspace can't host them. F SKUs can be resized or paused in Azure, for example scaled up before a daytime peak and down or paused overnight

Workspaces

• Concept: Containers for Fabric items (lakehouses, pipelines, reports)—like individual offices
• Purpose:
  • Security boundary (who can access what)
  • Organization unit (group related items)
  • Development lifecycle (dev/test/prod workspaces)
• Roles: Admin, Member, Contributor, Viewer
• Not a folder: a workspace is a security boundary (roles), a capacity and billing boundary (it is assigned to one capacity) and a lifecycle unit (Git, deployment pipelines); folders inside a workspace only organize items
• Workspace identity: an optional, automatically managed service principal that a workspace admin creates for the workspace; Fabric items use it to authenticate to Microsoft Entra–protected Azure resources (for example a firewall-enabled storage account through trusted workspace access) without stored credentials
• Where settings live: capacity (SKU size, pause/resume—on the capacity in Azure; applies to every workspace on it), workspace (roles, Spark pools and environments, Git connection—in workspace settings), item (settings on one item, such as a semantic model's sensitivity label)

Domains and Subdomains

• Concept: Logical grouping of workspaces for enterprise governance—like floors in the building
• Purpose:
  • Organize workspaces by business area (Finance, Sales, HR)
  • Apply consistent governance policies
  • Enable self-service within boundaries
• Hierarchy: Domain → Subdomain → Workspace

Visual: Organizational Hierarchy

⚠️ Exam Trap: A workspace can be assigned to a domain or subdomain in two places: a workspace admin (who is a domain contributor) does it in the workspace settings, and a Fabric admin or domain admin does it from the domain or subdomain page in the admin portal (Assign workspaces). The subdomain's settings pane holds only its name and description, so "edit the subdomain settings" is never the answer.

Key Trade-Offs:

• Granular Workspaces vs. Management Overhead: Many small workspaces provide isolation but increase administrative burden
• Domain Scope vs. Flexibility: Strict domain boundaries improve governance but may complicate cross-domain collaboration