DP-600 - Implement and Manage Semantic Models (27% of the exam) - Section 3.4

Identify use cases for and configure the large semantic model storage format.

Identify when a semantic model exceeds standard size limits and configure the large semantic model storage format to store data on disk rather than fully in memory. Understand the Fabric capacity and Premium capacity requirements for this feature and how enabling it affects XMLA write operations.

large semantic model storage formatmodel size limitsFabric capacityPremium capacityXMLA write

Practice question for this objective

Free sampleImplement and Manage Semantic Modelsmedium

An analytics engineer tries to enable the large semantic model storage format on an import "semantic model" that lives in a workspace backed by shared capacity under Power BI Pro licensing. The option to switch the model to the large format is unavailable. They need the model to be able to grow past the small default per-model size limit. What must change first so the format can be enabled?

AThe model must first be set to DirectQuery storage, because the large format is offered only once a model no longer caches any of its rows in memory on the shared tier.
BThe tenant XMLA endpoint must be switched from read-write back to read-only, since the large format is only exposed for models whose metadata cannot be written externally.
CA sensitivity label of at least Confidential must be applied to the workspace, because the large format becomes selectable only after the workspace content is classified for information protection.
DThe workspace must be assigned to a dedicated Fabric or Premium capacity, because the large semantic model storage format is available only to models hosted on such a capacity rather than on shared Pro capacity. Correct

Identify that the large semantic model storage format requires a dedicated Fabric or Premium capacity, not shared Power BI Pro capacity. The large semantic model storage format is a capacity-backed capability, so a model on shared Pro capacity cannot use it; assigning the workspace to a dedicated Fabric or Premium capacity is the prerequisite that makes the format selectable and lets the model exceed the small default limit.

Why A is wrong: The large format applies to in-memory import models, not DirectQuery, and changing storage mode does not unlock the format on shared capacity, so this addresses neither the tier nor the size ceiling.

Why B is wrong: Read-write XMLA is required for external metadata writes, not a blocker for the large format, so forcing the endpoint to read-only would restrict tooling without making the format available on shared capacity.

Why C is wrong: Sensitivity labels govern information protection and have no link to storage format availability, so labelling the workspace does nothing to expose the large format on shared capacity.

Why D is correct: The large format is a capacity feature, so the workspace must sit on a dedicated Fabric or Premium capacity; on shared Pro capacity the option is simply not offered, which is why it appears unavailable.

See more DP-600 practice questions, answers explained.

Exam traps in Implement and Manage Semantic Models

Answers that look right on this material and are not. Each one is a distractor from a different question in the DP-600 bank for this domain.

It moves the model out of memory and serves every report query by reading the compressed cache straight from disk, so capacity memory is no longer consumed during querying.
Why it is wrong: The format does not turn the model into a disk-served store; large-format models are still loaded into capacity memory to answer queries, so the claim that memory is no longer used is incorrect.
Set the model storage mode to DirectQuery in the scripting client, so the XMLA write only deploys metadata and no partitions are ever materialised in memory against the limit.
Why it is wrong: DirectQuery changes query behaviour and is not what the import pipeline needs; the engineer is loading partitions into memory, so the per-model size ceiling still applies until the large format raises it.
Switch the model from import storage to DirectQuery so that no data is cached in memory and the 1 GB import ceiling stops applying to it.
Why it is wrong: DirectQuery removes the cache but changes the whole storage mode and query behaviour, which is a re-architecture rather than simply lifting the import size ceiling the engineer asked to raise.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.