A watsonx.data administrator is decommissioning a Presto engine that was created for a project that has ended. Another team's catalog is still associated with that engine. What should the administrator do before deleting it?

The correct answer is to confirm which catalogs are associated with the Presto engine and ensure their consumers are served by another engine before deleting it. Engines, catalogs, and buckets have independent lifecycles in watsonx.data, and an association simply says which engine serves which catalog. Removing an engine therefore breaks the query path for every consumer that was reaching a catalog through it, even though the catalog and the underlying data are untouched. The safe sequence is to establish who is affected and associate their catalog with an alternative engine before the deletion.

Deleting the engine on the assumption that the associated catalog and its tables are removed with it is incorrect and is the dangerous misconception here. Catalogs and tables are not children of an engine; the data on object storage and its metadata both persist. Anyone acting on this belief will either be surprised that the data survived or, worse, delete an engine assuming the cleanup was complete.

Deleting the associated catalog first, then the engine, is incorrect because it destroys metadata another team is actively using in order to tidy up a project that has ended. Nothing about the engine's removal requires the catalog to go with it.

Pausing the engine indefinitely instead, because associations make deletion impossible, is incorrect because associations do not block deletion. Leaving a paused engine in place indefinitely also leaves an unowned object in the topology for the next administrator to puzzle over.

For the exam, remember that these objects are independent and that association is the thing you break.