Fabric / Architecture / Enterprise AI / Governance
Microsoft Fabric Architecture Podcast
Architecture decisions in Microsoft Fabric, beyond the marketing: Lakehouse versus Warehouse, ingestion patterns, Spark pitfalls, Real-Time Intelligence and DevOps for scalable data platforms.
11 episodesavg. 21 minLast update: 20 August 2026EnglishPodcast hosts Laura Bennett and Mark Sullivan
Now playing
Episode 1.10 - Microsoft Fabric Security: OneLake Security, RLS or OLS?
0:000:00
Sign in to track your progress automatically in My Learning Journey.
All episodes
Also on SpotifyPractice what you learned
Apply the concepts from this episode right away in the Architecture Lab.
- Lakehouse or WarehouseDraw the medallion boundary for a mixed analytics workload.
- Design your Data & AI platformTurn a few decisions into a reference architecture.
Knowledge check
Open the Architecture Lab Question 1 of 6
A retail company wants Spark engineers, SQL analysts and Power BI developers to work on the same data without creating duplicate copies. Which architecture best aligns with Microsoft Fabric best practices?
Question 2 of 6
A partner tells a prospect that Copilot in Fabric only becomes available from an F64 capacity onward, based on what applied back during preview. Is that still accurate, and what should the partner actually check now?
Question 3 of 6
After a good demo, an architect wants to bring all of a manufacturer's data sources into Fabric via Mirroring, including the SAP ERP and the EDI and CSV files on SFTP. Why can you not adopt that as-is for either source?
Question 4 of 6
Five multi-tenant customers share a Spark transformation capacity. The team relies on row-level security defined on the SQL analytics endpoint for tenant isolation. Why does that not protect the tenants once an engineer with workspace access works in a notebook?
Question 5 of 6
A Fabric report built on a Direct Lake semantic model suddenly becomes much slower after the underlying Delta tables grow well beyond their original size. What is the most likely explanation?
Question 6 of 6
A team manages Dev, Test and Prod Fabric workspaces connected through Git integration and deployment pipelines. Connection strings and lakehouse IDs differ per environment. What is the recommended way to manage these differences?
Learn more?
Go deeper on the same topic.
How-tos
How to build an agentic application with Fabric and FoundryFrom governed data in Microsoft Fabric to an agent in Microsoft Foundry that answers questions about it, with the decision that shapes the architecture at every step.How Microsoft partners can become a Frontier PartnerFrontier Transformation asks more of a partner than an AI page on the website. This is the route: your own organization first, then a knowledge foundation, agents around real workflows, governance from day one and a business model that holds up.How to set up CI/CD for Microsoft FabricThe control plane in code, the data plane through a release mechanism: which of the four deployment patterns fits you, and why your network choice may have already made that call.
Use cases
Manufacturing: Databricks and Fabric side by side with one governance layerA manufacturer keeps data engineering and ML on Azure Databricks and reporting in Microsoft Fabric, and connects both through Unity Catalog and Microsoft Purview into one view of lineage and access.Finance: demonstrable lineage for regulatory reportingA financial institution consolidates a patchwork of services onto Fabric and builds controlled, demonstrably correct regulatory reporting with Warehouse, Purview lineage and Git-driven ALM.Government: data mesh with delegated ownershipA municipality exposes department data as an integral view through Fabric domains and OneLake shortcuts, with delegated ownership per department and central GDPR safeguards.
Do you have a similar challenge?
Use the podcasts as inspiration, or share your own Data & AI challenge with us.