An open-data portal must read published gold tables while only engineering may write them. How should Unity Catalog privileges be separated?
Select an answer to reveal the explanation.
Short Explanation
Readers and writers need different badges: the portal service principal gets SELECT on gold, engineers keep MODIFY. Handing the portal OWNER on every layer is how published datasets get overwritten by accident.
Full Explanation
Privilege separation for an open-data portal means the portal service principal receives SELECT on published gold tables while MODIFY remains with the engineering group. Readers and writers get different badges: the portal can serve published civic datasets; engineers alone reshape pipelines and gold contents. That prevents accidental or malicious overwrite of published municipal gold through the portal identity.
Giving the portal OWNER on bronze, silver, and gold lets a read-oriented system rewrite pipelines and landings—far beyond portal needs. Allowing anonymous Internet users to MODIFY gold through Unity Catalog is an indefensible exposure. Removing all grants and embedding table data in static HTML nightly abandons governed live reads and creates stale, ungated copies.
Exam caveat: SELECT on gold does not imply access to bronze or silver; keep medallion privileges layered for municipal publication. OWNERSHIP transfers and broad MODIFY should be change-controlled. Operational check: grant the portal SP SELECT only on approved gold tables, verify portal queries succeed, attempt a write as the portal SP and expect failure, confirm engineering group retains MODIFY, and review SHOW GRANTS during release.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.