Consolidating a Shared Fabric Capacity Across Six Domains
Northwind Health runs Microsoft Fabric on a single F64 capacity. All six analytics domains share one workspace named CorpAnalytics with 38 Contributors and 12 Viewers. It contains 15 pipelines, 120 semantic models, and 40 notebooks. During month-end close, users repeatedly see capacity-exceeded messages between 08:00 and 11:00, and finance reports time out. Deployment is manual: developers edit production items directly. Audit requires development, test, and production separation plus least privilege. The platform team has no budget for another capacity this year, but it can change workspace design, scheduling, and deployment practices. Four deployment pipelines are available in the tenant.
1. Design the workspace and capacity topology. Explain why the current single workspace is inadequate and what you would change first.
Read the worked answer
The single workspace conflates isolation, ownership, and deployment stage. Separate by domain and by environment: for each of the six domains, create Domain_Dev, Domain_Test, and Domain_Prod workspaces, then group production workspaces into a Fabric domain for discovery. Assign only the production workspaces to the F64 capacity that serves business users; keep development and test workspaces on the same capacity only if the tenant cannot fund a second one, and enforce lower-priority usage through scheduling and workspace roles rather than open Contributor access.
The first changes are: (1) remove direct production editing by granting Contributors access only to Dev/Test; (2) connect each production workspace to a deployment pipeline; (3) publish production semantic models through Power BI apps so Viewers do not need workspace access; (4) use shared semantic models instead of 120 independent copies. This gives least privilege and an auditable promotion path without buying capacity.
2. The month-end spikes cannot be solved by adding capacity. What concrete actions would you take, and how would you prove they worked?
Read the worked answer
Start with evidence, not guesswork: open the Fabric Capacity Metrics app, identify the top CU-consuming items during 08:00-11:00, and separate interactive versus background usage. Likely fixes are:
- Stagger refresh schedules across domains and move large refreshes outside the close window.
- Reduce refresh parallelism and disable unnecessary mid-day refreshes.
- Convert suitable large Import models to Direct Lake where the Delta tables are well-formed, eliminating refresh CU.
- Remove unused columns, high-cardinality calculated columns, and redundant measures from the busiest models.
- Pause noncritical notebooks and dataflows during the close window.
- Put development/test workloads on a schedule that avoids production peak.
Prove the result by comparing throttling events, rejected interactive requests, and peak CU percentage in the Capacity Metrics app for the next close cycle. If residual spikes still threaten finance, a temporary scale-up is a budget decision, not a design fix, so document it as a last resort rather than silently relying on it.
3. How should the team promote changes from development to production with the four deployment pipelines?
Read the worked answer
Use Git integration for source control and deployment pipelines for promotion. Developers work in Domain_Dev, commit to a branch, and use a build validation step before deployment. The deployment pipeline promotes the same item definitions from Dev to Test to Prod, so parameters and data source rules must be externalized using variable libraries or deployment rules; otherwise the pipeline will point Test and Prod at development data.
Promotion gates should include: semantic model validation against Test data, refresh success, RLS testing with a regional test account, and a named approver for Prod. Production items should not be edited directly; hotfixes follow the same path. This satisfies the audit requirement for separation of duties and least privilege while keeping the four pipelines manageable.