A team lists three concerns about a reporting model on "Microsoft Fabric" capacity: reports must reflect new Delta rows within minutes, the model must not duplicate the lakehouse data, and a separate import model has outgrown the small default per-model size limit. They ask which concern the large semantic model storage format is the correct tool to address. Which concern does enabling the format actually resolve?
- AThe need for reports to reflect newly written Delta rows within minutes, which the format delivers by refreshing the cache automatically whenever the underlying lakehouse tables change.
- BThe requirement that the model avoid duplicating the lakehouse data, which the format meets by leaving the rows in OneLake and reading them in place rather than importing a copy.
- CThe separate import model that has outgrown the small default per-model size limit, which the format addresses by raising that model's ceiling toward the capacity maximum. Correct
- DAll three concerns at once, because enabling the format simultaneously adds live Delta freshness, removes data duplication, and raises the per-model size limit for the import model.
Why A is wrong: Near real-time freshness over Delta is a Direct Lake concern, not a size-format one; the large format does not auto-refresh a cache when lakehouse tables change, so it does not solve this.
Why B is wrong: Reading data in place without duplication describes Direct Lake; the large format applies to imported in-memory data, so it does not prevent duplication of the lakehouse rows.
Why C is correct: Lifting an import model past the small default per-model size limit is precisely what the large format does, so this is the one concern of the three that the format is the right tool to resolve.
Why D is wrong: The format only raises the size ceiling; freshness and no-duplication are Direct Lake properties, so claiming it solves all three conflates separate Fabric capabilities into one feature.