An administrator is troubleshooting a pilot deployment and wants the most appropriate next step. Which approach best demonstrates open lakehouse architecture in a IBM Certified watsonx Data Lakehouse Engineer environment?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Think of it this way: an open lakehouse is like a public library with proper librarians. The books (data files) sit on open shelves (object storage), the catalog tells you where everything is (Hive Metastore or HMS), and the reading rooms (query engines) are separate from the collection itself. Open table formats like Apache Iceberg are the shelving system — standardized enough that any engine can find and read what it needs without copying the whole collection into its own room.
Full explanation below image
Full Explanation
The correct answer is to use open table formats on object storage with governance and query engines layered above the shared data. IBM watsonx.data's architecture stores data as Apache Iceberg (or Delta/Hudi) tables on object storage (IBM Cloud Object Storage, AWS S3, etc.), with a shared metadata layer (Hive Metastore) that multiple query engines — Presto, Spark, Db2 — all read from simultaneously. Option B (proprietary warehouse) is wrong because it creates vendor lock-in, prevents multi-engine access, and eliminates the cost and flexibility advantages of the lakehouse pattern. Option C (raw files with no metadata) is wrong because without table metadata, SQL engines cannot discover, partition-prune, or time-travel on the data. Option D (copying to separate marts per engine) is wrong because it creates data duplication, stale copies, and governance gaps that defeat the entire purpose of a shared lakehouse.