A housing authority needs one top-level Unity Catalog boundary to hold all resident-services schemas. What object should they create first?

A housing authority that needs one top-level Unity Catalog boundary to hold all resident-services schemas should create a Unity Catalog catalog first. In UC’s catalog.schema.table model, the catalog is the top-level container; schemas for resident-services domains hang under it, then tables/views/volumes. Creating the catalog is the correct first object for that municipal boundary.

A Unity Catalog share that will contain the resident-services schemas is not the top-level boundary—a share cannot hold schemas as a namespace; shares are Delta Sharing objects for sharing data with external recipients, so you must create the catalog first before any resident-services schemas can exist. A Unity Catalog metastore that will contain the resident-services schemas is not the object to create here—a metastore contains catalogs, not schemas directly, and is an account-level boundary assumed to already exist, while the housing authority needs the catalog as the top-level resident-services boundary under it. A Unity Catalog external location that will hold the resident-services schemas is incorrect—an external location manages storage credentials and paths for storage access, but it is not a namespace boundary and cannot hold schemas.

Exam caveat: order of operations is typically metastore (account/region) → catalog → schema → tables/volumes. Most exam questions assume the metastore exists and ask for the next top-level boundary: catalog. Do not create a second metastore per department when a catalog suffices. Shares are not top-level namespace boundaries for schemas—they are Delta Sharing objects for sharing with external recipients.

Operational check: create the resident-services catalog in Unity Catalog, grant ownership to the housing data stewards group, create schemas beneath it, and only then register tables and row filters as needed.