How does Fabric support multi-tenant governance and isolate customer data?

• A. Use a single workspace with broad access for all tenants.
• B. Separate workspaces, dataset-level ACLs, separate OneLake regions or containers, and strict RBAC to isolate customer data with shared infrastructure.
• C. Duplicate all data for each tenant in the same store with minimal isolation.
• D. Use generic RBAC without tenant-specific controls.

Answer: (B)

Fabric handles multi-tenant governance by establishing explicit boundaries for each tenant while sharing the same platform infrastructure. The approach uses separate workspaces for each tenant to contain their questions, metadata, and pipelines within a distinct boundary. Dataset-level ACLs tighten access so only the designated users can reach specific datasets, even inside a tenant’s workspace. Storing tenant data in separate OneLake regions or containers provides clear storage separation, preventing cross-tenant data access at the storage layer. When you combine these boundaries with strict RBAC, you enforce least privilege so that users from one tenant cannot access another tenant’s resources. This mix achieves isolation with shared infrastructure, giving robust governance and data protection. Other options fail to provide proper tenant isolation or governance boundaries: one workspace with broad access dilutes separation, duplicating data in the same store offers minimal isolation, and generic RBAC lacks tenant-specific controls.