A team is preparing a production rollout and needs to avoid a design mistake. The team is focused on federated queries. Which recommendation is most appropriate?
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.