A team proposes managing table permissions inside their BI tool rather than in watsonx.data, arguing that all reporting goes through that tool anyway. Why is this a weak design?
Select an answer to reveal the explanation.
Short Explanation
Governance belongs to the platform, not to one client, because the platform is the path every engine and client goes through. If you put rules only in the BI tool, a query workspace, notebook connection, or other engine can still reach the same data without asking that tool for permission.
Full Explanation
The correct answer is the one stating that governance applied in one client leaves every other engine and client path unprotected. In watsonx.data, governance sits alongside storage, metadata, and engines as a platform component precisely so that it applies to every path to the data. Enforcing rules inside a single client protects only that client; the query workspace, a JDBC connection from a notebook, and any other engine associated with the same catalog all remain unaffected.
The option saying BI tools cannot express row-level rules, so the policies would be too coarse, is incorrect because it argues capability rather than architecture. Even a BI tool with sophisticated row-level rules would only apply them to its own users, which is the actual defect.
The option saying the catalog would reject queries from a tool that manages its own permissions is incorrect because the catalog does not police what clients do internally. It will serve any authorised connection regardless of what that client believes about permissions, which is exactly why the design fails quietly.
The option saying it is a sound design as long as the BI tool is the only tool ever connected is incorrect because it rests on a condition no platform team can guarantee. Access paths accumulate, and a control that depends on nobody ever adding one is not a control.
For the exam, associate governance with the platform layer, applied at query time, independent of client.