A water utility lands raw IoT sensor files in ADLS and later produces cleansed silver readings for analytics. How should they mix Unity Catalog table types across layers?
Select an answer to reveal the explanation.
Short Explanation
Bronze is the loading dock of raw boxes—you register it as external so the dock stays put. Silver is the cleaned inventory room—managed Delta lets Databricks run that room properly for water-sensor readings.
Full Explanation
A practical medallion mix for the water utility is external Unity Catalog tables for bronze IoT landing files already in ADLS, plus managed Delta tables for silver cleansed readings. Bronze stays registered against the existing landing path so ingest partners and device drops are not forced into a day-one managed rewrite. Silver becomes managed Delta so Databricks owns lifecycle, ACID merges, and governance for analytics-ready sensor readings used by operations and compliance reporting.
Forcing every raw IoT byte into managed tables and deleting the ADLS landing path on day one breaks established landing contracts and is unnecessary for bronze. Leaving both layers as classic Hive with no UC registration abandons governance for regulated utility telemetry. Storing silver only as CSV external tables and skipping Delta forfeits transactional cleansed-layer benefits the silver tier is meant to provide.
Exam caveat: external bronze still needs UC external locations/credentials and appropriate privileges; unmanaged files are not ungoverned if registered correctly. Promotion jobs should write silver managed tables with explicit quality checks before ops dashboards read them. Operational check: register bronze external over the IoT ADLS path, run the cleanse job into managed silver Delta, verify analysts query silver—not raw bronze—for KPIs, and confirm DROP on silver does not delete the bronze landing files.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.