In this post we are going to cover real-world manager scenarios in Microsoft Fabric: a throttled capacity, a Synapse migration, Databricks next to Fabric, a bill that is too high, wrong totals, an inherited tenant and a full platform design. 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 the hiring manager asks you to design a Fabric lakehouse platform for a retail company from scratch.
This is the last part of the series, and it is different from the others. There is no single feature to explain. The manager wants to hear your order of steps: what you do first, what you check, and what you tell the business. Interviewers ask these in the final round because they show whether you have actually run Fabric in a real company.
Part 10 of the Real Time Microsoft Fabric Interview Questions and Answers series on TechBrothersIT.
- The short answer
- Question 1: The capacity is throttled at 9 AM every Monday and the CFO's dashboard won't load. Walk me through your response.
- Question 2: Leadership asks whether to move from Azure Synapse to Fabric. How do you assess it, and what is your migration plan?
- Question 3: Your company has both Databricks and Fabric. How do you decide which workload goes where, and how do they share data?
- Question 4: The Fabric bill is higher than planned. How do you find out why and bring it down?
- Question 5: A pipeline succeeded but the report shows wrong totals. How do you trace the problem from report back to source?
- Question 6: You inherit a Fabric tenant with two hundred workspaces and no standards. What do you put in place first?
- Scenario 7: In the final round, the hiring manager asks you to design a Fabric lakehouse platform for a retail company from scratch. What is your design?
The short answer
In an incident, communicate first, then read the Capacity Metrics app and know the throttling stages. Migrate from Synapse in phases, share data with Databricks without copies, and cut cost meter by meter. Trace wrong numbers layer by layer, put standards in place before cleaning up, and design platforms that are governed and safe to rerun.
Keep that in mind. Every question below is one piece of it.
Question 1: The capacity is throttled at 9 AM every Monday and the CFO's dashboard won't load. Walk me through your response.
Communicate first, then read the Capacity Metrics app. The CFO's team should hear from you before they start guessing.
So first, tell them what is happening and when the next update comes. Then open the Capacity Metrics app. Its data lags 10 to 15 minutes, so drill into the Monday morning timepoints and find the items that used the capacity.
Then know the stages. Background jobs are smoothed over 24 hours, and throttling depends on how much future capacity is already used:
| Future use already consumed | Effect |
|---|---|
| UP TO 10 MINUTES | no throttling |
| 10 TO 60 MINUTES | new interactive jobs delayed 20 s |
| 60 MINUTES TO 24 HOURS | new interactive jobs rejected |
| OVER 24 HOURS | all new requests rejected |
Past 60 minutes, new interactive jobs are rejected, and that is the dashboard failing. Jobs already running are never throttled.
Now, step by step, from recovering today to fixing it for good:
- Metrics app timepoints - find the items behind the spike.
- Pause and resume, or scale up - pause and resume bills the carried-forward usage at once and clears throttling, but content is offline while it is paused.
- Capacity overage with a limit - it lets you pay for overage instead of being throttled, up to a limit you set.
- Autoscale Billing for Spark - move the heavy Spark work, often the weekend load, off the shared capacity. Spread the jobs out and tune the top items too.
- Own capacity for the CFO - put the CFO's reports on their own capacity.
Add capacity alerts, so you know about throttling before the CFO does.
Question 2: Leadership asks whether to move from Azure Synapse to Fabric. How do you assess it, and what is your migration plan?
Assess before you promise. Inventory what you have: pipelines, Spark pools and notebooks, dedicated SQL pools, and Synapse Link. For each one, check what maps cleanly and what needs rework, and size a Fabric capacity against today's workload.
Let's look at how each piece maps:
| In Synapse | In Fabric | Watch for |
|---|---|---|
| PIPELINES | Fabric pipelines | upgrade module handles Synapse |
| SPARK POOLS, NOTEBOOKS | Fabric Spark | Delta is the default format |
| SYNAPSE LINK | mirroring | check the source's status |
| DATA IN ADLS GEN2 | OneLake shortcuts | nothing is copied |
| DEDICATED SQL POOL | Fabric warehouse | T-SQL gaps: rework |
Most of it maps. Pipelines move to Fabric pipelines, and Microsoft's pipeline upgrade PowerShell module handles Synapse pipelines too. Spark code moves to Fabric Spark, where Delta is the default format. Synapse Link becomes mirroring.
The dedicated SQL pool needs the most care. The Fabric Migration Assistant converts the schema and lists what failed. The warehouse has no materialized views, IDENTITY is bigint only with no custom seed, and types like datetimeoffset aren't supported. So test the T-SQL and rewrite what breaks.
Then the plan. It is phased, not big bang:
- Shortcut - shortcut the existing data lake into OneLake, so nothing is copied.
- Pilot - move one workload end to end.
- Parallel run - run it next to Synapse and reconcile the numbers.
- Move the rest - one by one, and switch Synapse off last.
Leadership gets a working pilot and matching numbers before anything is switched off. That is a much easier conversation than a big bang date.
Question 3: Your company has both Databricks and Fabric. How do you decide which workload goes where, and how do they share data?
Start with one rule: one copy of the data, and one engine that writes each table. Then decide by workload, team skills and what is already built, not by which tool is newer.
Here is how it usually splits:
| Usually stays in Databricks | Usually fits Fabric |
|---|---|
| heavy engineering the team already runs | Power BI serving and Direct Lake models |
| machine learning already built there | T-SQL warehouse work and self-service |
Heavy engineering and machine learning the Databricks team already runs usually stay there. Power BI serving, Direct Lake models, T-SQL warehouse work and business self-service fit Fabric, where everything shares one capacity and OneLake.
Now the sharing. Let's go from Databricks to Fabric first. Mirror the Azure Databricks Unity Catalog into Fabric. That is metadata mirroring, and it is generally available. It syncs the catalog, and Fabric reads the Delta files through shortcuts, so nothing is copied. Direct Lake can use the mirrored catalog, and OneLake security can protect it.
The other direction works too. OneLake supports the ADLS Gen2 APIs, so Databricks can read and write OneLake with ABFS paths.
Two teams copying the same tables both ways. Agree who owns each table, and share the rest.
Question 4: The Fabric bill is higher than planned. How do you find out why and bring it down?
Split the bill by meter first. You can't fix a bill until you know which meter grew.
In Azure Cost Management, split the cost by meter. The capacity is billed per second while it runs, and OneLake storage is billed separately. Capacity overage and Autoscale Billing for Spark are meters of their own, and a surprise often hides there.
Here are the meters, where to look and how to cut each one:
| Meter | Where to look | How to cut it |
|---|---|---|
| CAPACITY (F SKU) | Capacity Metrics app: top items | pause dev, reservation, right-size |
| CAPACITY OVERAGE | its own Azure meter | set the limit, fix the spike |
| SPARK AUTOSCALE BILLING | Autoscale compute for Spark page | max limit, idle sessions |
| ONELAKE STORAGE | storage page | VACUUM, cool and cold tiers |
Then find the consumers. The Capacity Metrics app shows which workspaces, items and operations used the most capacity, and its storage page shows what is growing. The Chargeback app helps you show each team its share.
Now let's bring it down, in order:
- Pause dev and test capacities outside working hours.
- Buy a yearly reservation for the steady production size.
- Fix the top items: idle Spark sessions, dataflows doing heavy work that a notebook or copy job could do, and reports on unoptimized tables.
- For storage, VACUUM big Delta tables and move old data to cool or cold tiers.
Set a sensible limit on capacity overage, so one bad job can't run up the bill unnoticed.
Question 5: A pipeline succeeded but the report shows wrong totals. How do you trace the problem from report back to source?
Succeeded only means every activity ran. It says nothing about the data. So I walk backwards one layer at a time, and compare one number, like yesterday's sales total, at each step.
The path is source, bronze, silver, gold, the semantic model, then the report. We go from the right to the left:
- Model - a changed measure, a filter, a relationship. With Direct Lake, check the model was reframed after the load, or it still shows the old version of the table.
- Gold - compare totals by day.
- Silver - if gold is wrong, check for duplicate keys. A rerun that appended instead of merging is the classic cause.
- Bronze - compare row counts with the source.
Here are the checks I run, and the rollback:
-- gold: totals by day
SELECT order_date, SUM(amount) AS total
FROM gold.fact_sales
GROUP BY order_date ORDER BY order_date;
-- silver: duplicate keys after a rerun
SELECT order_id, COUNT(*) AS copies
FROM silver.orders
GROUP BY order_id HAVING COUNT(*) > 1;
-- which load changed it? then roll back
DESCRIBE HISTORY silver.orders;
RESTORE TABLE silver.orders TO VERSION AS OF 41;The first query gives the gold totals by day. The second finds order ids that appear more than once in silver. Then Delta history shows which load changed the table, and we restore it to the version before the bad load. After that, rerun with a MERGE that is safe to repeat.
Add checks after each load, like row counts, totals against the source and a duplicate check, and fail the pipeline when a check fails.
Question 6: You inherit a Fabric tenant with two hundred workspaces and no standards. What do you put in place first?
Don't start by deleting things. Start with an inventory, then fix access, then add structure.
Here is the order, step by step:
- Inventory - list every workspace with the admin APIs or the Govern tab in the OneLake catalog. Find its owner, its capacity, and whether anything ran recently.
- Access - this is the real risk. Replace individual users in workspace roles with Entra groups, cut back the Admins, and check in the tenant settings who can create workspaces.
- Structure - group workspaces into domains by business area, like Sales, Finance and Supply chain. Domains don't change access, but they give clear ownership and make the catalog easier to search. Agree a naming standard, and separate dev, test and prod.
- Protection - default sensitivity labels per domain, certified items for trusted data, and Git plus deployment pipelines for anything in production.
- Monitor and retire - monitor with the Capacity Metrics app, and retire unused workspaces only after their owners agree.
For the dev, test and prod split, the layout looks like this:
| Workspaces | Capacity |
|---|---|
| sales_dev, sales_test | dev capacity, paused at night |
| sales_prod | prod capacity |
Prod gets its own capacity, and the dev capacity is paused at night.
Write the standards on one page people will actually read, not a long document nobody opens.
Scenario 7: In the final round, the hiring manager asks you to design a Fabric lakehouse platform for a retail company from scratch. What is your design?
Let's build it from the sources to the report, then add what goes around it.
- Sources. Store and e-commerce databases come in through mirroring where the source supports it. Other systems, like the ERP, use copy jobs or pipelines through the on-premises data gateway, and clicks stream in through Eventstream.
- Storage. A medallion in OneLake: bronze, silver and gold lakehouses, each in its own workspace.
- Transform. Notebooks on Runtime 2.0 merge into silver and build a star schema in gold, with V-Order on for reporting.
- Orchestration. One pipeline lands the data, runs the notebooks, checks the data, and alerts on failure.
- Reporting. Power BI uses a Direct Lake on OneLake model over gold. On F64 or above, users with the Viewer role don't need a Pro license.
Then everything around it:
- Security. Entra groups and OneLake security, so store managers see only their region.
- Change control. Git and a deployment pipeline, with variable libraries per stage.
- Cost. Production gets its own capacity, dev is paused at night, and Autoscale Billing for Spark takes the big loads.
Every piece is governed, every load is checked, and every step is safe to rerun. That is a platform the business can trust.
That is the end of the series. If you worked through all 10 parts, you have the answers for the questions that actually come up on Fabric projects, from capacity to this final design.
Key points to remember
- Throttling: communicate, Metrics app, recover, then fix the cause
- Synapse: inventory, shortcut the lake, pilot, migrate in phases
- Databricks: one copy, one writer; share with Unity Catalog mirroring
- Cost: split by meter, pause dev, reservation, fix top items
- Wrong totals: trace layer by layer; standards before cleanup
All 10 parts are listed on the Real Time Microsoft Fabric Interview Questions and Answers page on this blog.
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.