A team is preparing a production rollout and needs to avoid a design mistake. Which approach best demonstrates multi-engine approach in a IBM Certified watsonx Data Lakehouse Engineer environment?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal: watsonx.data's multi-engine architecture is like having a Swiss Army knife where each tool is actually full-sized. Presto handles interactive SQL at scale, Spark handles heavy ETL and ML workloads, Db2 handles transactional queries — but they all read from the SAME governed data. You pick the engine that fits the job, not the data. Creating isolated copies for each engine defeats the whole architecture.
Full explanation below image
Full Explanation
The correct answer is to select the right engine for the workload while sharing governed data through the lakehouse. IBM watsonx.data's multi-engine design allows Presto (for interactive analytics), Apache Spark via IBM Analytics Engine (for ETL and ML), and Db2 (for SQL-compatible transactional workloads) to all access the same Iceberg tables through the shared HMS catalog. Option B (isolated copies per engine) is wrong because it creates data duplication, consistency gaps between copies, and defeats cost reduction — you pay for and manage multiple full copies of your data. Option C (one engine for all workloads) is wrong because no single engine is optimal for all workloads — Presto excels at ad-hoc queries but is not designed for iterative ML; Spark handles complex transformations but has higher latency for simple lookups. Option D (bypassing governance when switching engines) is wrong because governance policies must apply uniformly regardless of engine — otherwise a user could bypass a data masking policy simply by switching query engines.