An architect proposes copying every federated source into the lakehouse first, then federating those copies, to guarantee consistent performance. What is wrong with this plan?
Select an answer to reveal the explanation.
Short Explanation
You ingest or federate; they're alternatives, not a sequence. Once a copy is sitting in the lakehouse as a governed table, you query it directly. Wrapping it in federation just adds indirection and gives you nothing back.
Full Explanation
The correct answer is that once the data is ingested it should be queried as a lakehouse table; federating a local copy adds a layer with no benefit. Federation exists to reach data that has not been moved. Once the data has been ingested into the lakehouse it is a table in a catalog, and engines query it natively with the full benefit of open table formats and object storage layout. Introducing a federation layer over local data adds configuration and an extra hop while removing none of the ingestion cost the plan already paid. The claim that federation cannot target tables that are held in the lakehouse's own catalogs is incorrect as a statement of capability, but capability is not the issue. The plan's defect is that it is pointless, not that it is impossible. The claim that it is a sound pattern, and is the recommended way to stabilise federated performance, is incorrect because the recommended way to stabilise performance is exactly to ingest and then query directly. The proposal keeps the ingestion and adds overhead on top. The claim that copies cannot be governed, so the federated layer would be the only enforcement point, is incorrect because ingested tables are governed like any other lakehouse table. Being a copy does not place data outside policy. For the exam, hold the decision as a fork: query in place with federation, or move the data and query it as a lakehouse table.