A consultant is advising a customer that wants a scalable implementation. For IBM Certified watsonx Data Lakehouse Engineer, the topic is SQL access. What should the team do?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal: data in IBM watsonx.data isn't meant to be handed out as raw object files or screenshots — it's meant to be queried through SQL engines that enforce governance. Think of it like a bank vault: the vault has the money, but you access it through a teller window with proper identification, not by going around back with a crowbar. SQL engines are that teller window.
Full explanation below image
Full Explanation
IBM watsonx.data provides SQL access through multiple governed interfaces: the built-in Query workspace (SQL Editor in the UI), the Presto JDBC/ODBC endpoints for BI tools, REST API query execution for applications, and the Db2 Warehouse SQL engine for OLAP workloads. The correct answer — guiding users to query governed lakehouse tables through supported SQL engines and interfaces — ensures that every query goes through the access control layer, generates query history, and respects catalog-level policies. Telling users to download raw object files (Option B) bypasses all governance controls and produces unmanaged data extracts that violate data lineage and access audit requirements. Requiring application teams to bypass metadata catalogs (Option C) breaks the governance chain — catalogs are the enforcement point for access policies, schema validation, and lineage tracking, and bypassing them leaves data ungoverned. Using only screenshots for data delivery (Option D) is not a data access strategy; screenshots contain no machine-readable data, break reproducibility, and create manually maintained, ungoverned data artifacts. SQL access through governed interfaces is the IBM-prescribed consumption model for the lakehouse.