Microsoft Fabric¶

Scope¶

Microsoft Fabric as an analytics platform and the architecture decisions it forces. Covers OneLake and the one-copy principle, tenant/capacity/workspace/domain topology, the Lakehouse item versus the Warehouse item (SQL analytics endpoint, T-SQL versus Spark write paths, which is authoritative), Power BI semantic model storage modes (Direct Lake on OneLake, Direct Lake on SQL, Import, DirectQuery) including fallback triggers and per-SKU guardrails, shortcuts versus mirroring versus physical copy, F-SKU capacity and the CU consumption model (smoothing, bursting, throttling, surge protection, pause/resume), Delta as the native table format plus Iceberg and Unity Catalog interop, Real-Time Intelligence (Eventhouse, KQL databases, Eventstream), the layered security model (workspace roles, item permissions, OneLake security roles, SQL endpoint access modes), network isolation (tenant and workspace private links, managed VNets, outbound access protection), customer-managed keys, data residency and Multi-Geo, disaster recovery, and audit/compliance evidence. For the Synapse/ADF/Event Hubs/Stream Analytics layer Fabric is superseding, see providers/azure/analytics.md. For Azure Data Explorer and its relationship to Eventhouse, see providers/azure/data-explorer.md. For cross-platform governance patterns, see general/data-governance.md.

Fabric changes faster than most Azure services and several behaviours below are documented inconsistently by Microsoft. Where the docs contradict themselves, this file says so rather than picking a side. Re-verify status claims against Microsoft Learn before making a commitment on them.

Checklist¶

Tenant, Capacity, and Workspace Topology¶

[Critical] Is the split between the tenant home region and the capacity region understood, and does it satisfy the data residency requirement? The metadata platform (workspaces, access controls, and other tenant metadata) resides in the tenant home region; the back-end capacity platform, which performs compute and stores all workspace data including OneLake, resides in the capacity region. These are not the same thing, and the home region is fixed at tenant creation.
[Critical] Is each workspace deliberately assigned to a capacity, with the understanding that a workspace belongs to exactly one capacity at a time and that the capacity determines both the region and the billing boundary? Capacity assignment is the unit of cost attribution, throttling blast radius, and data residency simultaneously — it is not just a billing knob.
[Critical] Has the cross-region workspace move restriction been designed around rather than discovered later? Only Report, Semantic model (small storage format), Dashboard, Dataflow Gen1, Paginated Report, Datamart, and Scorecard are movable between regions. Lakehouses, warehouses, notebooks, and pipelines cannot be moved and must be deleted first. Moving a workspace also cancels all running jobs, and the move is blocked entirely when workspace private link or CMK is configured.
[Recommended] Are Fabric domains and subdomains used to group workspaces by business area where federated governance is wanted? Note two limits that undercut the mental model: domain assignment does not affect item visibility or accessibility, and all users in a tenant can see all domains. The set of settings actually delegable to a domain admin is narrow — domain-level default sensitivity label and certification settings.
[Recommended] Is workspace topology designed around blast radius — separate workspaces per environment and per sensitivity tier — rather than one large shared workspace? Several Fabric controls (workspace private links, outbound access protection, CMK, OneLake security) are workspace-scoped and all-or-nothing, so a workspace containing one unsupported item type blocks the control for everything in it.
[Optional] Are workspace and item definitions managed through Git integration and deployment pipelines rather than portal clicks? Note that deployment pipelines are not compatible with workspace-level private links — a workspace assigned to a deployment pipeline cannot be configured to deny public access.

OneLake and the One-Copy Principle¶

[Critical] Is it understood that there is exactly one OneLake per tenant, automatically provisioned, that cannot be deleted or duplicated? OneLake is not a resource you create; the architecture question is how workspaces and items partition it, not whether to have one.
[Critical] Is the one-copy principle being genuinely realised, or is the design quietly reintroducing copies? Every Fabric engine (T-SQL, Spark, Analysis Services, KQL with OneLake availability enabled) reads and writes Delta Parquet in OneLake. The value only materialises if shortcuts and mirroring are used in preference to physical copies — see the shortcuts section below.
[Critical] Is OneLake's access model understood as RBAC, not POSIX ACLs, despite the ADLS Gen2 API surface? OneLake supports the same REST APIs and hierarchical namespace features as ADLS Gen2 and works with the ABFS driver, but setAccessControl is permanently blocked: x-ms-owner/x-ms-group always return $superuser, x-ms-permissions always returns ---------, and x-ms-acl returns the caller's Fabric permissions translated into POSIX form. Any design that assumes storage-account-level ACL management will not work.
[Recommended] Are the OneLake endpoint conventions understood for external tooling? The storage account name is always onelake, the container is the workspace, and the item type must appear as an extension: abfss://<workspace>@onelake.dfs.fabric.microsoft.com/<item>.lakehouse/Tables/.... OneLake only accepts tokens in the Storage audience.
[Recommended] Is OneLake storage cost modelled separately from capacity? OneLake storage is billed per GB and does not consume CUs, but OneLake transactions do consume CUs (reads, writes, iterative operations, and tier-retrieval fees for cool/cold data). Soft-deleted data is retained seven days and billed at the active rate.
[Optional] Is the OneLake storage report (Workspace settings > OneLake) used for per-item storage attribution rather than inferring it from the capacity metrics app? As of a May 2026 change, the metrics app rolls OneLake compute up to a single workspace-level entry.

Lakehouse vs Warehouse¶

[Critical] Is the Lakehouse SQL analytics endpoint understood to be read-only? It gives a T-SQL query surface over the lakehouse's Delta tables and supports CREATE VIEW, inline TVFs, procedures, schemas, functions, and security policies — but no INSERT, UPDATE, DELETE, or table DDL. To modify lakehouse data you use Spark. Designs that assume a writable SQL surface over a lakehouse are wrong.
[Critical] Is the metadata sync lag between a Spark write and SQL analytics endpoint visibility accounted for in pipeline design? Under normal conditions the lag is under a minute, ranging from seconds to minutes — but the background sync process runs only while the endpoint is active and halts after 15 minutes of inactivity. A new metadata sync (preview) reduces this to seconds but applies only to newly created endpoints and cannot be enabled on workspaces using workspace private link.
[Critical] Is the Warehouse chosen when multi-table ACID transactions or a T-SQL write path are required, and the Lakehouse chosen when Spark, unstructured files, or open-format-first design dominate? The Warehouse supports full DQL/DML/DDL, BEGIN TRAN/COMMIT/ROLLBACK, and cross-database transactions across warehouses in the same workspace including reads from a lakehouse SQL endpoint. The Lakehouse has no multi-table transaction concept.
[Critical] Is the Warehouse's locking model understood before migrating a concurrent workload? Fabric Warehouse enforces snapshot isolation on all transactions and silently ignores SET TRANSACTION ISOLATION LEVEL. Locking is table-level regardless of how many rows a query touches, so two concurrent writers to the same table conflict (errors 24556/24706) — and Microsoft documents explicitly that "even when MERGE transactions only result in append-only changes, they still create a write-write conflict." This is the single most common surprise for teams migrating from SQL Server or dedicated SQL pools.
[Critical] Has the Warehouse T-SQL surface area gap been assessed against the actual workload before committing to migration? Not supported: triggers, synonyms, recursive queries, materialized views, manually created multi-column statistics, CREATE USER, BULK LOAD, (materialized views are contradictory in Microsoft's own docs: the T-SQL surface-area page lists them as unsupported and no Fabric Warehouse materialized-views page exists, while the data-warehousing overview prose claims support — the surface-area page is newer and more specific, but confirm before relying on either) SET TRANSACTION ISOLATION LEVEL, SET ROWCOUNT, PREDICT, SELECT FOR XML, vector data types, and queries targeting system and user tables together. Table-level gaps include global ##temp tables, computed columns, indexed views, partitioned tables, sequences, and user-defined types. MERGE is supported and GA; session-scoped #temp tables are supported; IDENTITY is supported but in preview and bigint only.
[Recommended] Are the Warehouse's fixed-at-creation properties decided deliberately? Collation defaults to Latin1_General_100_BIN2_UTF8 — case-sensitive — and cannot be changed after creation. varchar(max) is capped at 16 MB in the Warehouse and is not available at all on a lakehouse SQL analytics endpoint, where the 8 KB truncation still applies and can silently change join results.
[Recommended] Is the asynchronous Delta log publishing behaviour understood for external readers of Warehouse data? Warehouse user tables are stored as Parquet, and the Delta log is published by a background process after commit, giving external engines a read-only view that lags the Warehouse's own queries. Publishing can be paused with ALTER DATABASE CURRENT SET DATA_LAKE_LOG_PUBLISHING = PAUSED, during which external readers see pre-pause state while Warehouse queries see current state.
[Optional] Is the per-workspace item ceiling accounted for at scale? A workspace supports a maximum of 150 warehouse plus SQL analytics endpoint items, and cross-region connections are not supported at all, including across workspaces or capacities in different regions.

Shortcuts, Mirroring, and Data Movement¶

[Critical] Is each data source deliberately classified as shortcut, mirror, or physical copy, rather than defaulting to a copy pipeline? This is the decision that determines whether the one-copy promise is real. Shortcuts are symbolic links with no data movement; mirroring replicates continuously into Delta in OneLake at Fabric's expense; a pipeline copy is a third copy you own and pay for twice.
[Critical] Is the shortcut identity-passthrough exception understood before relying on shortcuts for access control? When shortcuts are accessed through Power BI semantic models in Direct Lake on SQL or through T-SQL engines in Delegated identity mode, the calling user's identity is not passed to the shortcut target — the calling item owner's identity is used instead, and "any permissions configured directly at the shortcut target path for the end user are bypassed." The documented fix is Direct Lake on OneLake, or T-SQL in User identity mode.
[Critical] For Mirroring, is the free-storage entitlement understood as capacity-linked? Microsoft grants one free terabyte of mirroring storage per capacity unit purchased — an F64 gets 64 TB. Background compute used to replicate into OneLake is free and does not consume capacity; querying the mirrored data with SQL, Power BI, or Spark is charged normally. You pay standard OneLake storage rates if you exceed the free limit or when the capacity is paused, and a paused or deleted capacity stops replication entirely.
[Critical] Is mirroring latency assessed against the actual freshness requirement? Microsoft documents changes being published "as fast as every 15 seconds," which makes mirroring a genuine substitute for nightly ETL from a system-of-record reporting replica. Mirrored data lands as Delta in OneLake and is read-only in Fabric — the source system remains authoritative and all writes go there.
[Recommended] Is the mirroring source list checked for GA versus preview status against the actual source? GA: Azure SQL Database, Azure SQL Managed Instance, SQL Server, Azure Cosmos DB, Azure Database for PostgreSQL, Snowflake, Oracle, SAP, Fabric SQL database, and open mirroring. Preview: Azure Database for MySQL, Google BigQuery, Dremio catalog, SharePoint List. Azure Databricks is metadata mirroring, not data replication — only the catalog structure is mirrored and the data is reached through shortcuts.
[Recommended] For an Azure Databricks mirrored catalog, has the authorization model been reviewed against the organisation's own policy? The Databricks-side documentation states that Fabric engines authorize against Unity Catalog "using short-lived credentials tied to the identity of the user who configured the connection, not the user who is querying the actual data," that "Fabric engines do not apply Unity Catalog governance and security policies to Fabric users," and that this "can lead to potential violations of corporate information security policies." The Fabric-side documentation describes the same mechanism neutrally and omits the warning.
[Recommended] Is external shortcut caching configured deliberately where cross-cloud egress matters? Cache retention is settable from 1 to 28 days, individual files over 1 GB are never cached, and caching is supported only for Google Cloud Storage, S3, S3-compatible, and on-premises gateway shortcuts — not ADLS Gen2 or Dataverse. Note the opposing consideration: cached data persists in OneLake, so caching must be disabled if the CMK-in-external-storage pattern is being used to keep data out of OneLake.
[Recommended] Are shortcut write semantics understood per target type? S3, GCS, and Dataverse shortcuts are read-only regardless of the user's permissions; ADLS Gen2 shortcuts support writes. Deleting a file within a shortcut deletes it in the target when the delegated credential has permission — shortcuts are not a read-only abstraction by default.
[Optional] Are the shortcut scale limits designed around? 100,000 shortcuts per item, 10 shortcuts per single OneLake path, and a maximum of 5 direct shortcut-to-shortcut links.

Power BI Semantic Models: Direct Lake, Import, DirectQuery¶

[Critical] Is the Direct Lake variant chosen explicitly — Direct Lake on OneLake or Direct Lake on SQL — rather than left to whatever the tooling defaults to? They behave differently in ways that matter. Direct Lake on OneLake reads Delta tables from any Fabric source, supports composite models, runs exclusively in DirectLakeOnly mode with no DirectQuery fallback, and is Microsoft's stated recommendation for new semantic models. Direct Lake on SQL uses a single source's SQL analytics endpoint for discovery and permission checks, supports SQL-endpoint RLS/OLS/CLS, and does fall back to DirectQuery.
[Critical] Are the fallback conditions for Direct Lake on SQL known and monitored? A query stays in Direct Lake mode only when the table has no SQL row-level security, no dynamic data masking, no object-level security, is not an unmaterialized SQL view, does not exceed the per-SKU guardrails on Parquet files, row groups, or rows, and the model has been framed since the underlying Delta tables changed. Memory pressure is an additional real-world cause not in that list. Diagnose with EVALUATE TABLETRAITS() and read [DirectLakeFallbackInfo].
[Critical] Are the per-SKU Direct Lake guardrails checked against the largest table before sizing the capacity? These are hard limits, and a single table exceeding any guardrail prevents Direct Lake mode for the entire model:

SKU	Parquet files/table	Row groups/table	Rows/table	Max model size on disk	Max memory
F2–F8	1,000	1,000	300 M	10 GB	3 GB
F16	1,000	1,000	300 M	20 GB	5 GB
F32	1,000	1,000	300 M	40 GB	10 GB
F64 / P1	5,000	5,000	1,500 M	Unlimited	25 GB
F128 / P2	5,000	5,000	3,000 M	Unlimited	50 GB
F256 / P3	5,000	5,000	6,000 M	Unlimited	100 GB
F512 / P4	10,000	10,000	12,000 M	Unlimited	200 GB
F1024+	10,000	10,000	24,000 M	Unlimited	400 GB

Note the asymmetry in what happens when they are exceeded: Direct Lake on SQL falls back to DirectQuery; Direct Lake on OneLake fails the refresh and leaves the model unqueryable. - [ ] [Critical] Is DirectLakeBehavior set to DirectLakeOnly in development so silent fallback surfaces as an error, and left at Automatic in production so users keep working? Silent fallback is the standard way a Direct Lake performance regression goes unnoticed for a quarter. (DirectQueryOnly exists to measure what fallback performance would be.) - [ ] [Critical] Is V-Order enabled deliberately for tables feeding Direct Lake models? V-Order is disabled by default for all newly created workspaces (spark.sql.parquet.vorder.default defaults to false), because it costs roughly 15% on write. Microsoft's gold-layer guidance calls it required for Direct Lake and documents a 40–60% improvement in cold-cache queries; other pages describe it as a performance recommendation rather than a functional prerequisite. Treat it as strongly recommended for gold-layer tables, not for write-heavy bronze. - [ ] [Recommended] Are Delta maintenance operations reconciled with framing? A framed Direct Lake model references a specific Delta commit version, so VACUUM that removes that version causes query errors until the model is reframed. Writing with Overwrite erases the Delta log each load and defeats incremental framing entirely; OPTIMIZE invalidates in-memory column segments and forces re-transcoding, producing a short-term cold-state penalty. - [ ] [Recommended] Is Import mode still used where it is genuinely the better answer? Import remains correct when the model author lacks write access to the source and needs Power Query for data preparation, when a Fabric capacity SKU is not available (Direct Lake requires one; Import works on any licence including Fabric Free), and when the model needs calculated columns, hybrid tables, model table partitions, user-defined aggregations, incremental refresh partitions, or auto date/time — none of which Direct Lake supports. (Calculated column support is genuinely ambiguous in Microsoft's documentation as of 2026-07-26: the storage-mode comparison table says "No (coming soon)" while the considerations section on the same page says "Supported (preview)". The most recent deliberate edit set it to unsupported. Verify before designing around it.) - [ ] [Recommended] Where semantic-model RLS is used with Direct Lake, is a fixed identity cloud connection configured? Microsoft's guidance is explicit on this. Note also that semantic-model RLS is not enforced for users with Write permission on the model, which includes everyone in the Admin, Member, and Contributor workspace roles. - [ ] [Optional] Is the cold/warm behaviour understood well enough to interpret first-query latency? Direct Lake loads entire columns on demand ("transcoding") and moves through cold, semiwarm, warm, and hot states. There is no documented first-party cache-warming API — the only documented method is to run queries.

Capacity Economics: F SKUs, CUs, and Throttling¶

[Critical] Has the existing Power BI Premium estate been checked before treating Fabric as a new purchase? P SKUs support Fabric, each P-SKU v-core corresponds to 8 CUs, and the mapping is P1→F64, P2→F128, P3→F256, P4→F512, P5→F1024. Many organisations already own most of a Fabric capacity. Two qualifications matter: Fabric items are not enabled on a Power BI Premium capacity by default — "if you're using a Power BI Premium capacity, Microsoft Fabric items aren't enabled," and a Fabric admin must switch Fabric on; and Premium Per User does not provision a Fabric capacity at all, so PPU licences cannot create or run lakehouses, warehouses, or notebooks no matter how many you hold. Note also that A and EM SKUs support Power BI items only and do not support Fabric. Microsoft no longer sells new P SKUs and is retiring them at the end of each customer's current agreement term, with a documented wind-down: a 30-day free grace period, days 31–90 throttled (export and recovery still possible), and full rejection of all operations from day 91 while data is retained but inaccessible. Customers on an active Enterprise Agreement can continue and renew existing P capacity annually until the EA term ends.
[Critical] Is the F64 threshold understood as the consumption-licensing cliff? On F64 and larger, users with a Fabric Free licence and the Viewer role can view Power BI content, matching P-SKU behaviour. On F2 through F32, every viewer needs a Power BI Pro or PPU licence. Authors and editors always need Pro or PPU regardless of capacity size. For a broad-audience reporting estate this single threshold usually dominates the sizing decision.
[Critical] Is CU smoothing understood, and distinguished from the throttling evaluation windows? Fabric divides time into 30-second timepoints (2,880 in 24 hours). Interactive operations are smoothed over a minimum of five minutes and up to 64 minutes depending on consumption; background operations are smoothed over 24 hours. Smoothed usage is paid for by future capacity. (Microsoft's Azure cost-management page describes interactive smoothing as a flat 10-minute interval; the authoritative Fabric throttling page says 5–64 minutes. Trust the Fabric page — the 10-minute figure is the throttling window, and conflating the two is the most common error in third-party write-ups.)
[Critical] Are the four throttling stages and their thresholds known, so that "Fabric got slow" can be diagnosed rather than guessed at?

Future capacity consumed	Policy	Effect
≤ 10 minutes	Overage protection	No throttling; jobs may borrow freely
10–60 minutes	Interactive Delay	Interactive jobs delayed 20 seconds at submission
60 minutes – 24 hours	Interactive Rejection	Interactive jobs rejected; background jobs still run
> 24 hours	Background Rejection	All requests rejected

Exceptions worth knowing: in-flight operations are never throttled; Real-Time Intelligence skips the 20-second-delay stage entirely and begins throttling at the rejection phase; Eventstreams reduce allocated CUs rather than rejecting; and Warehouse operations are classified as background, which means DMVs cannot be queried while a capacity is throttled — exactly when you most want them. Error signatures to grep for: CapacityLimitExceeded and SQL error 24801. - [ ] [Critical] Is pause/resume understood as both a cost lever and a throttling escape hatch? Only F SKUs can be paused. Pausing sums the remaining cumulative overages and smoothed operations and adds them to the Azure bill immediately, and "pausing a capacity results in a billing event for the accumulated future capacity usage… when a capacity starts or resumes, it has zero future capacity usage." That makes pause/resume a documented self-service way to end throttling. Note that OneLake storage continues to be billed while paused, all transactions to the capacity are rejected, and mirroring stops replicating. - [ ] [Recommended] Is capacity reservation evaluated against actual utilisation? Reservations are available for one or three years, are purchased in 1 CU increments, apply hourly with no carryover of unused benefit, and cover capacity only — not storage or networking. Microsoft's Azure pricing page states savings of approximately 41% versus pay-as-you-go; no percentage appears on Microsoft Learn, so treat any specific figure as a pricing-page value rather than a documented contractual one. Pay-as-you-go bills per second with a one-minute minimum. - [ ] [Recommended] Is bursting understood as borrowing rather than free capacity? Bursting lets an operation temporarily exceed the provisioned SKU, and smoothing then spreads the cost forward. For Warehouse and SQL analytics endpoint workloads the documented burst scale factors are 1–32x on F2, 1–16x on F4, 1–12x from F8 through F2048, 1–6x on F4096, and 1–3x on F8192. A scale factor above 1 means the workload is borrowing from a future interval. - [ ] [Recommended] Is surge protection configured where a single team's batch job can starve everyone else? Capacity-level surge protection lets an admin trigger background rejection earlier than the 100% default, and workspace-level limits cap a workspace's share of the rolling 24-hour CU budget. Both are checked every five minutes, so workspace limits are soft limits and the rolling window does not reset after a block ends. - [ ] [Recommended] Is Autoscale Billing for Spark evaluated where Spark is the dominant and spikiest workload? It moves Spark onto a separately billed serverless meter (0.5 CU hour), so Spark jobs stop consuming the shared capacity — but it is opt-in per capacity, does not burst or smooth, does not fall back to Fabric capacity, and is excluded from surge protection. It removes Spark as a throttling contributor and simultaneously removes its ability to exploit idle capacity. - [ ] [Recommended] Is the Microsoft Fabric Capacity Metrics app installed, and is someone accountable for the throttling and overage tabs? Usage data appears 10–15 minutes after the activity. The app does not support alerts or notifications — real-time alerting requires Real-Time hub capacity events, and it does not work at all when tenant private link is enabled. - [ ] [Optional] Is capacity overage (preview) understood before enabling it? It bills overage at three times the pay-as-you-go rate for usage that would otherwise trigger throttling, against an admin-set rolling 24-hour CU-hour limit checked every five minutes. Microsoft recommends keeping that limit below one-third of daily CU hours. It is a preview feature.

Security and Access Control¶

Network Isolation¶

This is historically the first blocker for regulated customers and it has moved substantially. Verify current status before committing — several capabilities below changed within the last year.

Encryption, Data Residency, and Sovereignty¶

[Critical] Is it established that Microsoft-managed encryption at rest already applies to everything, so that CMK is a control-ownership requirement rather than an encryption requirement? "All Fabric data stores are encrypted at rest by using Microsoft-managed keys… Data is never persisted to permanent storage while in an unencrypted state." Inbound traffic enforces a minimum of TLS 1.2 and negotiates TLS 1.3 where possible.
[Critical] If CMK is required, is its workspace scope and partial item coverage understood? Customer-managed keys for Fabric workspaces covers Lakehouse, Warehouse, Notebook, Environment, Spark Job Definition, API for GraphQL, ML model, Experiment, Pipeline, Dataflow, Copy job, Industry solutions, SQL Database, Mirrored Database, Graph, and Eventhouse (preview). A workspace containing any unsupported item type cannot have CMK enabled, and once enabled only supported item types can be created in it. Mirrored Dataverse and Mirrored Azure Databricks Catalog are explicitly not supported in a CMK workspace. Separately, Power BI BYOK operates at capacity scope for semantic models — the two are complementary, not the same feature.
[Critical] Is the documented list of what CMK does not protect reviewed against the control objective? Not protected: lakehouse column names, table format, and table compression; all data in Spark clusters — temp disks, shuffle, spills, and RDD caches — across notebooks, lakehouses, Spark job definitions, table maintenance jobs, shortcut transforms, and materialized view refresh; job logs in the history server; libraries attached through environments or session magics; pipeline and copy-job metadata such as database, table, and schema names; ML model and experiment metadata; and Warehouse Object Explorer queries and backend cache. For a data-sovereignty control objective, the Spark exclusion is usually the material one.
[Critical] Are the CMK operational constraints built into the key management runbook? Fabric supports versionless keys only and checks the vault daily for a new version, so wait 24 hours after creating a new version before disabling the old one. Key Vault or Managed HSM must have both soft-delete and purge protection enabled; keys must be RSA or RSA-HSM at 2,048, 3,072, or 4,096 bits (4,096-bit is not supported for SQL database in Fabric). Revoking the key blocks read and write within 60 minutes. Once the tenant-level encryption setting is turned off, CMK can no longer be enabled or disabled for workspaces in that tenant. CMK is supported on all F SKUs but not on trial capacities, and during a DR failover CMK supports read-only operations only.
[Critical] Is data residency reasoned about in terms of capacity region and home region, not just "the region we picked"? When a workspace is assigned to a Fabric capacity, all workspace data including OneLake is stored and processed in the capacity region. Under Multi-Geo, compute and storage sit in the multi-geo region but specific tenant metadata always remains in the home region: push datasets; dashboard and report metadata including tile names and tile queries; service buses for gateway queries and scheduled refresh jobs; permissions; semantic model credentials; Power BI Embedded playground state; and metadata linked to the Purview Data Map. Enhanced metadata scanning caches are always stored in the home region. Certain features — screenshots and data alerts among them — process data in the home region regardless.
[Recommended] Is the 30-day residue after a cross-region move disclosed in the residency assessment? "When moving data from one region to another, the source data might remain in the region from which the data was moved for up to 30 days. During that time end users don't have access to it. The data is removed from this region and destroyed during the 30-day period."
[Recommended] Are cross-region shortcuts assessed for latency, egress, and feature breakage rather than assumed transparent? Microsoft's guidance is that "OneLake shortcuts can reference data in other regions, but cross-region reads incur latency and egress costs"; shortcut caching mitigates egress for S3, GCS, S3-compatible, and gateway targets only. OneLake Iceberg virtualization requires the shortcut target to be in the same region, and cross-region shortcuts are not supported using managed private endpoints on private-link-enabled workspaces. No per-GB cross-region transfer rate is published on Microsoft Learn, and reservations explicitly exclude networking.
[Recommended] Is the OneLake redundancy and DR posture stated accurately in the resilience design? OneLake uses zone-redundant storage where available and locally redundant storage elsewhere — LRS gives at least 11 nines of durability but no protection against a datacentre disaster; ZRS gives 12 nines across three availability zones. Geo-redundancy requires the per-capacity disaster recovery setting, which replicates to the fixed Azure paired region (you cannot choose it). Replication is asynchronous, so data not yet copied at the time of a disaster is lost, and after failover the new primary has local redundancy only. The guidance applies only where the primary region has an Azure-paired secondary and Fabric is supported there. For Warehouse specifically, Microsoft's recommendation for "cross-regional disaster recovery and fully automated business continuity" is to run two Fabric Warehouse deployments in separate regions and maintain code and data parity — not to rely on the platform setting.
[Optional] Is the sovereign-cloud position verified directly rather than inferred? Microsoft Learn is ambiguous here: the Multi-Geo article states that "sovereign clouds support Multi-Geo across regions within that cloud," while the Power BI Premium migration guidance states that "sovereign cloud customers aren't affected by this retirement because Microsoft Fabric isn't yet available in sovereign clouds." Treat sovereign-cloud availability as unresolved in public documentation as of 2026-07-26 and confirm with Microsoft before designing around it.

Governance and Audit Evidence¶

[Critical] Is Microsoft Entra Conditional Access configured against all five resources Fabric depends on, rather than Power BI alone? Microsoft's guidance is to target Power BI Service, Azure Data Explorer, Azure SQL Database, Azure Storage, and Azure Cosmos DB in one common policy, and warns that "if your policy is too restrictive — for example, if it blocks all apps except Power BI — some features, such as dataflows, might not work." An existing Power BI-only CA policy is a live gap, not a starting point.
[Critical] Is it known that Fabric does not support the continuous access evaluation (CAE) session control in Conditional Access? Where a control objective depends on near-real-time session revocation after a risk event, Fabric cannot satisfy it through CAE and the compensating control must be identified explicitly. Documented as unsupported as of 2026-07-26.
[Critical] Is the audit evidence path — and its retention — established before an examiner asks? Fabric user activity flows to the Microsoft Purview audit log (the Microsoft 365 unified audit log), searchable in the Purview portal by a user holding the Audit Logs role in Exchange Online. Default retention for Audit (Standard) is 180 days. Audit (Premium)'s default one-year policy covers Entra ID, Exchange, OneDrive, and SharePoint records — Fabric records fall under "all other activities" and default to 180 days. Retaining Fabric audit records beyond 180 days up to one year requires an E5 or Purview Suite / E5 eDiscovery and Audit licence for the user who generated the record; ten years requires the additional 10-year retention add-on. An organisation may hold up to 50 custom retention policies. If the retention requirement exceeds this, an export path to a SIEM must be designed rather than assumed.
[Recommended] Are sensitivity labels applied with their inheritance limits understood, rather than assumed to flow everywhere? Labels can be set manually on all Fabric items and downstream inheritance is on by default — but it flows Power BI → Power BI, Fabric → Fabric, and Fabric → Power BI, and not Power BI item → Fabric item. "Autogenerated items from a lakehouse or data warehouse take their sensitivity label from their parent… they don't inherit the label from items further upstream." Inheritance from data sources is supported for Power BI semantic models only. Mandatory labelling is fully supported for Power BI items only, and for lakehouses, warehouses, and pipelines "mandatory labeling logic isn't enforced" — the user can save the item without a label.
[Recommended] Is Purview DLP for Fabric scoped honestly against its documented gaps? Supported item types are semantic models, lakehouses, warehouses, KQL databases, mirrored databases, SQL databases, and Cosmos databases; policies "apply only on data in tables stored in Delta format"; advanced classifiers including exact data match, trainable, credential, and named entity classifiers return no results; and DLP evaluation consumes capacity. There are no policy templates — all policies are custom.
[Recommended] Is Purview lineage coverage checked against the actual source estate rather than assumed universal? Lineage is produced for Fabric, Power BI, Azure Data Factory, Synapse pipelines, Azure Databricks, and many database sources; it is explicitly not produced for several common sources including Amazon Redshift, Amazon RDS, MongoDB, SAP BW, SAP HANA, Salesforce, Tableau, and Dataverse, and is "limited" for Blob Storage, ADLS Gen2, Azure Files, and S3 (captured only through pipeline participation). ADF, Azure ML, and Synapse lineage connections are not supported with the platform private endpoint.
[Optional] Are compliance attestations sourced from the Service Trust Portal rather than restated from a slide? Fabric is documented as compliant with ISO 27001, 27017, 27018, and 27701 and as HIPAA compliant, with the in-scope service list in Appendix A and B of the Microsoft Azure Compliance Offerings and the audit documentation on the Service Trust Portal.
[Optional] Are CMK configuration changes tracked in the audit log? The operations are ApplyWorkspaceEncryption, DisableWorkspaceEncryption, and GetWorkspaceEncryption.

Real-Time Intelligence¶

[Critical] Is Eventhouse selected for telemetry, log, and time-series workloads rather than forcing them into a Lakehouse or Warehouse? An Eventhouse hosts KQL databases running the same engine, commands, and policy objects as Azure Data Explorer — the Kusto documentation set is literally shared, with pages marked as applying to both. See providers/azure/data-explorer.md for the engine mechanics.
[Critical] Is the Eventhouse two-tier storage model understood, since it is billed separately from capacity? OneLake Cache Storage is premium storage governed by the cache policy; OneLake Standard Storage persists all queryable data and is governed by the retention policy. Retention controls how long data is queryable at all; caching controls how much of that window sits on fast storage. Both are billed separately from Capacity Units.
[Recommended] Is OneLake availability enabled on KQL databases where the same data must serve both real-time KQL queries and Direct Lake reporting? It creates a logical Delta copy at no extra storage cost — but while enabled you cannot rename tables, alter a column type, apply row-level security, or delete/truncate/purge data, and the resulting OneLake table is read-only and cannot be optimized after creation. Write latency is up to three hours, or until files of roughly 200–256 MB accumulate, configurable from 5 minutes via TargetLatencyInMinutes.
[Recommended] Is Eventhouse capacity behaviour understood as distinct from the rest of Fabric? Eventhouse bills on UpTime (active seconds × vCores) with an intrinsic autoscale mechanism and automatic suspension when idle. The Capacity Scheduler sets a 7-day minimum-capacity schedule in 60-minute blocks with a default minimum of 2 CUs, and enabling it means you are not charged for OneLake Cache Storage. Eventhouse throttling has three levels — proactive (queries throttled, ingestion continues), reactive (both paused, no data loss), and extreme reactive, where "data might be lost after a certain period."
[Recommended] Is Eventstream used as the ingestion front door where its limits fit — 1 MB message size, 90-day retention, at-least-once delivery, and a recommended minimum of F4? Creating an eventstream automatically provisions an Event Hubs namespace, and the custom endpoint exposes Event Hub, AMQP, and Kafka protocol tabs, so existing Event Hubs SDK clients work unchanged.
[Optional] Are the Eventhouse-versus-ADX gaps known before migrating a cluster? Not supported in Eventhouse: purge, cluster-level policies, system-assigned managed identities, and firewall rules. Must be removed before migrating: follower and leader clusters, CMK, VNet-injected clusters, and private or managed private endpoints. Not migrated automatically: data connections, continuous export, and database pretty names.

Interoperability and Exit¶

[Critical] Is the lock-in question answered concretely rather than with the "open format" slogan? The honest answer has three parts. Storage format is open — data lands as Delta Parquet in OneLake, and external engines can read it. Access is not unauthenticated — reads go through OneLake's ADLS Gen2-compatible endpoints with Entra tokens in the Storage audience, not through a storage account you own. Some engine access is read-only by design — Warehouse tables publish a Delta log for external readers with all writes required to go through the Warehouse.
[Critical] Where non-Microsoft engines must read Fabric data, is the access path chosen deliberately from the documented options — ABFS with a service principal holding workspace Contributor, the OneLake Iceberg REST catalog endpoint, or the Unity-Catalog-shaped /delta endpoint? Both catalog endpoints are read-only: "operations that handle metadata write operations aren't yet supported."
[Recommended] Is Iceberg interop understood as metadata virtualization and scoped to its limits? OneLake generates virtual Delta metadata over Iceberg tables and virtual Iceberg metadata over Delta tables with no data copy. Limits that matter: Iceberg V2 only; only the most recent metadata version is converted; generation takes 5 seconds to 2 minutes, so source updates must be less frequent than once per 2 minutes or readers see an inconsistent view; the bucket[N], truncate[W], and void partition transforms cause conversion to fail; the time type is unsupported and timestamp maps to timestamp_ntz, which "isn't fully supported across Fabric workloads"; Iceberg metadata uses absolute path references, so moving the folder makes the table unreadable; and the feature is not supported for tenants or workspaces with private links enabled. (Apache XTable is not the documented mechanism — that attribution appears nowhere in Microsoft's documentation.)
[Recommended] Where both Databricks and Fabric are in play, is the integration direction chosen deliberately? The documented paths are a Mirrored Azure Databricks Catalog in Fabric (metadata only, shortcuts to the data, with the Unity Catalog authorization caveat noted above), Databricks reading and writing OneLake over ABFSS with service principal authentication and workspace Contributor rights, OneLake catalog federation from Unity Catalog (read-only, requiring recent DBR and specific Fabric tenant settings), and publishing a Unity Catalog catalog to Fabric from the Databricks side (public preview, read-only in Fabric, requiring Delta or Iceberg with UniForm).
[Optional] Is it noted that Unity Catalog external locations pointing at OneLake ABFSS URLs are neither documented as supported nor as prohibited? The documented Unity-Catalog-governed route to OneLake is catalog federation. Do not assert either way without confirming with both vendors.

Migration and Adoption Posture¶

[Critical] Is the decision framed as "where does new work start" rather than "when do we migrate"? Azure Synapse Analytics has no announced retirement or end-of-support date — its Microsoft lifecycle entry reads "In Support," and the overview, FAQ, and quickstart pages carry no deprecation notice. What Microsoft does is steer new work to Fabric through Tip banners. Treating Synapse as end-of-life is not supported by the documentation; treating it as the platform for greenfield builds is not supported by Microsoft's guidance either.
[Critical] Are the cases where Fabric is not yet the right answer identified honestly before committing? Documented gaps as of 2026-07-26: Fabric Warehouse lacks materialized views, triggers, synonyms, and recursive queries, enforces table-level locking, and fixes collation at creation; cross-region connections are not supported at all; Fabric Spark lacks GPU-accelerated pools, external Hive Metastore support, JDBC connections, and .NET for Spark, all of which Microsoft explicitly names as reasons to stay on Synapse Spark; Power BI semantic models cannot live in a workspace with workspace-level private links; Fabric has no equivalent to the serverless SQL pool's per-TB cost cap; on-premises data gateways cannot register when tenant private link is enabled; and Azure-SSIS IR in ADF remains the only GA, VNet-injectable, on-premises-capable SSIS host. Any one of these can be decisive.
[Critical] For an existing Synapse dedicated SQL pool estate, is the migration assessed with the Migration Assistant against the documented incompatibilities rather than estimated? Required conversions include money → decimal(19,4), nvarchar → varchar, tinyint → smallint, and datetimeoffset is not supported at all and must be decomposed into a separate offset column. Indexes usually are not migrated. Distribution strategy, resource classes, and workload groups have no direct Fabric equivalent — Fabric's capacity model replaces them.
[Critical] For Synapse Link for Azure Cosmos DB, is the migration to Fabric Mirroring planned? Microsoft's banner is unambiguous: "Synapse Link for Cosmos DB is no longer supported for new projects. Don't use this feature." No retirement date is published. Note that Fabric Mirroring for Cosmos DB is a different mechanism, not a rebrand — it "does not use Azure Cosmos DB's analytical store or change feed as a change data capture source" and requires continuous backup on the account. The Azure SQL variant carries softer wording ("Instead of Azure Synapse Link, use Fabric Mirroring"), and Synapse Link for Dataverse is explicitly not being retired.
[Recommended] Are the component-level retirements that have been announced tracked separately from the platform? Azure Synapse Data Explorer (Preview) was retired on 7 October 2025. The Synapse "allow trusted Microsoft services" firewall exception is documented for retirement on 1 August 2026 — third-party reports of a postponement into 2027 could not be confirmed against Microsoft Learn and should be verified directly.
[Recommended] For an existing ADF estate, is the self-hosted integration runtime replacement gap assessed before planning a move? Fabric's equivalent is the on-premises data gateway, but it does not support Private Link for control flow, does not auto-update, has no Azure Key Vault integration, and is Windows-only with no container image — all of which SHIR supports. See providers/azure/analytics.md for the full comparison.
[Optional] Is a proof of concept run before committing a semantic model to Direct Lake? Microsoft's own guidance recommends it: "produce a prototype — or proof of concept (POC) — to determine whether a Direct Lake semantic model is the right solution, and to mitigate risk."

Why This Matters¶

Fabric's capacity model is the leading source of cost and performance surprise, in the same way DBUs are for Databricks and per-TB scanning is for BigQuery. The mechanism that makes it feel fast — bursting, so that a small capacity can run a large operation — is the same mechanism that makes it fail later, because smoothing pushes the cost into future timepoints and throttling arrives minutes or hours after the job that caused it. A team that runs a heavy nightly load on an F8 will see it succeed, see nothing wrong in the moment, and find interactive reports rejected the following afternoon. The Capacity Metrics app is the only place this is visible, it lags 10–15 minutes, and it does not alert. Nobody discovers this proactively.

The F64 threshold reframes the buying decision more than any technical consideration. Below F64, every person who views a Power BI report needs a Pro or PPU licence; at F64 and above, Fabric Free plus the Viewer role suffices. For an organisation with a few authors and a few thousand readers, the licence arithmetic swamps the compute arithmetic, and the right capacity size is frequently determined by the reader count rather than the workload. Compounding this, many organisations already own P-SKU Premium capacity that supports Fabric today and are unaware they have already bought most of what they are being quoted for — while Microsoft has stopped selling new P SKUs and is retiring existing ones at the end of each customer's agreement term, on a wind-down that ends in complete inaccessibility of data at day 91.

The security model composes four layers, and the composition is not intuitive. Workspace Admin, Member, and Contributor roles carry Write to OneLake and therefore override OneLake security Read restrictions, so the natural instinct of "make them a Contributor and restrict the data" inverts the intended control. T-SQL row- and column-level security apply only through the SQL endpoint and are invisible to Spark. Warehouse SQL security does not project into OneLake at all, so a shortcut reader can see what the warehouse denies. And the SQL analytics endpoint's access mode silently decides whether OneLake roles or SQL grants are even in effect — with a mode switch that is destructive across the entire workspace. Each layer is defensible in isolation; the failure mode is assuming one layer covers an engine it does not reach.

For regulated institutions, the network and encryption story has genuinely improved and is genuinely incomplete, and the incompleteness is specific rather than general. Workspace-level private links now allow isolation without tenant-wide blast radius — but Power BI semantic models cannot exist in such a workspace, which removes the reporting layer from the isolated boundary. Outbound access protection now exists and is the right control for exfiltration — but it is incompatible with external data sharing and OneLake diagnostics, and the portal cannot configure it alongside inbound private links. CMK exists at workspace scope — but does not cover Spark cluster temp disks, shuffle, spills, or caches, which is precisely where a large processing job materialises its data. And Fabric does not support continuous access evaluation, so session revocation is not near-real-time. None of these are reasons to reject Fabric; all of them are things that must be discovered during design rather than during an examination.

The Synapse question deserves a straight answer because the market gives a confused one. Microsoft has announced no retirement date for Azure Synapse Analytics; its lifecycle record says "In Support." What Microsoft has done is stop investing in it, point every new-user path at Fabric, retire specific components (Synapse Data Explorer in October 2025), and tell customers plainly to stop using Synapse Link for Cosmos DB. The correct posture for most organisations is therefore neither "migrate immediately" nor "Synapse is fine" — it is to start new work in Fabric, keep running Synapse workloads that depend on capabilities Fabric does not yet have, and re-check that list each quarter, because it is shrinking.

Common Decisions (ADR Triggers)¶

Fabric vs Databricks vs Synapse vs Snowflake on Azure — Fabric for Microsoft-ecosystem organisations where Power BI is already central, the reader population is large, and a SaaS operating model is preferred over infrastructure control vs Databricks for heavy Spark and ML workloads, mature multi-engine governance through Unity Catalog, and cross-cloud portability vs Synapse for existing dedicated SQL pool investments and for the specific capabilities Fabric lacks (GPU Spark pools, external Hive Metastore, JDBC, per-TB cost caps) vs Snowflake for multi-cloud strategy, warehouse-first SQL workloads, and data sharing across organisational boundaries. The strongest Fabric-specific argument is usually licence arithmetic and Power BI integration, not engine capability.
Synapse → Fabric migration posture — start new work in Fabric while leaving running Synapse workloads in place (lowest risk, defensible given no announced retirement, but sustains two platforms) vs planned migration of dedicated SQL pools using the Migration Assistant (bounded scope, forces the T-SQL surface-area and datetimeoffset conversions early) vs deferral pending specific Fabric gaps closing (correct where GPU Spark, external Hive Metastore, or cross-region connectivity is load-bearing). Component-level retirements — Synapse Data Explorer, Synapse Link for Cosmos DB — should be sequenced ahead of the platform decision because they have Microsoft guidance behind them.
Lakehouse vs Warehouse as the serving layer — Lakehouse when Spark is the primary write path, data includes unstructured files, or open-format-first design matters vs Warehouse when multi-table ACID transactions, a T-SQL write path, or SQL-Server-shaped tooling is required. The decisive questions are usually the write path and whether table-level locking is acceptable under the actual concurrency.
Direct Lake on OneLake vs Direct Lake on SQL vs Import — Direct Lake on OneLake for new models (Microsoft's recommendation; composite models; no silent fallback; but guardrail breaches fail the refresh) vs Direct Lake on SQL where SQL-endpoint RLS/OLS/CLS must be honoured or graceful degradation to DirectQuery is preferred vs Import for self-service authors without source write access, for sub-F-SKU licensing, and where calculated columns, hybrid tables, or incremental refresh partitions are required.
Shortcut vs mirror vs physical copy — shortcut when the data can stay where it is and the source system's access model is acceptable (no copy, no storage cost, but delegated identity semantics and the passthrough exception apply) vs mirroring when a system of record must be queryable in Fabric at near-real-time freshness without ETL (free replication compute and 1 TB storage per CU, read-only in Fabric, capacity must stay running) vs physical copy only when transformation is genuinely required at ingest. Defaulting to copy pipelines is the standard way the one-copy benefit is lost.
Capacity sizing and purchase model — size for the reader population and the F64 licensing threshold first, then for workload vs size for workload and accept Pro licensing for readers below F64. Then: pay-as-you-go with pause/resume scheduling for bursty or non-production capacity vs reservation for steady-state (one or three years, capacity only, no carryover of unused hourly benefit) vs consolidating onto existing P-SKU Premium capacity until the agreement term ends.
Single large capacity vs multiple smaller capacities — one capacity maximises burst headroom and simplifies administration but makes every workload a noisy neighbour with a shared throttling fate vs multiple capacities isolate blast radius and attribute cost cleanly but fragment burst headroom and multiply the F64 licensing threshold problem. Surge protection and workspace-level CU limits are the middle path.
Autoscale Billing for Spark on or off — on when Spark is spiky and must not throttle interactive reporting (isolated serverless meter, predictable interactive experience) vs off when Spark is steady and benefits from exploiting idle capacity through bursting and smoothing. It cannot do both.
Tenant-level vs workspace-level private link — tenant-level when the whole estate must be off the public internet and the collateral loss (Copilot, on-premises gateways, PDF/PowerPoint export, the Capacity Metrics app, Purview Information Protection, Iceberg virtualization) is acceptable vs workspace-level when only specific workspaces hold regulated data and the reporting layer can live elsewhere, since semantic models cannot exist in a private-link workspace.
Inbound protection vs outbound access protection — these solve different problems and the choice is usually "both": private links prevent unauthorised inbound reach, outbound access protection prevents exfiltration to unapproved destinations. Configuring them together on one workspace requires the Set Network Communication Policy API rather than the portal.
CMK vs Microsoft-managed keys vs CMK-in-external-storage — Microsoft-managed keys when the requirement is encryption at rest (already satisfied) vs workspace CMK when key custody and revocation must be customer-controlled, accepting partial item coverage and the Spark cluster exclusion vs keeping data in CMK-encrypted ADLS Gen2/S3/GCS and reaching it through shortcuts when data must not rest in OneLake at all — which requires disabling shortcut caching, since cached data persists in OneLake.
Multi-Geo vs single-region — Multi-Geo when data must rest in a geography other than the tenant home region, accepting that specific tenant metadata (permissions, credentials, report metadata, Purview Data Map links) always remains in the home region and that some features process in the home region regardless vs single-region when the home region already satisfies residency, avoiding the metadata carve-out entirely.
Platform DR setting vs dual-region deployment — the per-capacity disaster recovery setting for asynchronous geo-replication of OneLake to the fixed Azure paired region (simple, some data loss on failover, local redundancy only afterward) vs Microsoft's own recommendation of two parallel Fabric deployments with maintained code and data parity, which is what the Warehouse guidance actually prescribes for automated business continuity.
SQL analytics endpoint access mode: User identity vs Delegated — User identity mode when rules must be enforced consistently across Spark and SQL through OneLake security, accepting that SQL GRANT/REVOKE on tables is ignored vs Delegated identity mode when SQL-native grants, dynamic data masking, and existing T-SQL security tooling are required, accepting that OneLake roles do not carry over and reads use the item owner's identity. Switching later is destructive at workspace scope.
Audit retention strategy — accept the 180-day unified audit log default vs extend to one year through E5 or Purview add-on licensing for the users generating the records vs export to a SIEM when the retention obligation exceeds what Purview retention policies can provide. The licensing dependency sits on the generating user, which is easy to get wrong when service principals run the pipelines.

Reference Architectures¶

What is Microsoft Fabric? -- platform overview, workloads, and the tenant/capacity/workspace model
OneLake overview -- one lake per tenant, hierarchy, and the one-copy principle
OneLake API parity with ADLS Gen2 and Blob -- supported APIs, blocked ACL operations, and header behaviour
Microsoft Fabric capacity licenses -- F SKU table, CU counts, P-SKU equivalence, and the F64 viewing threshold
Throttling in Microsoft Fabric -- smoothing windows, bursting, the four throttling stages, carryforward and burndown
Pause and resume your capacity -- billing settlement on pause and using pause to clear throttling
Surge protection -- capacity-level and workspace-level background rejection thresholds
Autoscale Billing for Spark -- serverless Spark billing outside capacity CUs
Microsoft Fabric Capacity Metrics app -- installation, pages, and what the app can and cannot show
Fabric capacity reservations -- one- and three-year terms, CU increments, and what reservations exclude
Power BI Premium P SKU migration decision guide -- P-to-F mapping and the retirement wind-down timeline
Understand Direct Lake storage mode -- Direct Lake on OneLake vs on SQL, guardrails table, and storage mode comparison
How Direct Lake works -- transcoding, framing, fallback conditions, and DirectLakeBehavior
Direct Lake and storage -- cold/warm/hot states, bootstrapping, row group sizing, and the VACUUM hazard
Delta Lake table optimization and V-Order -- V-Order defaults, write cost, and configuration
Lakehouse SQL analytics endpoint -- read-only surface, metadata sync, and endpoint limitations
Fabric Warehouse T-SQL surface area -- the authoritative supported and unsupported T-SQL command list
Transactions in Fabric Warehouse -- snapshot isolation enforcement, table-level locking, and write-write conflicts
Query the Delta Lake logs of a warehouse -- asynchronous log publishing and DATA_LAKE_LOG_PUBLISHING
Lakehouse vs Warehouse decision guide -- capability comparison across the two item types
OneLake shortcuts -- internal and external shortcut types, caching, limits, and the identity passthrough exception
OneLake shortcut security -- passthrough vs delegated authorization and how security intersects
Mirroring in Microsoft Fabric -- supported sources, GA/preview status, latency, and the free-storage-per-CU cost model
Mirroring Azure Databricks Unity Catalog -- metadata mirroring, shortcuts, and prerequisites
Use Fabric mirrored catalogs from Azure Databricks -- the Databricks-side authorization warning
Use Iceberg tables with OneLake -- metadata virtualization, bidirectional conversion, and its limitations
OneLake and Azure Databricks -- ABFSS access with service principal authentication
Roles in workspaces -- the authoritative Admin/Member/Contributor/Viewer capability matrix
OneLake data access control model -- role composition, inheritance, limits, and propagation latency
SQL analytics endpoint and OneLake security -- user identity vs delegated identity mode and the mode-switch consequences
Fabric end-to-end security scenario -- inbound and outbound protection patterns end to end, with a worked medallion example
Overview of private links for Fabric -- tenant-level private link and the full list of affected features
Overview of workspace-level private links -- per-workspace isolation, FQDN construction, and DNS resolution behaviour
Supported scenarios for workspace private links -- supported and unsupported item types, limits, and troubleshooting
Workspace outbound access protection overview -- managed private endpoints vs data connection rules, connector granularity, and the tenant admin API
Managed private endpoints for Fabric -- outbound connectivity to firewalled Azure sources
Trusted workspace access -- workspace identity reaching firewall-enabled ADLS Gen2
Customer-managed keys for Fabric workspaces -- supported items, key vault requirements, revocation, and the exclusion list
Multi-Geo support for Fabric -- capacity region vs home region and the tenant metadata that never leaves home
OneLake disaster recovery and data protection -- ZRS/LRS defaults, the capacity DR setting, and asynchronous failover behaviour
Fabric disaster recovery experience-specific guidance -- per-workload recovery procedures and what customers must back up themselves
Conditional Access for Fabric -- the five target resources to include and the CAE limitation
Track user activities in Microsoft Fabric -- audit log access through the Microsoft Purview portal
Manage audit log retention policies -- default retention, licence dependencies, and the 10-year add-on
Sensitivity labels in Fabric and Power BI -- labelling support matrix and downstream inheritance directionality
Eventhouse overview -- UpTime billing, autoscale, and the Capacity Scheduler
OneLake availability for Eventhouse -- the logical Delta copy and its restrictions
Real-Time Intelligence consumption -- OneLake Cache vs Standard storage tiers and their governing policies
Fabric deployment patterns -- Azure Architecture Center guidance on capacity, workspace, and region topology