Set up and configure an Azure Databricks environment: free practice questions

AI/BI Genie uses Unity Catalog metadata — including table comments, column comments/descriptions, and Genie-specific natural-language instructions — to understand the schema and generate accurate SQL. Adding descriptive comments to columns like `acct_cd` ('account code') and `jrnl_dt` ('journal date'), along with business-context instructions in the Genie space, directly improves LLM grounding. Option A is wrong because creating an aliased view adds maintenance overhead and bypasses the rich metadata layer; it is a workaround rather than the intended Genie configuration approach. Option C is wrong because Photon improves query execution speed but has no effect on the language model's ability to interpret column names or generate accurate SQL. Option D is wrong because over-privileging the service principal is a security anti-pattern and does not improve response quality — Genie's accuracy is driven by metadata enrichment, not broad permissions.

After creating a connection object in Unity Catalog, the next step is to create a foreign catalog using CREATE FOREIGN CATALOG ... USING <connection_name>. The foreign catalog mirrors the remote database's schemas and tables inside Unity Catalog, making them queryable with standard SQL and governed by Unity Catalog permissions. — External tables reference files in object storage, not relational database connections; the connection object cannot be used as a LOCATION credential. — External locations map a storage credential to a cloud storage path (ABFSS/GCS/S3); they are not related to database connections. — Using JDBC directly via spark.read bypasses Unity Catalog governance entirely and does not make the tables visible in the catalog namespace; it also requires manual credential management.

Using separate catalogs for production and development, combined with granting developers privileges only on the `dev` catalog, provides the strongest Unity Catalog-native isolation. Developers cannot traverse `prod` without USE CATALOG on it, enforcing environment separation at the catalog boundary. Using separate schemas within the same catalog provides logical separation but is weaker—a misconfigured permission could leak access across schemas in the same catalog. Unity Catalog does not support explicit DENY statements (unlike some traditional RDBMS systems), so table-level ACLs cannot issue a blanket deny; access is controlled by grants, and the absence of a grant on `prod` is effectively a deny, but this is harder to manage at scale than catalog-level separation. Deploying separate workspaces without Unity Catalog abandons the centralized governance and auditing benefits of Unity Catalog and increases operational overhead.

In Unity Catalog, dropping a managed table removes both the table metadata from the metastore and permanently deletes the underlying data files from the managed storage location. This is the defining characteristic of managed tables — Unity Catalog owns the data lifecycle, so dropping the table also drops the data. — Unity Catalog does not automatically retain managed table data files for 30 days after a DROP TABLE; the deletion is immediate. (Note: Delta table time travel and the underlying Delta log may retain data briefly depending on VACUUM settings, but the table registration and managed ownership are removed.) — There is no restriction preventing managed tables from being dropped; any user with the DROP TABLE privilege can drop a managed table. — While Databricks has introduced some protections for accidental deletion in certain contexts, a standard DROP TABLE on a managed table does not move files to a recoverable trash location with a guaranteed UNDROP window in the general Unity Catalog model.

In Unity Catalog, a schema-level MANAGED LOCATION specifies the default storage path for managed tables created within that schema. When a managed table is created without an explicit LOCATION clause, its data is stored under the schema's managed location rather than the parent catalog's or metastore root's default location. This provides granular storage control at the schema level. — The MANAGED LOCATION is not a reference to a storage credential; storage credentials are separate objects used to authorize access to external locations. — Catalog-level storage locations are used as defaults when no schema-level location is set; a schema-level MANAGED LOCATION overrides the catalog-level default. — Managed tables use the schema or catalog managed location; external tables specify their own LOCATION explicitly and are not affected by the schema's MANAGED LOCATION.