Databricks-DA-Assoc Managing Data Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  CREATE MATERIALIZED VIEW main.sales.high_value AS SELECT * FROM main.sales.orders WHERE total_amount > 1000;

  Why it's wrong here

  A materialized view stores precomputed results and must be refreshed to reflect changes in the base table, so it does not automatically pick up future updates. It also requires a Databricks SQL warehouse with serverless or pro configuration and is intended for expensive aggregations, not simple row filtering. For a lightweight, always-current filter, a standard view is the appropriate choice.

• ✓

  CREATE VIEW main.sales.high_value AS SELECT * FROM main.sales.orders WHERE total_amount > 1000;

  Why this is correct

  A standard CREATE VIEW stores only the SQL definition, and each query re-executes it against the base table, so results always reflect the latest committed data. This matches the requirement for a live, filtered projection without storage or refresh overhead. The view inherits access through the base table, so the analyst needs SELECT on the orders table.

• ✗

  CREATE TEMPORARY VIEW main.sales.high_value AS SELECT * FROM main.sales.orders WHERE total_amount > 1000;

  Why it's wrong here

  A temporary view is scoped to the current session or notebook and disappears when the session ends, and it cannot be created with a three-part Unity Catalog name. It therefore cannot serve as a persistent, shareable object for other analysts. The requirement implies a durable object usable across sessions, which a temporary view cannot satisfy regardless of its refresh behavior.

• ✗

  CREATE OR REPLACE VIEW main.sales.high_value AS SELECT * FROM main.sales.orders WHERE total_amount > 1000 WITH SCHEMA EVOLUTION;

  Why it's wrong here

  WITH SCHEMA EVOLUTION is a clause for table operations such as CREATE TABLE AS SELECT and MERGE, not for defining a view. Including it in a CREATE VIEW statement produces a syntax or analysis error. Even if it parsed, schema evolution governs how new source columns are absorbed during writes, which is irrelevant to a read-only filtered view.