A Fabric project can expose the same business dataset through three radically different mechanisms: a OneLake shortcut, a mirrored database, and a physically copied table. They may look similar to a report consumer, but a data engineer needs to know which component owns the bytes, which identity can read them, who controls schema evolution, and what happens when the upstream source fails. DP-700 tests this reasoning under its ingest-and-transform domain; the answer cannot simply be “use OneLake because it is unified.”
Microsoft’s OneLake shortcut guidance distinguishes references to existing data from ETL copies. The data movement decision guide separately compares mirroring, Copy job, pipeline Copy activity and Eventstreams. Read both before treating all ingestion mechanisms as synonyms.
First decide where the authoritative records live
Suppose an insurance company already maintains customer transactions in a managed operational database. Fraud analysts need a fresh copy of some tables, whereas finance wants reconciled month-end snapshots with business corrections. A shortcut to supported files in external storage may avoid copying data, but it cannot fix inconsistent source rows. Mirroring may continuously replicate a supported database into Fabric with minimal hand-written ingestion. A pipeline copy or Copy job may be better when the target needs an independent governed snapshot, a different region, or transformations before analysts can use it.
Draw three boxes: source, Fabric item, consumer. Mark the physical location of the authoritative data, each connection identity, any replication process, the transformation stage, and the delay tolerance. If that diagram cannot explain what “fresh” means, the design is incomplete.
A shortcut is an access path, not a transformation pipeline
OneLake shortcuts make data stored elsewhere available within a Fabric item without creating a second physical dataset through that action. In a lakehouse, a shortcut in Tables can surface supported Delta-formatted tables, including in the SQL analytics endpoint where supported; a shortcut in Files makes referenced files available for processing without automatically registering them as a SQL table. This location choice shapes the consumer experience and should be made deliberately.
The identity boundary matters. Internal OneLake shortcuts use the caller’s access to the target. External shortcuts depend on stored cloud connection credentials and the destination item’s access model; permission to the shortcut can therefore be a path to data that would otherwise remain outside the user’s storage account. Review access both at the source connection and the Fabric item. A metadata pointer is not itself a row-filtering security guarantee.
Shortcuts do not provide a guarantee that the upstream source is always reachable, low latency, or compatible with a changing table schema. A schema-breaking change upstream can break a downstream notebook immediately. For important reporting, consider whether a controlled local Delta copy and validation stage is justified.
Database mirroring solves a different ingestion problem
For an eligible database source, mirroring maintains a replicated analytical representation in Fabric. This reduces the need to build manual CDC extraction and update logic, but does not eliminate downstream quality and modeling responsibilities. A business table might be faithfully replicated while still having duplicated customers or unsuitable dimensional grain. Mirrored data is a landing point, not proof of a curated gold layer.
Check the supported source engine, connection requirements, change capture capabilities, unsupported table features, retention and expected lag. A database that merely speaks SQL is not automatically supported by every Fabric mirroring connector. Also account for replication pause or schema changes; establish what a stalled mirror means for downstream dashboards and alerts. If downstream logic requires transformations, use a separate lakehouse, warehouse or notebook stage.
Copy job and pipeline Copy activity are not interchangeable with mirroring
Copy job supports full and incremental movement with managed state for supported watermark and CDC scenarios; after a successful initial load, the job can move changed data rather than all rows. Microsoft’s Copy job documentation explains how its state advances after successful runs. A pipeline’s Copy activity becomes attractive when copying is part of a larger dependency graph: lookups, branching, notebooks, notification and recovery all in one orchestration.
For a batch source with an unreliable modified-date column, a simple timestamp watermark can miss late updates. A better mechanism may use source CDC, a monotonically increasing version, or a periodic reconciliation. Copy job’s managed state is helpful, but the ingestion contract still needs to account for deletes and unexpected source changes. The incremental loading walkthrough explains why replay and watermark advancement must be explicit.
Compare mechanisms against recovery, not only setup effort
| Question | Shortcut | Mirroring | Copy job or Copy activity |
|---|---|---|---|
| Does the operation create an independent target copy? | Not by itself | Yes, via replication | Yes, via movement |
| Where is source freshness determined? | Upstream source | Replication latency/state | Execution cadence and successful run |
| Can a transformation be applied during movement? | No | Not the mirror itself | Copy moves data; downstream transformations may be orchestrated |
| What must operations inspect? | Target availability and credentials | Mirroring status, lag, schema | Run history, copy state, errors, row counts |
These are conceptual defaults, not a claim that every connector supports every operation. A real design decision must check the specific connector and table type.
Test failure using a controlled source outage
Build a simple lab with a supported shortcut and a separate physically copied Delta table. Query both when the source is reachable, then interrupt the source connection in a test environment. The copied target may remain queryable while the shortcut is unavailable; this illustrates the distinction between access path and autonomous dataset. Restore the connection and document whether source schema changes remain compatible.
Next simulate a mirrored-source lag scenario, where finance’s daily close requires all transactions through 23:59. Your operating runbook should show which replication status or watermark proves that boundary, and what the downstream job does if freshness is insufficient. Never label the data “complete” merely because a pipeline reached a success-shaped status.
Security and cost complete the choice
Duplicating data can incur storage, maintenance and governance overhead, but reading external data repeatedly can create its own latency, network cost and external dependency. Security boundaries also differ: OneLake role grants, workspace/item access and source cloud connection permissions all deserve an explicit review. The OneLake security article develops those distinctions.
For DP-700, the durable skill is to classify a requirement as reference, replication or controlled ingestion, then name its freshness, permission, failure-recovery and ownership contracts. That explanation is more useful than memorizing a comparison chart without a workload.