A team is preparing a production rollout and needs to avoid a design mistake. For IBM Certified watsonx Data Lakehouse Engineer, the topic is federated queries. What should the team do?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal: federation in IBM watsonx.data is like conference calling across databases — you can query a remote PostgreSQL, a Db2 table, and an Iceberg lakehouse table in a single SQL statement without physically moving any data first. It's not magic, and it won't make a 100ms remote source respond in 10ms, but it eliminates unnecessary ETL for data that doesn't need to live in the lakehouse.
Full explanation below image
Full Explanation
IBM watsonx.data supports federated queries through the Presto query engine using built-in connectors that translate SQL to the remote source's native protocol at query time. This allows analysts to join lakehouse data with live operational database records without running ETL pipelines or maintaining duplicate copies. Federating only after duplicating every source locally (Option A) defeats the entire purpose of federation — the whole value is avoiding duplication; this approach incurs ETL costs, introduces data freshness lag, and adds storage overhead without any governance benefit. Using federation to avoid all access controls (Option B) misunderstands how federation works — remote source queries still require valid credentials and respect the remote system's access controls, and the lakehouse catalog enforces its own policies on federated virtual tables. Assuming federation makes slow remote sources local (Option D) is a performance misconception — federation queries the remote source in real time, so remote latency is still experienced; caching or ingestion is required if low latency is needed. The certification expects candidates to apply federation selectively where data freshness and movement avoidance justify the remote query overhead.