A data engineer sets up mirroring against the archives network's donor-management database so its tables appear in OneLake for analytics. Which statement correctly describes what mirroring provides once it is configured?
Select an answer to reveal the explanation.
Short Explanation
Once it's switched on, mirroring just keeps working in the background. It's a continuous, near-real-time replica of the source tables in OneLake, no schedules to babysit and no ETL code to maintain.
Full Explanation
Mirroring is designed to be a low-maintenance, continuous replication mechanism: once configured against a supported source, it keeps OneLake's copy of the tables current in near real time without the team building or scheduling any custom pipeline logic. This directly matches what's described, mirroring the donor-management database, and is the operational behavior a data engineer should expect after setup. Describing it as a manually triggered, scheduled pull misunderstands the feature entirely; mirroring runs continuously in the background rather than waiting for a manual trigger, which is the opposite of the batch-and-schedule mental model. Describing it as a one-time copy at the moment it was enabled ignores mirroring's defining trait, ongoing replication, and would leave the OneLake copy stale the moment the source changes again. Describing it as a transformation layer that cleanses and conforms data conflates mirroring with silver-layer processing; mirroring replicates the source data essentially as-is into Delta format, it does not perform business-rule cleansing or cross-source conforming, that work still happens downstream in the medallion pipeline. After enabling mirroring, a reasonable operational check is confirming replication lag stays within an acceptable window during peak write activity on the source, since near-real-time is not the same guarantee as truly instantaneous.