A water utility's IoT firmware adds new telemetry fields mid-season. How should the lakehouse team handle schema drift?
Select an answer to reveal the explanation.
Short Explanation
Firmware adding fields is like a meter sprouting a new dial—you want an alert and a plan to wire that dial in, not an auto-merge free-for-all or a season-long quarantine freeze. Don't spin up new table versions and rewrite silver history every firmware change; evolve the schema intentionally.
Full Explanation
Municipal IoT streams commonly drift when water-utility firmware adds telemetry fields mid-season. The lakehouse response is to detect schema drift events, alert operators, and intentionally evolve the ingest contract, bronze/silver schemas, and expectations so new fields are either adopted, staged, or explicitly ignored—never silently lost or accidentally breaking typed consumers. Drift detection plus a controlled evolution plan preserves SCADA continuity while keeping Unity Catalog tables honest about what columns exist and what they mean.
Freezing the bronze schema at the launch firmware version and relegating new telemetry fields to a quarantine table until end-of-season reconciliation lets drift accumulate unseen and delays any intentional schema decision; stakeholders lose visibility into current telemetry and the new fields remain ungoverned for months. Enabling Delta Lake auto-merge on silver tables so additional firmware columns append automatically during scheduled streaming updates treats schema drift as a background plumbing task instead of a managed change, which can silently break typed consumers and bypass operator review. Creating a new Unity Catalog table version for every firmware update and rewriting silver history to backfill new telemetry fields across past seasons fragments the governed catalog and mutates historical telemetry, abandoning stable ACID tables and expectation attachment points.
Exam caveat: auto-merge of unknown columns without review can still break strongly typed silver transforms; detection and alert do not mean blindly widening every table in production without a change window. Operational check: stage a firmware payload with an extra field, confirm a drift alert fires, verify existing columns continue to land, document whether the new field is added to bronze/silver or held in a variant/raw map, and re-run expectations after the intentional schema update.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.