I'm working through the DP-700 (Microsoft Fabric Data Engineer Associate) certification, and the section that made me actually stop and take proper notes wasn't the storage architecture — it was governance. Specifically, OneLake's catalog and its endorsement system. It's easy to treat governance as the "boring compliance section" of a data platform, but once I worked through it, it became clear this is the layer that decides whether anyone downstream can actually trust the data they're looking at.
Here's a practical breakdown of what I learned, mostly from my own notes.
The problem governance is solving
Before getting into the catalog itself, it's worth naming the problem. In a typical data estate:
- Separate storage accounts, databases, and filesystems per team
- Teams keeping their own copies of "the same" data
- The predictable result: duplication, then inconsistency
OneLake's answer at the storage layer is a single unified, tenant-wide storage layer — one copy of data instead of five slightly different ones, with shortcuts letting teams reference data without physically copying it. But a shared lake only helps if people can actually find, trust, and understand what's in it. That's what the catalog and endorsement system are for.
OneLake Catalog: discovery, not just storage
The catalog is what makes OneLake searchable rather than just centralized. It lets you:
- Discover and browse data assets across the entire Fabric tenant
- Search by name, or browse by workspace and domain
- View metadata for each item — name, type, owner, last refresh time, workspace location, sensitivity labels, and endorsement status
That last point matters more than it sounds. A catalog entry isn't just "here's a table" — it's "here's a table, here's who owns it, here's when it last refreshed, here's whether it's been reviewed, and here's how sensitive it is." That's the difference between a data swamp and a governed lake: the metadata travels with the data, not in a separate wiki someone forgot to update.
Governance and security capabilities sit directly under this catalog, and it connects to Microsoft Purview for the broader data governance picture — classification, sensitivity labeling, and lineage tracking all roll up into the same system.
Sensitivity labels and access control
Sensitivity labels are the access-control half of governance. You classify data, apply a label, and that label determines who can see what and how the data can be tracked and shared — including lineage, so you can trace where a piece of data came from and where it's been used downstream.
This is the part BI-focused work often skips. Building a dashboard rarely forces you to think about who shouldn't see a given field, or how to prove where a number in a report actually originated. Governance makes that thinking mandatory rather than optional.
Endorsement levels: how trust gets signaled
This is the part I found most useful, because it gives you a vocabulary for something every data team deals with informally anyway: is this data actually reliable, or did someone just throw it in the lake?
OneLake has three endorsement levels:
| Level | Meaning |
|---|---|
| Promoted | Ready for sharing — write-permission holders can promote an item themselves |
| Certified | Meets organizational standards, reviewed and approved by an authorized reviewer |
| Master data | The authoritative source of truth for core organizational data, reviewed by authorized reviewers |
The jump from "promoted" to "certified" is the important one — it moves trust from self-declared to reviewed. Anyone can promote their own work as ready. Certification requires someone else, with authority to do so, to actually check it against a standard. "Master data" goes further still: it's not just correct, it's the reference version that everything else should be measured against.
Read as a system, these three levels give an organization a shared language for data maturity — the same way "draft," "peer reviewed," and "canonical" might work in a documentation system. Without it, every team just calls their own numbers "the real numbers," and nobody has a tiebreaker when two dashboards disagree.
How data actually gets into this governed lake
For context, OneLake supports five ingestion paths, each with different governance implications:
- Mirroring — continuous replication from an external database with automatic updates
- Pipelines — orchestrated data movement and transformation at scale
- Dataflows — Power Query connects to sources, transforms, and loads (e.g., into Power BI or Excel)
- Streaming — real-time data through event streams (IoT, app logs, clickstreams)
- Direct upload — straight into OneLake through the Fabric interface
None of these paths are inherently "governed" — governance is applied on top, through catalog metadata, sensitivity labels, and endorsement. Which means the ingestion method you choose doesn't excuse you from the governance step afterward. A table streamed in through an event hub still needs an owner, a sensitivity label, and eventually a trust level, same as one uploaded manually.
Why this matters beyond the exam
I've spent most of my career on the visible, consumer-facing side of data work — dashboards, semantic models, the layer people actually look at. Governance sits underneath that, invisible when it's working and painfully obvious when it's not (inconsistent numbers, no one sure which table is "the real one," no idea who to ask when something looks wrong).
Studying OneLake's catalog and endorsement system gave me a concrete framework for a skill I'd mostly practiced informally: knowing which data to trust, and being able to explain why. That's a small but real shift — from just building on top of data, to being able to reason about whether the data underneath deserves to be built on.
I'm an Analytics Engineer based in Nairobi, currently working through the DP-700 certification and co-leading the Kenya Tableau User Group. If you're studying Fabric too, or have thoughts on how your org handles data trust/endorsement in practice, I'd like to hear about it.
Top comments (0)