An Eventhouse in Microsoft Fabric ingests telemetry into a native KQL table. Interactive KQL queries over the most recent fourteen days have become slow, and capacity metrics show those queries reading from cold storage because the hot cache holds only a few days. The data already lives natively in the Eventhouse, so the team wants the recent window served from memory without moving or duplicating it. Which change best restores low-latency queries on the recent data?
- AExtend the table caching policy so the hot cache covers the full fourteen-day window, keeping the recent data in memory instead of spilling to cold storage. Correct
- BEnable query acceleration on the native KQL table so the engine maintains an accelerated cache that serves the recent fourteen-day window from memory.
- CReplace the native table with a OneLake shortcut to the same telemetry as Delta files, letting the shortcut acceleration cache hold the recent window in memory.
- DRun OPTIMIZE and VACUUM on the underlying telemetry so fewer, larger files are scanned and the recent fourteen-day window loads from memory faster.
Why A is correct: The caching policy sets how many days of a native KQL table stay in the hot cache, so extending it to cover fourteen days keeps the recent window in memory and restores low-latency interactive queries.
Why B is wrong: Query acceleration applies to OneLake shortcuts over external data, not to native KQL tables, so it is the wrong lever for data that already lives inside the Eventhouse engine.
Why C is wrong: Swapping a native table for a shortcut moves the data out of the indexed engine and adds an external reference, which does not improve hot-window latency and removes native ingestion control.
Why D is wrong: OPTIMIZE and VACUUM are Delta maintenance commands for Lakehouse tables and do not govern the Eventhouse hot cache, so they cannot decide how much of the recent window stays in memory.