A data engineering team has provisioned watsonx.data and added a Presto engine. They now have a governed catalog of Iceberg tables that analysts need to query through that engine, but the tables do not appear when analysts connect. In Infrastructure Manager, what still has to be done?

The correct answer is the option that says to associate the catalog with the Presto engine so the engine can see and serve its tables. In watsonx.data, Infrastructure Manager is where engines, catalogs, buckets and services are registered and, critically, where they are associated with one another. A catalog is not globally visible to every engine on the platform; it is served by the engines it has been associated with. Until the Iceberg catalog is associated with that Presto engine, the engine has no metadata for those tables and analysts connecting to it will see nothing.

The restart option is incorrect because restarting the engine re-reads the associations that already exist. If none exists, a restart changes nothing, and it interrupts every other query the engine is serving.

The grant-each-analyst-the-admin-role option is incorrect because it confuses authorization with topology. Access control decides who may read a table once an engine can see it; it does not make the catalog reachable from the engine in the first place. Granting Admin here is also a real security regression for no benefit.

The re-ingest-through-a-second-bucket option is incorrect because the data does not need to move. The lakehouse model keeps one governed copy on object storage, and duplicating it into a second bucket creates a divergent dataset with its own governance problem.

For the exam, remember that engine, catalog and bucket are registered independently and then explicitly linked.