A federated query against a remote warehouse is slow, and monitoring shows a very large volume of data being read across the network for a query whose result is a few hundred rows. What should be examined first?
Select an answer to reveal the explanation.
Short Explanation
If you see tiny results from huge network reads, the filtering is happening on the wrong side of the wire. Check pushdown first: see whether filters and column projections are being sent to the source, and look for query constructs that stop the connector from delegating them.
Full Explanation
The symptom described - a large read producing a small result - is the classic signature of filters being evaluated locally after the data has crossed the network. Connectors push predicates and projections down where the source supports them, but constructs the remote system cannot interpret force the engine to pull rows and filter them itself. Examining whether filters and column projections are being pushed down to the source rather than applied after transfer is the first diagnostic step.
The lakehouse bucket storage tier is incorrect because the lakehouse bucket is not in the path of a federated read. The data is coming from the remote source, not from object storage.
The query history retention option is incorrect because retention affects how long you can review a query afterwards, not how it executes.
The catalog re-association option is incorrect because association is a reachability concern. The query that runs and returns rows has already proved the catalog is reachable.
For the exam, tie the phrase much more data read than returned directly to pushdown.