A permits team wants Unity Catalog to reflect medallion layers for permit data under one subject-area boundary. How should they organize objects?

Organize permit medallion layers as separate bronze, silver, and gold schemas under a single permits subject-area catalog. One catalog defines the municipal subject boundary; schemas encode layer (and sometimes domain) so analysts always know whether they are on raw landings, cleansed models, or published metrics. One catalog with bronze/silver/gold schemas keeps navigation predictable without multiplying catalogs or volumes per layer.

One permits schema holding bronze, silver, and gold tables with layer prefixes conflates layers and makes privilege and discovery errors more likely. Creating separate bronze, silver, and gold catalogs for the permits domain multiplies catalog boundaries, complicates governance, and adds unnecessary operational overhead the question does not require. Storing bronze, silver, and gold permits data in separate volumes under one schema bypasses Unity Catalog's governance and schema-level organization, losing layer separation.

Exam caveat: catalog/schema design is organizational—pair it with grants (for example, broader platform MODIFY on bronze, tighter SELECT on gold). Naming conventions should be consistent across civic domains so permits, 311, and utilities look alike. Operational check: create catalog permits with schemas bronze, silver, and gold; place landing, cleansed, and metric tables accordingly; verify three-level names read cleanly; and sample SHOW TABLES IN each schema for the permits team.