A business intelligence team needs to build dashboards over curated Iceberg tables held in watsonx.data. They ask the platform team how their BI tool should reach the data. What is the appropriate answer?
Select an answer to reveal the explanation.
Short Explanation
The engine is the front door. Point the BI tool at the Presto engine through standard SQL connectivity, and every query inherits the catalog's table definitions and the platform's access controls. Going around the engine means going around the governance that lives there.
Full Explanation
The appropriate answer is to connect the BI tool to a Presto engine over JDBC or ODBC and query the governed catalog tables. Consumption in watsonx.data happens through a query engine. The Presto engine exposes standard JDBC and ODBC endpoints, so BI tools connect the same way they would to any SQL source, and the tables they see are the governed catalog tables with access policies applied.
Giving the BI tool direct read access to the object storage bucket so it can read the Parquet files is incorrect because reading the underlying files bypasses the catalog and the access controls layered above it. The tool would also have to interpret Iceberg's metadata itself to know which files constitute the current table state, and a snapshot taken mid-write can be read inconsistently.
Exporting the tables to CSV on a schedule and having the BI tool import the extracts is incorrect because scheduled extracts produce dashboards that are as fresh as the last export rather than as fresh as the data, and each extract is an ungoverned copy sitting outside the platform.
Having the BI tool call the catalog's metadata API and reconstruct the tables client-side is incorrect because the metadata API describes the tables; it does not serve their rows. Reconstructing table state client-side reimplements the engine badly and inherits none of its governance.
For the exam, treat the engine as the supported consumption path and direct file access as the anti-pattern.