A data storage choice is an operating contract
Microsoft Fabric supports lakehouses, warehouses, OneLake shortcuts, mirrored data and Real-Time Intelligence paths. Microsoft Fabric DP-700 expects the engineer to choose an appropriate store and loading pattern instead of treating every item as the same database with a different icon. The decisive requirements include data structure, write ownership, update frequency, query pattern, source control, consumer language, governance and what happens when the underlying source changes.
Consider an organization consolidating financial transactions, clickstream events and shared reference tables. Repeatedly copying a static dimension into several lakehouses might add unnecessary synchronization risk, while streaming millions of events into a batch-only destination could create unacceptable latency. A SQL-heavy modeled mart may benefit from a Fabric warehouse, while large raw and semi-structured files naturally fit lakehouse storage. The platform allows combinations rather than demanding one universal store.
The current Fabric Data Engineering overview explains lakehouses, notebooks, job definitions and pipelines. Use these capabilities to frame a concrete data contract: who writes, who reads, where physical storage lives, what transformations are needed and who can investigate an outage.
A lakehouse combines file flexibility with Delta table semantics
A Fabric lakehouse uses OneLake storage and provides file and table areas. Delta Lake is the preferred and typically default table format for managed lakehouse tables, bringing transaction-log semantics alongside the columnar file layout. A raw JSON landing zone and a curated Delta fact table are not interchangeable, even when both are stored under the same lakehouse item. The first may preserve unvalidated source evidence while the second promises a defined schema and consistent update behavior.
The Delta table documentation describes why these tables fit data engineering: transactional updates, history and broad integration. However, ACID table storage does not automatically detect duplicate business events or determine which source is authoritative. That remains a pipeline and quality-contract responsibility.
When modeling a bronze/silver/gold flow, decide whether layers should be separate tables or lakehouses based on ownership, permissions and operations—not because three labels look good in a diagram. Preserve the original source evidence when replay or audit is required and document which changes are allowed in each curated layer.
OneLake shortcuts can reuse data without another full copy
A shortcut exposes supported data from another OneLake path or external store through a logical reference. This can reduce unnecessary copying and give consumers a familiar Fabric location for source data. But the location, source permissions, format and availability remain meaningful. If a partner revokes source access or reorganizes a folder, a shortcut may stop resolving or return a different set of files, depending on configuration.
Use a shortcut when the source is already suitable for supported consumption, the organization has a legitimate shared access path and copying would add more problems than it solves. For example, a governed reference table managed by a central team might be reused by several subject-area workspaces. The consuming teams still need clear schema expectations and incident ownership because they do not control the producer’s refresh schedule.
The engineer should distinguish a shortcut’s existence from a successful query. A destination item can be visible even when the backing credentials, storage format or engine compatibility prevent the intended operation. OneLake security determines which identity and data permissions apply to those references.
If the upstream team controls the file schema, introduce a source-change agreement. For example, require notification before renaming columns or replacing a Delta table with raw CSV files, and set a validation check for the consumer’s expected fields.
A shortcut gives the consuming workspace access to the source path but does not create a private historical snapshot of every old value. For regulated analytics, decide whether a retained copy or curated layer is needed for reproducibility, and document the cost and privacy consequences before adding one. The right answer follows audit requirements, not a generic preference for zero-copy.
Mirroring is a different synchronization decision
Mirroring can replicate supported data from a source system into Fabric-managed analytical storage according to the connector’s capabilities. Unlike a shortcut that references existing data, mirroring is intended to maintain a synchronized analytical copy. That can relieve a team from creating its own periodic extract jobs for particular supported sources, but it also introduces questions about source onboarding, change propagation, latency, schema evolution and cost.
For a transactional database whose changes must be analyzed without placing heavy reporting queries on the source, supported mirroring may be a strong option. Before selection, confirm that the exact database engine, edition and object types are supported. Do not assume every source field, security setting or schema alteration is replicated identically. Document what happens to update and delete events and what an interruption looks like in monitoring.
Choosing mirroring because it sounds simpler than a pipeline can fail if the target needs complex cleansing or business mapping before consumers use it. Mirroring and transformation are separate responsibilities. A mirrored bronze-like dataset may still require managed normalization and privacy controls in a curated layer.
Mirroring also changes failure interpretation. If replication pauses after a source maintenance window, the destination may still be queryable, but its freshness can fall behind the business requirement. Build an alert around the expected change-propagation delay and expose the last reliable update time to consumers.
An analyst viewing a mirrored table must not infer that a successful SELECT means the source system’s latest transaction has arrived. When processing corrections, reconcile source counts or representative change records rather than only checking whether the replicated object exists.
A warehouse fits governed relational consumption patterns
A Fabric data warehouse offers a SQL-centric approach for analytical tables and transformations. It is attractive for teams with dimensional models, relational joins and established T-SQL development practices. The distinction from a lakehouse is not that one is always faster or more secure; it is which development and consumption model fits the actual workload and engine support.
An order-processing example can have raw parquet files landed in OneLake, a Spark transformation producing curated Delta tables and a downstream relational fact/dimension model maintained in a warehouse. Another company may perform most transformations directly in a warehouse. Choose based on existing skills, write operations, transactional behavior, query patterns and actual complexity rather than artificially duplicating each table in two engines.
The architecture should state the source of truth. When a row is corrected, identify where it is changed, how that correction reaches the analytical table and what consumer freshness is guaranteed. If two gold copies are maintained, reconcile them explicitly. A diagram claiming ‘single source of truth’ is meaningless if two teams can overwrite the same business measure differently.
Real-Time Intelligence adds choices for high-velocity events
Eventstreams and Eventhouses address event-driven ingestion and KQL-oriented analysis. A high-volume telemetry feed may be better handled by this path than by attempting to reprocess every event through a nightly warehouse procedure. But even here, the design must account for retention, late events, partitioning, processing windows and the consumers’ latency tolerance. A near-real-time dashboard is not automatically an authoritative finance ledger.
Fabric can also expose OneLake data through shortcuts for supported Real-Time Intelligence use cases, with query acceleration available under applicable conditions. Caching does not change the fact that a query consumes externally managed source data, and it can have separate capacity and storage costs. Prefer an architecture test against actual query patterns over a blanket statement that shortcut access is always as fast as native event ingestion.
Choose between stored copies and referenced data by checking freshness requirements, ownership and access paths. Event processing and storage placement are separate decisions; neither a successful event arrival nor a shortcut alone proves the analytical result is correct.
Choose with a comparison built around failure and ownership
For each candidate architecture, record source, ownership, storage location, transformation engine, latency goal, update/delete behavior, required permissions, performance expectations and recovery path. A shortcut saves copies but may introduce dependence on a producer’s availability. Mirroring simplifies certain source synchronization but does not promise all transformations are complete. A warehouse can suit governed SQL modeling but may not be the best raw-file landing zone.
Test a change event and an outage. What happens if a source column is renamed? Does a mirrored destination pause, a shortcut query fail or an ingestion notebook reject the record? Which service logs reveal the problem, and who can fix it? If a consumer uses a cached view, will the freshness label be honest after an ingestion interruption? These scenarios expose operational differences better than product tables full of green ticks.
DP-700 readiness means defending one reasonable architecture while acknowledging tradeoffs and scope. The exam asks engineers to build a maintainable system, not to endorse a particular Fabric item because it is newest or most visually prominent.
Ownership can decide between two architectures that appear equivalent in a slide deck. A central reference-data team might promise a maintained source table with stable permissions; then a shortcut can make contractual sense.
A payment processor might demand proof that a daily regulatory report can be regenerated from the exact historical extract; then a versioned retained landing copy can be justified despite additional storage. Write the decision as an explicit tradeoff with a test and responsible owner. If that contract later changes, revisit the architecture instead of preserving a decision made for an earlier workload.