Emergency management already stores historical storm CSVs in ADLS and wants Azure Databricks to query them without rewriting the files. Which Unity Catalog object should they create?

When historical storm CSVs already live in ADLS and emergency management does not want a rewrite, create a Unity Catalog external table whose DDL LOCATION points at that existing path. External (unmanaged) tables register cloud storage under Unity Catalog so SQL and governance apply without moving or converting files first. For municipal storm history, that lets analysts start querying immediately while the EOC retains the original landing layout and any upstream agency drop process.

COPY into a new managed Delta table before any query is a valid later promotion step, but it violates the stated constraint of not rewriting files just to enable query. Uploading CSVs as notebook attachments confines access to one notebook, breaks multi-user discovery, and is not a Unity Catalog object for shared emergency analytics. Converting CSVs to JSON in place and ignoring Unity Catalog until a gold model exists delays governance and still does not register a queryable catalog table for storm history.

Exam caveat: external tables do not automatically give Delta ACID semantics if the files remain CSV; plan a silver managed Delta promotion when transactional updates, time travel, or OPTIMIZE matter. Also ensure the external location and storage credentials are registered so compute can read the ADLS path under UC. Operational check: CREATE EXTERNAL TABLE against the storm path, run SELECT LIMIT, confirm the location URI matches ADLS, and verify grants allow emergency analysts without granting them rights to delete the underlying files casually.