A medallion lakehouse can be readable yet incorrect if raw and curated layers do not preserve the meaning and provenance of records. In a fictional logistics feed, bronze retains duplicate event deliveries, silver reconciles them using an event identity and permitted correction policy, and gold presents a stable business total. Add a late correction, a malformed timestamp and a large set of tiny Delta files; decide which failure needs reprocessing, which is a validation defect and which is physical maintenance. OPTIMIZE may reduce file-layout overhead, but VACUUM manages retention and must not delete files still required for recovery or an approved investigation. When reviewing independent DP-700 practice questions about lakehouse operations, check whether the explanation preserves the business data contract, distinguishes compaction from file retention, and proves the recovery window with evidence. The linked offering is third-party preparation, not Microsoft’s official exam or evidence that a Fabric maintenance job was executed.

Imagine a fictional parcel service with three inputs: raw scan events, daily tracking corrections and reference information about delivery depots. The business needs a report of delivered parcels by region and a defensible response when a package scan is disputed. A medallion design can make that easier, provided bronze, silver and gold are defined by evidence quality and business responsibility rather than by the number of tables drawn on an architecture slide.

Define bronze, silver and gold by their contracts

Microsoft’s medallion architecture guidance describes bronze as raw data, silver as cleansed or enriched data and gold as curated output. The distinction matters because each stage has a different reason to exist. Bronze preserves source records and arrival context. Silver establishes validated types, identities and standardization. Gold presents the measures and dimensions that reporting or downstream services can use.

In the parcel example, bronze contains the original scan payload and a source file identifier. Silver resolves event timestamps, validates the parcel ID, removes invalid duplicate deliveries according to an agreed rule and quarantines malformed records. Gold computes completed deliveries and service metrics for a reporting period. This avoids treating a raw ‘delivered’ event as the final state when a later correction says the package was returned to sender.

A design should be able to answer whether every gold measure can be traced to the silver records and original source identity. If an assertion cannot be reconstructed after a correction, the team may have cleaned away evidence too early. Keep transformation version and provenance through the layers, and define a reprocessing mechanism that does not blend historical source versions unpredictably.

Choose workspace and engine boundaries for each layer

Fabric can use separate lakehouses, a combination of lakehouse and warehouse, or other supported OneLake storage patterns for a medallion design. Microsoft describes designs with each layer in its own lakehouse or bronze and silver in lakehouse storage followed by a warehouse gold layer. The right selection depends on the team’s use of Spark, T-SQL, security boundaries, refresh needs and consumer expectations. The gold layer is a serving contract, not a mandate that every output must use the same engine.

Separate workspaces can help govern boundaries at scale. A raw-input engineering workspace may have stronger write rights for ingestion services and fewer human readers. A curated workspace may expose only approved serving tables. Sharing everything through one broad workspace role can erase much of the security value of staging layers. Pick boundaries that represent real ownership and access needs rather than creating unnecessary resource sprawl.

Treat OneLake shortcuts carefully. A shortcut can make source data available without a full copy, but it does not cleanse or verify the data or make the source available forever. The choice between OneLake shortcuts and mirroring affects data duplication, freshness and operational responsibility. In a medallion design, the additional question is where an immutable or versioned record must be preserved for repeatable downstream transformation.

Write curated Delta tables without losing source identity

Fabric lakehouse tables commonly use Delta Lake, which combines Parquet data with a transaction log. That allows supported transactional operations and historical versioning, but it does not make business transformation logic infallible. A Delta write that commits wrong values is still a wrong result. Use stable keys and validation rules, and keep a record of which source batch or event set the transaction represents.

A silver transformation should separate parsing errors from business rule failures. If a timestamp is malformed, the record may require quarantine. If two scans refer to the same package at different times, they may both be legitimate events rather than duplicates. If a correction arrives after the reporting period closes, the workflow needs a restatement or adjustment policy. Handling incremental and late-arriving data loads requires explicit restatement and recovery rules; the focus here is how layers and table maintenance support the resulting physical data.

Document the quality acceptance for each layer: expected type, nullability, unique key, source age, allowed duplicate behavior and rejected fraction. A gold table should have a business definition for every metric and should cite the input version or window. That lets a failed audit reproduce the result without treating a single dashboard value as the sole source of truth.

Recognize small files, skew and scan inefficiency

Repeated micro-batch writes can produce many small Parquet files. Each file adds metadata and scanning overhead, so query performance can degrade even if total data size changes little. A skewed partition can make one Spark task much slower than its peers, while a poorly chosen predicate can force an expensive scan. Diagnose which problem is present before adding compute or changing every table’s partition strategy.

Use measurement before and after a representative optimization. Record the query, input distribution, file count, latency and CPU or capacity context. A short scan against a tiny synthetic table may not demonstrate the benefit of compaction, and an overly aggressive layout change can make writes slower without improving the queries that matter. The right optimization depends on both readers and writers.

Microsoft’s Delta table guidance explains Fabric’s maintenance and default behavior, which has changed by runtime and workspace creation date. Avoid copying an old configuration example into a new environment without checking the currently effective Spark settings. A valid performance experiment needs the actual runtime and workload characteristics recorded.

Use OPTIMIZE and V-order for different physical effects

OPTIMIZE compacts data files and can improve scan efficiency. V-order is a Parquet write-layout optimization that can benefit read-heavy analytics, often with extra write work. Microsoft’s V-order guidance notes that V-order is disabled by default in newly created Fabric workspaces, with settings that can be controlled at supported session, table or write levels. Do not assume V-order is always on or always desirable.

For the parcel service, a gold aggregate queried repeatedly by dashboard users may justify testing V-order, whereas a fast-updating bronze table may prioritize write throughput. Compare the same read query and ingest workload before and after the change. If reads improve but ingestion time exceeds the business deadline, the tradeoff might be unacceptable. Keep the optimization targeted rather than impose the same setting across all bronze, silver and gold tables.

V-order and Z-order answer different layout questions and can be complementary where supported. A practitioner should understand their purpose without promising a universal speedup. Any benchmark should include cold and warmed behavior appropriately and report the selected filter and data distribution. The output needs to remain correct, not merely fast.

Treat VACUUM as retention management, not query tuning

The Fabric VACUUM documentation states that VACUUM removes files no longer referenced by the Delta log when they are older than the configured retention interval. Its principal effect is storage cleanup. It is not the same as compaction or file-layout optimization, and running it does not automatically improve a query that is slow because of skew or bad filtering.

The usual default retention is seven days. Reducing that period can remove files needed for time travel, concurrent readers or recovery from a bad write. Do not use a zero-hour or very short retention simply to make a workspace storage metric look better. The parcel service may need to reconstruct yesterday’s mistaken delivered count, so maintenance needs to respect the business’s recovery window as well as the storage bill.

Before any cleanup, decide which old table versions must remain accessible and identify concurrent readers, replay jobs and recovery obligations. In Fabric Spark SQL, VACUUM schema_name.table_name DRY RUN can list files proposed for removal without deleting them; verify the command against the actual Fabric runtime and table context. Record maintenance timing so it does not collide with an active replay or reader relying on older files. If retention must be shortened, perform a risk review and test affected jobs; do not disable the seven-day safety check as routine practice.

Recognize deletion vectors and cleanup sequencing

Supported Delta operations can use deletion vectors to mark rows removed without immediately rewriting all affected files. That can improve write behavior while leaving physical cleanup for a later step. Microsoft’s Delta guidance distinguishes REORG, OPTIMIZE and VACUUM: one can rewrite affected active data, one can improve layout and one removes obsolete unreferenced files after retention. These operations should not be described as interchangeable cleanup buttons.

Suppose a parcel event was wrong and a correction removes it from a silver table. The logical query result can be correct while the older file remains available for historical recovery. Whether the system must physically remove sensitive content is a separate retention and legal question. A data engineer needs to understand the dependency and validate the expected result after maintenance, especially if deletion vectors or concurrent writes are involved.

A practical maintenance calendar records the table’s size, update rate, concurrent consumers, recovery window, compacted file sizes and cost impact. Assign a human owner who can stop a potentially destructive maintenance job when downstream tests fail. Blindly scheduling aggressive cleanup across every table creates risk without demonstrating improved service quality.

Design a controlled medallion and maintenance exercise

Build an entirely fictitious dataset with duplicate parcel scan events, one late correction, a depot lookup and an invalid timestamp. Preserve original source identity in bronze; validate and quarantine in silver; derive a documented on-time-delivery metric in gold. Repeat the same input and confirm that totals do not change unexpectedly. Then update one late source record and show which derived values must be restated.

Measure a chosen gold query before and after a supported OPTIMIZE operation on a sufficiently representative synthetic table, and capture the real file and query metrics if a tenant is available. Investigate whether V-order belongs on that table without asserting guaranteed gains. Test retention in a nonproduction setting and record how far back a version can be queried after cleanup. Keep the data small and safe enough to repeat.

For DP-700, the end-to-end answer is not ‘bronze, silver, gold’ followed by a command list. It is a defensible design where raw evidence survives, transformations are reproducible, serving tables represent agreed meaning and physical maintenance respects performance and recovery requirements. If you cannot execute the lab in Fabric, clearly mark run-time outcomes NOT TESTED rather than turning an illustrative design into a claimed benchmark.