Microsoft Fabric

OneLake, capacity smoothing and throttling, Lakehouse vs Warehouse, Direct Lake, security, CI/CD and Fabric vs Databricks trade-offs.

Same series as Parts 1-7. Structure: theory primer, then Q&A in three tiers (core, "subtleties", design/scenario), then a gotchas table and a list of volatile details to re-check before the interview.

Important caveat: Fabric changes monthly. Items marked [verify] were in preview, changed recently, or vary by SKU/region. Check them against the current docs before you state them as fact. Interviewers respect "this was preview when I last checked, I'd confirm the current status" far more than a confidently outdated claim.

THEORY PRIMER

What Fabric actually is

Fabric is a SaaS analytics platform. Everything sits on one tenant-wide lake (OneLake) and runs on one shared pool of compute (Capacity, measured in Capacity Units, CU). The workloads are:

• Data Engineering (Spark, Lakehouse)
• Data Factory (pipelines, Dataflows Gen2, Copy job, Mirroring)
• Data Warehouse (T-SQL)
• Real-Time Intelligence (Eventhouse/KQL, Eventstream, Activator)
• Data Science
• Power BI
• SQL database (an OLTP SQL engine inside Fabric)

The two ideas that explain most of the design and most of the surprises:

1. One storage format. Every engine reads and writes Delta/Parquet in OneLake, so data isn't copied between engines.
2. One capacity for everything. Spark, warehouse queries, pipelines and Power BI all burn the same CU pool. Most Fabric production incidents are capacity incidents, not code bugs.

Object model

Tenant
 └─ Capacity (F-SKU, CU pool, region)
     └─ Workspace (security + deployment + Git boundary; assigned to ONE capacity)
         └─ Items: Lakehouse, Warehouse, Notebook, Pipeline, Dataflow Gen2,
                   Semantic model, Eventhouse, Eventstream, Environment, ...

Workspace = container in OneLake. Item = folder inside it. The physical path is:

abfss://<workspace>@onelake.dfs.fabric.microsoft.com/<item>.<ItemType>/Tables/<table>

OneLake

• One logical lake per tenant, ADLS Gen2 API compatible (DFS endpoint), so existing tools (Databricks, Storage Explorer, azcopy-style tooling) can talk to it.
• Entra ID only. There are no storage account keys.
• Shortcuts: pointers to other locations (other OneLake items, ADLS Gen2, S3, GCS, Dataverse, S3-compatible and others) that appear as native folders and involve no data copy.
• Delta is the native format. Table format virtualization exposes Delta tables as Iceberg metadata (and vice versa) so Iceberg-oriented engines can read them [verify].

Capacity, smoothing, throttling (the concept interviewers probe hardest)

• You buy an F SKU (F2 to F2048). F64 = 64 CU.
• Usage is smoothed, not billed per instantaneous spike:
  • Interactive operations (queries, notebook interactive runs, report renders) smooth over roughly 5 to 64 minutes.
  • Background operations (scheduled refreshes, pipelines, scheduled Spark) smooth over 24 hours.
• Fabric lets you burst above your SKU size and pays it back later out of future smoothed capacity (carry-forward or "burndown").
• When future capacity is over-consumed, throttling kicks in by stages:

• Diagnosis tool: the Fabric Capacity Metrics app (CU seconds by item and operation, throttling and overage charts).

Engines and how they relate

        Spark (Lakehouse)         T-SQL (Warehouse)        KQL (Eventhouse)
              │  writes Delta          │  writes Delta            │ can expose Delta
              ▼                        ▼                          ▼
        ─────────────────────── OneLake (Delta/Parquet) ───────────────────────
              ▲                        ▲
     SQL analytics endpoint      Direct Lake semantic model
     (read-only T-SQL over       (VertiPaq loads Parquet columns
      Lakehouse Delta tables)     directly, no import copy)

Lakehouse vs Warehouse (one-paragraph version)

V-Order

A write-time Parquet optimization (special sorting, row-group layout, dictionary encoding) that makes reads faster and files smaller, especially for Power BI Direct Lake and the SQL engines. It costs some write time. It is still ordinary, spec-compliant Parquet, so any engine can read it.

Q&A TIER 1: CORE

1. OneLake and shortcuts

Q: What is OneLake and why does it matter architecturally?

A: It is a single, tenant-wide, ADLS-Gen2-compatible logical lake with Delta as the native format. The consequence is that Spark, T-SQL, KQL and Power BI operate on the same physical files, so you don't build copy pipelines between "the lake" and "the warehouse". Data movement becomes a governance and modelling question, not a plumbing one. I'd still say plainly that "one copy" is an ideal, not a guarantee: you can still end up with duplicated data if teams ignore shortcuts and re-ingest.

Q: What are shortcuts and what are their limits?

A: Pointers that appear as folders inside a Lakehouse (or KQL database) with no copy. Key behaviours:

• In a Lakehouse, a shortcut only becomes a queryable table if it sits at the top level of Tables/ (or directly under a schema folder in schema-enabled lakehouses) and points at a valid Delta table. A shortcut nested deeper isn't auto-discovered as a table. In Files/ it can be anywhere.
• Deleting the shortcut removes the pointer, not the target data. Deleting files or folders through the shortcut path can delete data in the target (for writable targets), which surprises people.
• For external targets (ADLS, S3, GCS) there is a network hop and possible egress cost. Shortcut caching can reduce repeated reads from S3/GCS/on-prem-style sources [verify].
• Shortcuts are read-through for most engines. Some engines and features have restrictions on writing through them.

Q: Where does a shortcut's security actually get evaluated?

A: This is a classic trap. For OneLake-to-OneLake shortcuts, access generally follows the caller's identity against the target. For shortcuts to external stores (ADLS, S3), access uses the credential stored in the shortcut's connection, meaning the creator's chosen identity or key, not the reader's own permissions on the source. So anyone who can read the shortcut can read whatever that connection can read. That is effectively delegated access and needs governance review: who is allowed to create external shortcuts, and with which connections.

2. Capacity

Q: Explain smoothing and throttling. Why did my pipeline fail even though CPU looks fine?

A: Fabric measures consumption in CU-seconds and smooths it over time. Background jobs are spread over 24 hours, interactive over a short window. You can burst well over the SKU size and pay it back later. Problems appear when accumulated future consumption crosses the throttling thresholds (delay, then interactive rejection, then background rejection). So a job can fail or a report can stall not because it is expensive itself, but because of what the whole capacity has consumed for the past hours. The first thing I check is the Capacity Metrics app: which item and operation type dominate CU-seconds, and when overage started. Then I split workloads: heavy ETL and Power BI serving should not share a capacity in production.

Q: What happens when you pause a capacity?

A: Content becomes inaccessible (queries and reports fail) but OneLake storage remains, and you keep paying for storage. Subtle point: accumulated smoothed overage does not vanish on pause; the outstanding overage is billed at that moment [verify current billing behaviour]. Pausing right after a heavy burst is therefore not a free reset.

Q: Which SKU threshold matters for Power BI licensing?

A: F64 and above: report consumers can view without an individual Power BI Pro licence. Below F64 (F2 to F32), viewers still need Pro or PPU licences. This frequently decides the SKU purely on licensing arithmetic, independent of compute needs.

Q: Trial capacity vs paid F-SKU: what can't you do on trial?

A: Trial is roughly F64-equivalent and time-limited. Several enterprise networking and security features need a paid F-SKU: managed private endpoints and trusted workspace access to firewalled storage are the ones to name [verify current list]. Don't validate a private-networking design on a trial capacity.

3. Lakehouse and SQL analytics endpoint

Q: What is the SQL analytics endpoint and what are its limitations?

A: Every Lakehouse gets an auto-provisioned, read-only T-SQL endpoint over its Delta tables (not Files/). You can create views, functions, procedures and apply RLS/CLS/DDM through T-SQL on it, but you cannot INSERT/UPDATE/DELETE, and you cannot create tables in it. Data has to be written via Spark, pipelines or Dataflows.

Q: A Spark job wrote new data but the SQL endpoint shows the old data. Why?

A: The endpoint keeps its own metadata about the Delta tables and syncs it in the background. There can be a lag from seconds to minutes (occasionally longer for many tables or large logs). Fixes: wait, or trigger a metadata refresh (UI button or REST API "refresh SQL endpoint metadata"), and build a refresh step into pipelines that hand off from Spark to T-SQL consumers. This is a design issue in medallion pipelines where Gold is read via the endpoint right after a notebook writes it.

Q: Which Delta features can break interoperability?

A: Writer features newer than what a given reader engine supports. Examples to watch: column mapping, deletion vectors, certain protocol versions, and unusual column types or names. A table written by Spark with a newer protocol can fail to sync to the SQL endpoint or fall outside what Direct Lake supports. Be careful with ALTER TABLE ... SET TBLPROPERTIES enabling new features, and test the read path from every consumer engine before enabling one [verify support matrix].

4. Warehouse

Q: What does the Fabric Warehouse give you that the Lakehouse endpoint doesn't?

A: Full T-SQL DML and DDL, and multi-table ACID transactions (snapshot isolation). It also has zero-copy table clone, time travel via OPTION (FOR TIMESTAMP AS OF ...) (retention on the order of 30 days), automatic statistics and compaction, and cross-database queries within a workspace.

Q: Warehouse limitations and traps?

A: A short list:

• Only snapshot isolation. There is no READ COMMITTED lock-based behaviour, so write-write conflicts on the same table surface as update conflicts and need retry logic.
• Primary and foreign keys can be declared but are NOT ENFORCED. They are metadata hints. Uniqueness and referential integrity must be validated by your own DQ checks (same point as Part 6).
• T-SQL surface is a subset of SQL Server. Some constructs (certain DDL alterations, triggers, some MERGE and IDENTITY behaviour) have been missing or added recently [verify].
• The default warehouse collation is case-insensitive, whereas the Lakehouse SQL endpoint historically used a case-sensitive binary collation. Mixing them produces surprising join and filter results [verify current defaults].
• External engines cannot write into Warehouse tables, although they can read the Delta.

Q: When Lakehouse, when Warehouse?

A: Lakehouse where Spark/Python owns transformation, where you have semi-structured or file data, or where ML needs the same data. Warehouse where the team is T-SQL-first, where you need multi-table transactions or stored-procedure-based ELT, or where you migrate from Synapse dedicated pools or SQL Server. In practice mixed: Bronze/Silver in Lakehouses via Spark, Gold in a Warehouse via T-SQL, or all in Lakehouse with the SQL endpoint for serving. The choice is about skills and transactional needs, not performance.

5. Direct Lake

Q: What is Direct Lake and how is it different from Import and DirectQuery?

A: Import copies data into VertiPaq and needs scheduled refresh. DirectQuery sends SQL to a source at query time (slow but always fresh). Direct Lake loads the needed Parquet column segments from OneLake straight into VertiPaq memory on demand, with import-like speed and no copy step. A "refresh" is only framing: re-pointing the model at the latest Delta version, which is metadata-only and quick.

Q: What is Direct Lake fallback, and what triggers it?

A: In the original Direct Lake on SQL endpoint mode, if a query can't be served from Parquet, it silently falls back to DirectQuery over the SQL endpoint, which is much slower. Common triggers: the source object is a view (not a table), RLS/CLS defined at the SQL endpoint, the table exceeding capacity guardrails (row counts, file counts, row groups per SKU), or unsupported features. The newer Direct Lake on OneLake mode reads Delta from OneLake directly and does not fall back, but then security must be defined differently [verify GA status and the security model]. Practical rules: model against tables, not views; define RLS in the semantic model (or OneLake security), not on the endpoint; monitor for fallback using DAX Studio / Performance Analyzer / DMVs.

Q: How do you make a table Direct Lake friendly?

A: Avoid the small-file problem (OPTIMIZE), keep a healthy row-group size, use V-Order on Gold tables (readHeavyForPBI profile), and keep tables within SKU guardrails. Memory matters too: columns are loaded on first use and evicted under pressure, so the first query after a framing or cold start is slower (a "cold cache" effect that people mistake for a bug).

6. Spark in Fabric

Q: Starter pools vs custom pools?

A: Starter pools are pre-warmed and give session start in seconds. Custom pools let you choose node size, autoscale and the executor range, but start slower. Subtle: features like managed private endpoints / managed VNet make starter pools unavailable, so you get multi-minute cold starts. A private-networking requirement has a direct startup-latency cost.

Q: How is Spark capacity accounted?

A: 1 CU = 2 Spark VCores, and Spark can burst (about 3x the base VCores per capacity). Interactive requests beyond available cores fail with a "too many requests for capacity" style error (HTTP 430), while batch and scheduled jobs are queued (FIFO) up to a limit. So a notebook run interactively can fail on a busy capacity while the same notebook scheduled through a pipeline queues and waits. Idle sessions also burn CU until they time out, so stop sessions rather than leaving notebooks open.

Q: What is high concurrency mode?

A: Multiple notebooks share a single Spark session (and therefore cores), which cuts startup time and cost. Sharing is only allowed when the same user, the same default lakehouse, the same Spark configuration and the same libraries or environment apply. It's useful inside pipelines running many small notebooks. Drawback: less isolation, so one notebook's variables, temp views and memory pressure can affect another.

Q: What are Spark resource profiles?

A: Preset config bundles: writeHeavy, readHeavyForSpark, readHeavyForPBI. New workspaces default to writeHeavy with V-Order off, optimised for ingestion. If you write Gold tables for Direct Lake, switch to the read-heavy-for-PBI profile or enable V-Order on those tables specifically. Ingestion and serving tables deserve different profiles [verify current defaults].

Q: Native Execution Engine?

A: A vectorised C++ engine (Velox/Gluten-based) that accelerates supported Spark operators on Parquet/Delta without code changes. Unsupported operators fall back to the JVM engine, so speed-ups are workload-dependent. Enable it per environment or session and benchmark on a real job [verify].

7. Data Factory in Fabric

Q: How do Fabric pipelines differ from ADF? (Very likely question given an ADF background.)

A: Key differences:

• No tumbling window trigger. Use schedule triggers with explicit watermark/window parameters, or event-based triggers via Fabric events (Activator).
• No SSIS integration runtime and no self-hosted IR. On-premises access goes through the on-premises data gateway or VNet data gateway.
• No mapping data flows. The equivalents are Dataflow Gen2 (Power Query) or Spark notebooks.
• Linked services become Connections, managed centrally and shareable across items. Connection IDs need parameterizing for CI/CD.
• Copy activity targets Lakehouse tables directly (Delta) and there are no DIU knobs. Throughput optimisation is largely automatic.
• Existing ADF factories can be mounted as items in a workspace for gradual migration.

Q: Dataflow Gen2: when and when not?

A: Good for self-service or low-code transformation with Power Query and many connectors. Bad for heavy, high-volume transformation: it is comparatively CU-expensive, and performance depends on query folding. By default it stages through hidden staging Lakehouse/Warehouse items, which adds cost and complexity. Rule of thumb: for volume or tight cost control, use a Spark notebook or Copy plus T-SQL. Use Dataflows Gen2 where business users own the logic.

Q: Copy job vs pipeline Copy activity?

A: Copy job is a simpler, item-level, wizard-driven data movement with built-in incremental copy and CDC-style options, aimed at less orchestration-heavy scenarios. Pipelines remain the orchestration tool (dependencies, parameters, retry, notebooks). Use Copy job for straightforward replication and pipelines when it is part of a larger DAG [verify feature parity].

8. Mirroring

Q: What is Mirroring and what does it cost?

A: Near-real-time replication from an operational source (Azure SQL DB, Azure SQL MI, Cosmos DB, Snowflake, PostgreSQL, SQL Server, Oracle and others, plus open mirroring for custom producers) into OneLake as Delta, with no ETL to build. Cost model: the replication compute is free (does not consume your CU), and you get free mirroring storage up to a size tied to your capacity (about 1 TB per CU). Queries against the mirrored data (SQL endpoint, Spark, Direct Lake) do consume capacity. Source-specific: the mechanism differs per source (change feed for Azure SQL DB, CDC for SQL Server, etc.), and each has table/type limitations and prerequisites such as managed identity permissions [verify source list and limits].

Q: Mirroring vs building CDC yourself with ADF/Databricks (as in Part 2)?

A: Mirroring gives you a maintained, low-effort raw replica, which is effectively a managed Bronze. You lose control over the exact change semantics, history retention (SCD2 from change events), custom dedup logic and per-table replay. For a governed, auditable financial pipeline I'd still want the raw change log preserved. I'd use mirroring where the requirement is "fresh replica for analytics" and custom CDC where I need event-level history and replay.

9. Real-Time Intelligence

Q: Eventhouse vs Lakehouse for streaming data?

A: An Eventhouse (KQL database) is built for high-rate append data with sub-second to seconds query latency, time-series functions, retention and cache policies, and materialized views. A Lakehouse via Spark Structured Streaming is better when the data needs to flow into the medallion/Delta world and be joined with batch data. Eventhouse data can be made available in OneLake as Delta ("OneLake availability") so the two worlds meet.

Q: What are the key knobs in Eventhouse?

A: The hot cache policy (data in local SSD, fast) and retention policy (when data is dropped). Cold data (outside the cache) is still queryable but slower. Also update policies (ingest-time transformation) and materialized views (pre-aggregation). Subtle: an Eventhouse can keep consuming CU while "on" (there's a minimum-capacity setting to control always-on cost) [verify].

Q: Eventstream and Activator roles?

A: Eventstream is the no-code ingestion and routing layer (sources: Event Hubs, Kafka, CDC, custom endpoints; destinations: Eventhouse, Lakehouse, Activator, derived streams). Activator is rule-based alerting and action ("when this condition holds, notify or call a flow").

Q&A TIER 2: SUBTLETIES (what separates hands-on from documentation-reading)

10. Security model

Q: Explain workspace roles vs item permissions vs OneLake security.

A: Three layers:

1. Workspace roles (Admin, Member, Contributor, Viewer): coarse. Admin/Member/Contributor can write to items and reach the data widely.
2. Item permissions (Read, ReadData, ReadAll, Write, Share, ...): fine-grained per item. ReadAll allows direct OneLake and Spark reads of the underlying files; ReadData allows reads through SQL.
3. Data-level security: T-SQL RLS/CLS/DDM on Warehouse and SQL endpoint, plus OneLake security (folder/table/row/column-level roles enforced at storage level) [verify GA and coverage].

The trap: RLS/CLS defined in T-SQL does not protect the underlying files. Someone with ReadAll (or a contributor role) can read the Parquet in OneLake directly through Spark and bypass the SQL-layer rules. Additionally, Admin/Member/Contributor roles effectively bypass warehouse RLS/CLS. RLS applies to Viewer and to users who only have item-level or explicit SQL grants. So for real isolation you must (a) not hand out write-capable workspace roles to consumers, (b) not grant ReadAll where SQL-only access is intended, and (c) prefer storage-level enforcement (OneLake security) for sensitive data.

Q: How would you secure sensitive tax data in Fabric? (Compare with Part 3.)

A: Same layers as Part 3, expressed in Fabric terms:

• Entra ID groups mapped to workspace and item roles (least privilege; consumers as Viewer or item-level read only).
• Separate workspaces (ideally separate capacities) per environment and sensitivity zone.
• OneLake security or T-SQL RLS/CLS/DDM for row and column restrictions, with awareness of the bypass paths above.
• Sensitivity labels (Purview) that propagate to derived items and exports, and DLP policies.
• Workspace identity for authenticating to firewalled ADLS via trusted workspace access, with no keys or SAS in notebooks. Secrets in Key Vault.
• Private links (tenant-level or workspace-level) and managed private endpoints for Spark, plus outbound access protection to control egress [verify availability].
• Customer-managed keys where regulation demands key control [verify scope].
• Audit via the Purview audit log and Fabric activity logs, exported to Log Analytics or a SIEM.

Q: What is workspace identity and why use it?

A: A managed identity (an Entra service principal) tied to a workspace. It authenticates to external resources without user credentials or keys: notably firewalled storage accounts via trusted workspace access (resource-instance rules on the storage account), and connections in pipelines/shortcuts. It removes personal-credential dependencies, which matters because pipelines and shortcuts otherwise often run as an individual user.

Q: Pipelines run under whose identity?

A: Scheduled pipeline and notebook runs typically execute as the user who owns or last modified the schedule/item (not a neutral service identity), unless service principal execution is supported for that activity. So when that person leaves or their access changes, jobs start failing. Mitigations: run production items as service principals or workspace identity where supported, and periodically audit item owners [verify current service-principal support per item type].

11. CI/CD and deployment

Q: How do you do CI/CD in Fabric?

A: Two mechanisms plus tooling:

• Git integration (Azure DevOps or GitHub): each workspace is bound to one branch and one folder. Items are serialised to definition files. Commit/update flows are manual in the UI or automated through APIs.
• Deployment pipelines (Dev, Test, Prod stages) promote content between workspaces, with deployment rules (data source, parameter) to re-point items per stage. Variable libraries provide environment-specific values in a more code-first way [verify GA].
• Code-first automation: the fabric-cicd Python library and the Fabric REST APIs let you deploy from Azure DevOps or GitHub Actions with a service principal, which is the closest analogue of the Databricks Asset Bundles flow from Part 1.

Q: What are the CI/CD gotchas?

A: Several:

• Not every item type is supported by Git integration, and support level differs per item [verify].
• Git tracks item definitions, not data. A deployed Lakehouse arrives empty. Tables and data must be recreated or reloaded, and shortcuts need re-pointing.
• Notebook default-lakehouse binding is workspace-specific: after promotion, a notebook can still point to the Dev lakehouse unless you rebind it (deployment rules or parameterisation).
• Connection IDs in pipelines are environment-specific and must be parameterised.
• Warehouses are typically version-controlled as SQL database projects (dacpac-style) rather than plain Git item definitions [verify].
• Workspace-to-branch coupling means feature-branch workflows need a workspace per developer branch.

12. OneLake and ADLS Gen2 differences

Q: What differs between OneLake and a plain ADLS Gen2 account?

A: Several things:

• Identity is Entra only, with no account keys. SAS-style access has been limited to user delegation tokens [verify].
• Namespace: workspace / item.type / Tables|Files. Workspaces are the containers, so you can't lay out an arbitrary folder tree at the root.
• Not all ADLS/Blob features exist (some ACL and storage-management features, lifecycle policies, certain APIs). Structure and lifecycle are governed through Fabric, not storage-account tooling.
• Spaces or special characters in workspace/item names can break abfss:// paths in some tools. Use GUID-based paths for programmatic access.
• Region: data lives in the capacity's region (multi-geo capacities available). Cross-region reads through shortcuts can add latency and egress cost.

Q: Can Databricks work with OneLake?

A: Yes, in both directions. Databricks can read and write OneLake through the ADLS-compatible endpoint (Entra auth via service principal or passthrough). In the other direction, Fabric can create shortcuts to ADLS locations where Databricks writes Delta, and you can mirror Azure Databricks Unity Catalog into Fabric (creating shortcuts to UC tables) [verify]. The interop story is real, but be honest about limits: Delta feature and protocol compatibility, plus governance split across two catalogs.

13. Delta and table maintenance specifics

Q: How do you maintain Delta tables in Fabric?

A: Same concepts as Part 2, with Fabric wrappers: OPTIMIZE (with optional V-Order), VACUUM (default 7-day retention; shortening it breaks time travel and can break concurrent readers, including Direct Lake framing on an older version), and Lakehouse "table maintenance" from the UI/API for scheduling. Optimize write and auto-compaction settings depend on the resource profile. Warehouse tables are compacted automatically by the engine.

Q: Why is Z-Order less prominent in Fabric?

A: V-Order and file sizing matter more for the Power BI/Direct Lake path. Z-Order (and liquid clustering, [verify support]) still applies for Spark point lookups and merge keys, as in Databricks. Different serving engines want different physical layouts, which is another reason to separate ingestion and serving tables.

Q&A TIER 3: DESIGN AND SCENARIO

14. Medallion in Fabric: workspace or lakehouse per layer?

Q: How would you lay out Bronze/Silver/Gold?

A: Two viable patterns:

• Workspace per layer (bronze-ws, silver-ws, gold-ws): clean security boundaries, separate access lists, and the option to put layers on different capacities. Cost: more workspaces and cross-workspace shortcuts to manage.
• Lakehouse per layer inside one workspace: simpler, fewer moving parts, but security is coarser because workspace roles apply to all items.

I choose by the security requirement: if Gold must be broadly readable while Bronze stays locked down, use separate workspaces. Then add environment separation (Dev/Test/Prod workspaces, ideally not sharing a capacity with Prod). Cross-layer access via shortcuts, not copies.

15. "Our Fabric workloads keep getting throttled"

Q: How do you diagnose and fix it?

A: Systematic path:

1. Capacity Metrics app: find what consumed CU-seconds (by item and operation), separating interactive from background, and when overage began.
2. Identify the offenders: typically a huge Dataflow Gen2, an unbounded Spark job, a Direct Lake fallback storm, or many concurrent report refreshes.
3. Fix at the source: rewrite expensive Dataflows as Spark/SQL, right-size Spark pools, stagger schedules to flatten peaks (smoothing helps but doesn't create capacity), fix Direct Lake fallback, add OPTIMIZE.
4. Isolate: move ETL and BI to separate capacities so a batch spike can't reject interactive report queries.
5. Then scale: bigger SKU, reserved capacity, or autoscale-style billing for Spark [verify availability].

16. Migrating Synapse/ADF to Fabric

Q: How would you approach migrating an Azure Synapse + ADF estate?

A: Map component by component:

• Synapse Spark to Fabric Spark: mostly portable (notebooks), but re-check libraries, runtime versions and mount/credential patterns.
• Dedicated SQL pool to Fabric Warehouse: not lift-and-shift. T-SQL surface differences, no distribution/index hints, different tuning model. Plan a schema and code conversion.
• Serverless SQL to Lakehouse SQL endpoint: closer.
• ADF pipelines: mount existing factories for coexistence, then rebuild gradually. Watch the gaps: no tumbling window, no SSIS IR, no mapping data flows, self-hosted IR replaced by gateways.
• Power BI datasets to Direct Lake where it makes sense.

Do it as a strangler-pattern migration, running old and new in parallel with the reconciliation framework from Part 6 to prove equivalence table by table.

17. Fabric vs Databricks (a very likely question for this role)

Q: How do you choose between Fabric and Databricks?

A: Honest, balanced answer:

Common real pattern: Databricks for heavy engineering and ML, Fabric for the BI/semantic serving layer, connected through OneLake shortcuts or mirroring. The decision is rarely purely technical. It also depends on team skills, licensing (F64 and Power BI) and governance requirements.

18. Ingest a fast-changing SQL Server table, end to end

Q: Design it in Fabric.

A: Two options depending on requirements. (1) Mirroring for a managed near-real-time replica, then Silver/Gold via Spark or T-SQL on top, with reconciliation checks against the source. (2) Custom CDC (Copy job, pipeline or Eventstream landing change events in Bronze), then a deduplicating idempotent MERGE into Silver as in Part 2, when I need event history, replay, or precise delete semantics. Either way: DQ gate before Silver, control totals at each stage (Part 6), a SQL endpoint metadata refresh step before T-SQL consumers read, and a service principal or workspace identity for the pipeline.

19. What would you not use Fabric for?

Q: Where does Fabric fall short?

A: Be candid, since this signals real experience:

• Workloads needing fine-grained Spark tuning, custom cluster configuration or Photon-like performance work.
• Very strict per-job cost attribution: shared capacity smoothing makes chargeback harder.
• Highly regulated setups whose required networking or key-management features are not yet available [verify].
• Environments needing mature multi-catalog governance and lineage on day one.
• Rapidly changing features: preview-to-GA churn adds change-management overhead for production platforms.

GOTCHAS TABLE (fast review)

VOLATILE DETAILS: RE-CHECK BEFORE THE INTERVIEW

1. Direct Lake on OneLake: GA status, security model, fallback behaviour.
2. OneLake security (row/column/table level): GA status and which engines enforce it.
3. Warehouse T-SQL surface: MERGE, IDENTITY, ALTER TABLE support, current default collation.
4. Service-principal execution support per item type (pipelines, notebooks, Dataflows Gen2).
5. Networking: workspace-level private link, outbound access protection, feature list on trial vs paid SKUs.
6. Mirroring: supported source list and per-source limitations.
7. Spark: current runtime versions, Native Execution Engine status, autoscale billing for Spark.
8. Variable libraries and fabric-cicd maturity; Git-supported item types.
9. Materialized lake views (declarative Silver/Gold with data-quality constraints) and their status.
10. Table format virtualization (Delta/Iceberg) coverage.

Tip if you come from ADF/Synapse/Databricks: that background (and a Fabric certification, if you hold one) gives you a natural framing: answer Fabric questions by comparison ("in ADF it was X, in Fabric it's Y, and the gotcha is Z"). It demonstrates hands-on migration thinking, not memorised docs.