In this post we are going to cover the Microsoft Fabric platform, capacity and licensing: what Fabric is, how it is organized, what an F64 really means, and how smoothing, bursting and throttling work. These are 7 real Microsoft Fabric interview questions, asked the way they come up on a real project, and the last one is a scenario where you size and set up Fabric for a 40-person data team and 2,000 report viewers.
Fabric is one analytics product where engineering, pipelines, the warehouse, data science, real-time and Power BI all share the same storage and the same compute. Interviewers start here because every other Fabric topic depends on it. If you don't understand the capacity, you can't explain why reports slow down, why Spark jobs get throttled, or what the licenses will cost the business.
Part 1 of the Real Time Microsoft Fabric Interview Questions and Answers series on TechBrothersIT.
- The short answer
- Question 1: Your manager asks what Microsoft Fabric actually is and how it differs from Azure Synapse plus Power BI. What do you say?
- Question 2: A new team member asks how Fabric is organized. What are the tenant, capacities, workspaces, items and domains, and how do they relate?
- Question 3: Finance asks what an F64 is. What are capacity units, and what changes between F2, F32 and F64 for licensing?
- Question 4: Users say reports were fast this morning and now everything is slow or rejected. How do smoothing, bursting and throttling work?
- Question 5: A Spark-heavy team keeps throttling the shared capacity. What are your options, including Autoscale Billing for Spark and separate capacities?
- Question 6: Leadership wants to see who is using the capacity and why. How do you monitor it with the Capacity Metrics app and the Monitoring hub?
- Scenario 7: You are asked to size and set up Fabric for a 40-person data team and 2,000 report viewers. What do you propose?
The short answer
Fabric is a SaaS analytics platform: every workload shares one storage layer, OneLake, and one compute model, the capacity, sized as an F SKU in capacity units. Usage is smoothed, and the capacity is throttled when too much future capacity is used up. From F64 up, viewers with the Viewer role can read Power BI content with a free license.
Keep that in mind. Every question below is one piece of it.
Question 1: Your manager asks what Microsoft Fabric actually is and how it differs from Azure Synapse plus Power BI. What do you say?
Fabric is a software as a service analytics platform. Data engineering, Data Factory, the warehouse, data science, Real-Time Intelligence, databases and Power BI all live in one product.
Let's look at the two things everything sits on.
First, one storage layer, OneLake. There is exactly one per tenant. It is built on ADLS Gen2, and tables are stored as Delta Parquet. Spark, T-SQL, Direct Lake and KQL all read the same copy.
Then, one compute model, the capacity. That is an F SKU, sized in capacity units, and every workload draws from it.
Now compare that with Synapse. Synapse is platform as a service: you size and pay for each pool yourself, and the dedicated SQL pool and Power BI imports keep their own copies of the data.
| Synapse plus Power BI | Fabric | |
|---|---|---|
| MODEL | Azure PaaS pools you size, plus Power BI | one SaaS product, one capacity |
| STORAGE | data lake, plus SQL pool and import copies | OneLake, one per tenant |
| GOVERNANCE | set up per service | OneLake catalog plus Purview |
Governance sits on top: the OneLake catalog, plus Purview for labels and audit. One more detail that surprises people: you don't need an Azure subscription to use Fabric. You only need one to buy F capacity.
Don't call it "Synapse renamed". Say one lake, one capacity, and what that means for the team: fewer copies and fewer moving parts.
Question 2: A new team member asks how Fabric is organized. What are the tenant, capacities, workspaces, items and domains, and how do they relate?
Think of it as a tree. Let's walk down it from the top.
- Tenant. At the top is your Microsoft Entra tenant. It has exactly one OneLake, which can't be deleted or duplicated.
- Capacities. Under the tenant are capacities: pools of compute units, each in one Azure region. A tenant can have many, for example one for prod and one for dev.
- Workspaces. Each workspace is assigned to one capacity. A workspace is a container for items, and it maps to a container in OneLake.
- Items. Items are what you build: lakehouses, warehouses, notebooks, pipelines and reports. Each item is a folder in OneLake, and a workspace holds up to 1,000 items.
Two things matter here. Throttling happens per capacity, so whatever runs on one capacity can't slow down another. And domains sit across the tree. A domain groups workspaces by business area, like sales or finance, which is how you build a data mesh in Fabric.
The catch with domains: a domain doesn't change access. Access still comes from workspace roles and item permissions.
I keep production on its own capacity, and I use domains so people can find data in the OneLake catalog.
Question 3: Finance asks what an F64 is. What are capacity units, and what changes between F2, F32 and F64 for licensing?
An F64 is a Fabric capacity size, and the number is the capacity units: sixty-four. Sizes double at each step from F2, and in compute an F64 is roughly a P1.
Capacity units are the currency for all compute, and every workload draws from the same pool. For Spark, one CU equals two vCores, so an F64 gives 128 vCores, with bursting up to three times that.
| SKU | Capacity units | Spark vCores | Who can view Power BI |
|---|---|---|---|
| F2 | 2 | 4 | Pro or PPU per viewer |
| F32 | 32 | 64 | Pro or PPU per viewer |
| F64 | 64 | 128, burst to 384 | free license, Viewer role |
You buy F SKUs in Azure. They are billed per second with a one-minute minimum, or you can take a yearly reservation for a discount.
Now the licensing line, which is what finance really cares about:
- F2 to F32: everyone who views Power BI content needs Pro or Premium Per User.
- F64 and above: users with the Viewer role can view Power BI content with a free license.
Two things don't change at any size. Creating or sharing Power BI content needs Pro or PPU. And PPU isn't a capacity, so it won't run lakehouses or notebooks.
Compare the cost of an F64 with a Pro license for every viewer. That comparison usually decides the size.
Question 4: Users say reports were fast this morning and now everything is slow or rejected. How do smoothing, bursting and throttling work?
Let's take the three ideas in order.
First, bursting. Fabric doesn't stop a job just because it needs more than the capacity has. Bursting lets the job use more compute than the SKU provides, so it finishes fast. Borrow now, pay back later.
Then, smoothing. Fabric spreads that usage over future time:
- Interactive operations, like report queries, are smoothed over 5 to 64 minutes.
- Background operations, like pipelines, Spark jobs and most warehouse work, are smoothed over 24 hours.
Then, throttling. It looks at how much future capacity you have already used up:
| Future use already consumed | Stage | Effect |
|---|---|---|
| up to 10 minutes | Overage protection | no throttling |
| 10 to 60 minutes | Interactive delay | new interactive jobs wait 20 seconds |
| 60 minutes to 24 hours | Interactive rejection | new interactive jobs rejected |
| over 24 hours | Background rejection | all new requests rejected |
So this morning's heavy load borrowed from the afternoon. That is why reports got slow first, and then got rejected. One thing to remember: jobs that are already running are never throttled.
To recover, you have two options. Scale up the SKU, or pause and resume the capacity, which bills the carried-forward usage right away and clears the throttling. There is also capacity overage, which lets you pay for overage instead of being throttled, up to a limit you set.
Question 5: A Spark-heavy team keeps throttling the shared capacity. What are your options, including Autoscale Billing for Spark and separate capacities?
First, prove it is Spark. Open the Capacity Metrics app and look at which workspaces and items burn the CUs at the timepoints where throttling started. Then pick from the options.
| Option | How it helps | Note |
|---|---|---|
| Autoscale Billing for Spark | serverless, billed separately | max CU limit, no smoothing |
| Separate capacity | throttling is per capacity | another SKU to manage |
| Tune the jobs | off-peak schedule, right-sized pools | turn off job-level bursting |
Option one is Autoscale Billing for Spark, which Microsoft's docs now also call on-demand billing. It is generally available and opt-in per capacity. Spark moves to serverless compute that is billed separately, so it stops using the capacity's CUs. You set a maximum CU limit. Above that limit, interactive Spark jobs are throttled and batch jobs queue. There is no bursting, no smoothing and no fallback to the capacity, so size the limit for your peak.
Option two is a separate capacity. Move the Spark team's workspaces to their own F SKU. Throttling is per capacity, so their peaks no longer hurt the report users.
And tune the jobs. Schedule heavy jobs off-peak and right-size the pools. Admins can turn off job-level bursting, so one job can't grab every burst core.
Workspace-level surge protection, which is in preview, can cap the CU use of one workspace.
Question 6: Leadership wants to see who is using the capacity and why. How do you monitor it with the Capacity Metrics app and the Monitoring hub?
Two tools for two audiences. The Capacity Metrics app is for capacity admins: who uses the CUs, and why. The Monitoring hub is for everyone: what ran, and whether it worked.
Let's start with the Capacity Metrics app. It is a Power BI template app, and it gives you:
- Compute: 14 days, by workspace and item.
- Storage: 30 days.
- Timepoint: a 30-second drill-down, so you see what was running when you hit throttling.
- Throttling and overage: including carryforward and burndown.
Two caveats. The data lags about 10 to 15 minutes, and the app has no alerts. For alerts, use the Fabric capacity events in the Real-Time hub, and alert on those.
Then the Monitoring hub:
- Job runs: pipelines, notebooks, dataflows and refreshes.
- Your items only: users see only items they have permission for.
- Refreshed Monitor hub: in preview, it adds capacity and cost pages, and alerts.
I build a monthly view: CU use by workspace and item, top consumers, and how often we were throttled. To charge usage back to teams, there is the Chargeback app.
Scenario 7: You are asked to size and set up Fabric for a 40-person data team and 2,000 report viewers. What do you propose?
I start with the licensing line, because it drives the size. Below F64, two thousand viewers would each need Pro. On F64 or above, viewers with the Viewer role can use free licenses. So production reporting goes on an F64.
Then the forty engineers. They need Pro only if they create or share Power BI content. Building lakehouses, notebooks and pipelines works with a free Fabric license on the capacity.
Next, I separate the workloads:
- Prod capacity, F64: production reports and production loads.
- Dev and test: a smaller F SKU that we pause at night.
- Autoscale Billing for Spark: keeps Spark experiments off the shared CUs, so they don't throttle the executive dashboards.
Then the setup around it:
- Workspaces by domain and environment, like sales dev, test and prod.
- Git in dev, and deployment pipelines to promote.
- Roles to Entra groups, not to people.
- Measure first: start with a trial or pay-as-you-go, track usage in the Metrics app under real load, set capacity alerts, then buy a yearly reservation for the size we really use.
The F64 is decided by the viewers. Everything else is sized from real usage in the Metrics app.
Key points to remember
- Fabric is SaaS: one lake (OneLake), one compute model (capacity)
- Tenant, capacity, workspace, item; domains group workspaces
- F SKU number = capacity units; free viewers from F64 up
- Smoothing spreads usage; throttling starts after 10 minutes of future use
- Spark: Autoscale Billing or a separate capacity; watch the Metrics app
Part 2: OneLake, Shortcuts and Mirroring
Part of the Real Time Microsoft Fabric Interview Questions and Answers series on TechBrothersIT. Features, limits and their status (GA or preview) are current as of October 2026; check the Microsoft Learn page for anything you quote in an interview.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.