Governance leadership wants one consistent data-access rule enforced no matter whether a branch analyst queries a Lakehouse's tables through the SQL analytics endpoint, a Spark notebook, or a Power BI report, rather than configuring the restriction separately in each engine. Which Fabric capability is designed to provide this consistency?
Select an answer to reveal the explanation.
Short Explanation
OneLake security sits underneath every engine that touches the data, like a single set of vault rules that apply no matter which door — SQL, Spark, or Power BI — an analyst happens to walk through.
Full Explanation
OneLake security is designed to enforce access rules at the underlying data layer itself, so the same restriction — whether the default role or a custom OneLake data access role — applies consistently regardless of which compute engine (the SQL analytics endpoint, a Spark notebook, Power BI, or any other OneLake-aware tool) is used to read the data. This directly satisfies governance's requirement for one rule enforced everywhere, without re-implementing it per engine. Configuring row-level security separately in SQL, Spark, and Power BI is exactly the fragmented, error-prone approach governance wants to avoid — three separate configurations to keep in sync, with real risk of them drifting apart over time. Dynamic data masking scoped only inside the Power BI dataset would leave the same data fully unmasked when queried directly through SQL or Spark, defeating the consistency goal entirely. Endorsing the Lakehouse as Certified is a trust-and-quality signal with no access-control effect whatsoever, so it does nothing to enforce any rule, consistent or otherwise. To validate, an engineer should query the same restricted table through the SQL endpoint, a Spark notebook, and a Power BI report as the same restricted user and confirm identical enforcement in all three.