An administrator is troubleshooting a pilot deployment and wants the most appropriate next step. For IBM Certified watsonx Data Lakehouse Engineer, the topic is source integration. What should the team do?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Think of it this way: federation in watsonx.data is like a reference librarian who can look up books in other libraries without physically moving those books to your branch. Your query runs locally, but Presto's connector framework pushes relevant filter predicates down to the remote source and retrieves only what you need. This is not magic — remote sources that are slow stay slow, and federation does not replace local access control.
Full explanation below image
Full Explanation
The correct answer is to use federation when data should be queried across sources without unnecessary movement. IBM watsonx.data's Presto engine supports federated queries through its connector framework — you can query Db2, MongoDB, MySQL, PostgreSQL, and other supported sources alongside lakehouse Iceberg tables in a single SQL statement, with predicate pushdown to minimize data transfer. Option A (federating only after duplicating locally) is wrong because it defeats the purpose of federation; if you're going to duplicate locally first, you don't need federation. Option B (using federation to avoid access controls) is wrong because federated queries still respect both the watsonx.data access control layer AND the source system's own authentication and authorization; federation does not bypass either. Option D (assuming federation makes slow sources fast) is wrong because federation executes queries in the source's own query processor — a remote OLTP database with poor indexing will respond slowly to federated queries regardless of the Presto connector.