A team is preparing a production rollout and needs to avoid a design mistake. For IBM Certified watsonx Data Lakehouse Engineer, the topic is multi-engine approach. What should the team do?
Select an answer to reveal the explanation.
Short Explanation and Infographic
In a production lakehouse, engine selection is a workload decision, not a team preference — Presto excels at low-latency ad hoc SQL while Spark owns heavy transformation and training jobs, and both read from the same governed Iceberg catalog. The key insight is that sharing data through a common catalog eliminates data silos without sacrificing engine specialization. Isolated copies for each engine or forcing a single engine onto every workload both blow up your storage costs and governance story.
Full explanation below image
Full Explanation
The correct answer is option A: Select the right engine for the workload while sharing governed data through the lakehouse.. This aligns with IBM's IBM watsonx.data platform architecture guidance, which emphasizes select the right engine for the workload while sharing governed data through the lakehouse as the recommended approach for production deployments. Option B (Create isolated copies for every engine) is incorrect because it either bypasses IBM's recommended architecture or introduces operational risk that the correct approach is specifically designed to avoid. Option C (Use one engine for every workload regardless of fit) is incorrect because it either bypasses IBM's recommended architecture or introduces operational risk that the correct approach is specifically designed to avoid. Option D (Bypass governance when switching engines) is incorrect because it either bypasses IBM's recommended architecture or introduces operational risk that the correct approach is specifically designed to avoid. Understanding this distinction is critical for the C9007300 exam: IBM watsonx.data is designed to enforce governance, performance, and operational best practices through its built-in architecture, and the correct answers consistently reflect those architectural constraints rather than shortcut alternatives.