Bronze, silver, and gold layers are widely used in modern data engineering, but the labels are only useful when they describe real contracts. DP-700 candidates should understand why a medallion architecture can improve replay, data quality, and consumer stability in Microsoft Fabric\u2014and also recognize when teams create three layers that simply duplicate the same data without adding value.<\/p>\n
A good medallion design separates source fidelity, engineering trust, and consumer-ready meaning. It should make ownership and recovery clearer, not make the path longer for its own sake.<\/p>\n
Bronze usually captures data close to its source representation, together with ingestion metadata such as arrival time, source identifier, batch ID, and schema version. The purpose is not to make the data pleasant for analysts. It is to preserve enough fidelity to replay transformations and investigate source problems.<\/p>\n
Some validation still belongs at ingestion: a completely unreadable file or corrupt payload may need quarantine. But aggressive business transformation in bronze makes later recovery harder because the original evidence has already been changed.<\/p>\n
The broader data engineering<\/a> role depends on this replay boundary when downstream logic changes.<\/p>\n Silver is where data becomes consistent enough for reuse. Types are normalized, duplicate records are handled, keys are stabilized, invalid rows are quarantined or corrected, and important business entities begin to align across sources.<\/p>\n The exact rules depend on the domain. A customer may need deduplication across CRM and billing systems; telemetry may need unit conversion and late-event handling; finance data may require reference-data validation before it is accepted.<\/p>\n Silver should have a clear quality contract. A consumer should know which problems are already resolved and which ambiguities remain.<\/p>\n Gold structures data for a particular analytical purpose: dimensional models, aggregates, domain data products, feature sets, or other consumer-ready shapes. The design should optimize clarity and performance for the intended audience rather than preserve every source detail.<\/p>\n Different gold products can be legitimate when consumers have different grain or latency. A daily financial mart and a near-real-time operations model might both derive from the same trusted silver entities without forcing one compromise table to serve both.<\/p>\n The data warehouse and data lake<\/a> distinction helps here because gold can be served through a warehouse, lakehouse, or another Fabric experience depending on the workload.<\/p>\n A weak medallion implementation writes bronze, copies it unchanged to silver, and then copies it again to gold. That adds storage, processing, and operational dependencies without improving trust or usability.<\/p>\n Each transition should answer a question. Bronze to silver: what defects or inconsistencies are resolved? Silver to gold: what consumer-oriented model or aggregation is created? If no meaningful contract changes, another physical layer may not be justified.<\/p>\n OneLake and shortcuts can also reduce unnecessary duplication when data can be referenced safely across boundaries.<\/p>\n Source schema changes should not automatically become consumer schema changes. Bronze can preserve new source fields, silver can validate and normalize them, and gold can expose them only when the analytical contract is ready.<\/p>\n This buffer protects downstream products from producer volatility. It also gives engineers a place to compare old and new versions, backfill history, and test how a change affects business rules.<\/p>\n Ownership should be explicit. The source team owns producer semantics, the data engineering team owns curated transformations, and product owners should approve consumer-facing definitions.<\/p>\n Rebuilding every layer from all history can become expensive as the platform grows. Incremental processing needs stable keys, watermarks, or partitions so each layer can update only what changed while preserving correct history.<\/p>\n The challenge is that a change upstream can affect more than one downstream row. Correcting a customer dimension, for example, may require reprocessing facts or aggregates depending on the model. Incremental design therefore follows business dependencies, not only arrival time.<\/p>\nUse silver to establish engineering trust<\/h2>\n
Use gold to serve analytical products<\/h2>\n
Avoid copying data between layers without purpose<\/h2>\n
Design layer ownership and schema evolution together<\/h2>\n
Plan incremental processing across the layers<\/h2>\n