A team is preparing a production rollout and needs to avoid a design mistake. What is the best way to handle multi-engine approach while staying aligned with the certification objectives?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal: IBM watsonx.data is not a single-engine platform — it's a multi-engine ecosystem. Think of it like a toolbox: you wouldn't use a screwdriver to hammer a nail. Presto handles interactive SQL, Spark handles large-scale batch and ML workloads, and Db2 Warehouse handles mixed analytical-transactional workloads. The magic is that they all share the same governed data layer, so there's no duplication.
Full explanation below image
Full Explanation
The multi-engine approach in IBM watsonx.data allows Presto, Apache Spark, Db2 Warehouse, and other supported engines to operate on shared, governed Iceberg tables stored in object storage. Engine selection is workload-driven: Presto excels at low-latency interactive queries, Spark at large-scale data transformation and ML pipelines, and Db2 Warehouse at mixed analytical and transactional workloads. Creating isolated copies for every engine (Option B) defeats the entire purpose of the shared storage architecture — data becomes inconsistent across copies and storage costs multiply without adding any analytical value. Using one engine for every workload regardless of fit (Option C) guarantees performance degradation; Presto is not optimized for ML training, and Spark is not optimized for sub-second interactive queries. Bypassing governance when switching engines (Option D) creates a security gap where governed data in one engine becomes ungoverned when queried by another — the governance model must follow the data across all engines. Proper multi-engine architecture is central to watsonx.data's value proposition and a core exam topic.