A team argues that federating a source is a way to give analysts access to data that governance would otherwise restrict, because the data is never stored in the lakehouse. How should this be assessed?
Select an answer to reveal the explanation.
Short Explanation
Federation doesn’t dodge governance. You’re still accessing data, so the source’s controls and the lakehouse’s policies both apply.
Full Explanation
The correct assessment is the one saying it is wrong because federated access is still access, and both the source's controls and lakehouse policy apply to it. Governance follows the data regardless of where it is physically held. A federated query runs under a connection whose credentials carry the source system's own authorisation, and the platform's policies still govern which principals may use that catalog and its tables. Nothing about not copying the data removes either control.
The option saying it is correct because policies attach to stored tables and a federated table stores nothing is incorrect because it assumes policy is a property of storage. It is a property of the request, evaluated against the requesting identity at query time.
The option saying it is correct only for read-only federation, while write-back federation would be governed, is incorrect because governance is not conditional on direction. Reads are the very thing access policy is most concerned with.
The option saying it is wrong because federation cannot be used against sources that have access controls is incorrect for the opposite reason: federating a controlled source is entirely normal, and the connector authenticates to it like any other client would.
For the exam, treat any proposal that presents a technical mechanism as a way around governance as a distractor by construction.