Scenario practice questions

A data analyst is creating a Databricks SQL dashboard to display a single key performance indicator: the total number of active subscriptions for the current day. The value must be prominent and readable at a glance, with no axes or categories. Which visualization type should the analyst choose?

Trap 1: Bar chart

A bar chart is designed to compare values across categories, requiring at least one categorical axis and a measure. For a single KPI with no categories, a bar chart would either show a lone bar or require an artificial grouping, which adds visual noise without benefit. It does not present a single number as prominently as a dedicated single-value visualization, so it is not the best fit here.

Trap 2: Line chart

A line chart is used to show trends over a continuous dimension such as time, connecting data points across intervals. The scenario asks for a single current-day value with no time series or axes, so a line chart would misrepresent the data or require unnecessary date grouping. It is not suited for displaying one scalar KPI prominently at a glance.

Trap 3: Pie chart

A pie chart shows parts of a whole across multiple categories, using slices to represent proportions. A single total subscription count has no subcategories to divide into slices, so a pie chart would be meaningless or would show one full circle. It also does not emphasize a single numeric value as clearly as a single-value visualization, making it inappropriate for this KPI display.

A
Counter
A counter visualization displays a single aggregated value prominently, which is exactly what is needed for a KPI such as today's active subscription count. It has no axes or category encodings, so it presents the number clearly for at-a-glance reading. This makes it the appropriate choice for a single-value dashboard widget focused on one metric without additional dimensions.
B
Bar chart
Why it fails: A bar chart is designed to compare values across categories, requiring at least one categorical axis and a measure. For a single KPI with no categories, a bar chart would either show a lone bar or require an artificial grouping, which adds visual noise without benefit. It does not present a single number as prominently as a dedicated single-value visualization, so it is not the best fit here.
C
Line chart
Why it fails: A line chart is used to show trends over a continuous dimension such as time, connecting data points across intervals. The scenario asks for a single current-day value with no time series or axes, so a line chart would misrepresent the data or require unnecessary date grouping. It is not suited for displaying one scalar KPI prominently at a glance.
D
Pie chart
Why it fails: A pie chart shows parts of a whole across multiple categories, using slices to represent proportions. A single total subscription count has no subcategories to divide into slices, so a pie chart would be meaningless or would show one full circle. It also does not emphasize a single numeric value as clearly as a single-value visualization, making it inappropriate for this KPI display.

Question 2mediummultiple choice

A data analyst has been asked to grant a new team member read access to a specific table named 'customer_orders' in Unity Catalog. The analyst wants to ensure the team member can query the table but cannot see any other tables in the schema. Which SQL command should the analyst use?

Trap 1: GRANT SELECT ON SCHEMA main.sales TO `user@example.com`;

Granting SELECT on the entire schema would allow the user to read all tables within that schema, including 'customer_orders', but also any other tables present. This violates the requirement to restrict access to only the specified table. Schema-level grants are broader and not appropriate when table-level isolation is needed.

Trap 2: GRANT USAGE ON TABLE main.sales.customer_orders TO…

USAGE is not a valid privilege for tables in Unity Catalog; it applies to catalogs and schemas. Granting USAGE on a table would not grant the ability to query data. The correct privilege for reading table data is SELECT, not USAGE. This command would likely fail or have no effect.

Trap 3: GRANT SELECT ON CATALOG main TO `user@example.com`;

Granting SELECT on the entire catalog would give the user read access to all tables in every schema within the catalog, far exceeding the intended scope. This violates the principle of least privilege and does not meet the requirement to limit access to a single table.

A
GRANT SELECT ON SCHEMA main.sales TO `user@example.com`;
Why it fails: Granting SELECT on the entire schema would allow the user to read all tables within that schema, including 'customer_orders', but also any other tables present. This violates the requirement to restrict access to only the specified table. Schema-level grants are broader and not appropriate when table-level isolation is needed.
B
GRANT SELECT ON TABLE main.sales.customer_orders TO `user@example.com`;
This command grants the SELECT privilege on the specific table 'main.sales.customer_orders' to the user. In Unity Catalog, table-level grants are supported and allow fine-grained access control, enabling the user to query only that table without access to other tables in the schema. This directly satisfies the requirement.
C
GRANT USAGE ON TABLE main.sales.customer_orders TO `user@example.com`;
Why it fails: USAGE is not a valid privilege for tables in Unity Catalog; it applies to catalogs and schemas. Granting USAGE on a table would not grant the ability to query data. The correct privilege for reading table data is SELECT, not USAGE. This command would likely fail or have no effect.
D
GRANT SELECT ON CATALOG main TO `user@example.com`;
Why it fails: Granting SELECT on the entire catalog would give the user read access to all tables in every schema within the catalog, far exceeding the intended scope. This violates the principle of least privilege and does not meet the requirement to limit access to a single table.

Question 3mediummultiple choice

Refer to the exhibit. An analyst is reviewing the configuration JSON for a Genie Space. Why is the 'instructions' field critical in this scenario?

Exhibit

{
  "genie_space": "sales_analysis",
  "instructions": "Always join sales_data with region_lookup on region_id.",
  "data_source": "catalog.schema.sales_delta_table",
  "status": "active"
}

Trap 1: It automatically generates a visualization for the user whenever a…

The instructions field provides guidance for the query generation process, not for visualization rendering. Visualizations are typically handled by the Genie interface's internal logic based on the resulting dataset, not by hardcoded instructions in the configuration JSON provided for model guidance.

Trap 2: It forces the user to provide a region ID every time they ask a…

The instructions guide the internal SQL generation logic for the AI engine; they do not explicitly force an interactive prompt for the user to provide specific inputs. The goal is to make the query generation seamless, not to add friction to the user's natural language request process.

Trap 3: It caches the results of the query to improve performance for…

The instructions field does not govern caching mechanisms. Caching in Databricks is managed by the underlying compute environment and the Spark SQL engine, not by the natural language instructions defined for the Genie Space. This field is strictly for guiding the model's SQL generation logic.

A
It automatically generates a visualization for the user whenever a query is run.
Why it fails: The instructions field provides guidance for the query generation process, not for visualization rendering. Visualizations are typically handled by the Genie interface's internal logic based on the resulting dataset, not by hardcoded instructions in the configuration JSON provided for model guidance.
B
It ensures the AI correctly implements the required join logic between the two datasets.
Explicitly stating the join requirements prevents the AI from making assumptions about column relationships. In complex schemas, the model might otherwise choose the wrong column to join on, leading to inaccurate results. This configuration enforces consistent, correct business logic across all user queries within the Genie Space.
C
It forces the user to provide a region ID every time they ask a question.
Why it fails: The instructions guide the internal SQL generation logic for the AI engine; they do not explicitly force an interactive prompt for the user to provide specific inputs. The goal is to make the query generation seamless, not to add friction to the user's natural language request process.
D
It caches the results of the query to improve performance for future users.
Why it fails: The instructions field does not govern caching mechanisms. Caching in Databricks is managed by the underlying compute environment and the Spark SQL engine, not by the natural language instructions defined for the Genie Space. This field is strictly for guiding the model's SQL generation logic.

Question 4mediummulti select

Which TWO of the following scenarios are valid use cases for using the COPY INTO command? (Choose two)

Trap 1: Implementing a continuous streaming pipeline with sub-second…

COPY INTO is not designed for continuous streaming at sub-second latency. It operates as a batch process, even if triggered frequently. Auto Loader is the correct choice for low-latency streaming because it maintains persistent state and uses efficient event notifications to process data as it lands in storage.

Trap 2: Performing complex, multi-stage ELT pipeline orchestration.

COPY INTO is a single-step loading command. It is not an orchestration tool and does not manage multi-stage data pipelines, dependency tracking, or workflow scheduling. For complex orchestration, tools like Databricks Workflows or Delta Live Tables should be used to manage dependencies and task sequencing across the environment.

Trap 3: Ingesting historical data from a database using JDBC connectors.

COPY INTO is specifically designed for file-based ingestion from cloud storage (S3, ADLS, GCS). It does not interact with JDBC connectors. To ingest data from external databases, you must use the Spark read API with a JDBC connector to load data into a DataFrame before writing to Delta.

A
Ingesting data that arrives in files at unpredictable, irregular intervals.
COPY INTO is idempotent, meaning if you run the same command multiple times on the same files, it will not duplicate the data. This makes it perfect for irregular batch uploads where you just want to load everything that has landed since the last successful execution without building streams.
B
Implementing a continuous streaming pipeline with sub-second latency.
Why it fails: COPY INTO is not designed for continuous streaming at sub-second latency. It operates as a batch process, even if triggered frequently. Auto Loader is the correct choice for low-latency streaming because it maintains persistent state and uses efficient event notifications to process data as it lands in storage.
C
Loading CSV files into Delta tables while performing basic transformation.
COPY INTO supports loading data directly into Delta tables from CSV, JSON, Parquet, and Avro files. It also allows for basic column filtering and transformation via a select statement during the load, making it a versatile tool for quick, reliable batch loading tasks in a data warehouse environment.
D
Performing complex, multi-stage ELT pipeline orchestration.
Why it fails: COPY INTO is a single-step loading command. It is not an orchestration tool and does not manage multi-stage data pipelines, dependency tracking, or workflow scheduling. For complex orchestration, tools like Databricks Workflows or Delta Live Tables should be used to manage dependencies and task sequencing across the environment.
E
Ingesting historical data from a database using JDBC connectors.
Why it fails: COPY INTO is specifically designed for file-based ingestion from cloud storage (S3, ADLS, GCS). It does not interact with JDBC connectors. To ingest data from external databases, you must use the Spark read API with a JDBC connector to load data into a DataFrame before writing to Delta.

Question 5mediummultiple choice

An analyst wants to include a chart from a Databricks SQL query in a presentation and also allow stakeholders to explore the same query interactively later. Which two-part approach best fits this need?

Trap 1: Create a separate notebook for each stakeholder and email the…

Emailing notebook files creates divergent copies that quickly become stale and are hard to govern. Stakeholders may also lack the environment to run them. This does not produce a presentation-ready chart and does not provide a shared interactive query, so it does not meet either part of the requirement.

Trap 2: Take a screenshot of the SQL editor and paste it into the slides

A screenshot of the editor shows code rather than a rendered visualization and offers no interactivity. It also becomes outdated as soon as the query or data changes. While quick, it fails to deliver a proper chart for the presentation and cannot support stakeholder exploration, so it is the wrong choice here.

Trap 3: Copy the query text into the presentation slides and ask…

Embedding raw SQL in slides provides no visual and shifts execution burden to the audience, who may lack access or SQL skills. It also risks version drift if the query changes later. This approach fails both the presentation goal and the interactive exploration goal, making it unsuitable for the scenario.

A
Create a separate notebook for each stakeholder and email the notebook files
Why it fails: Emailing notebook files creates divergent copies that quickly become stale and are hard to govern. Stakeholders may also lack the environment to run them. This does not produce a presentation-ready chart and does not provide a shared interactive query, so it does not meet either part of the requirement.
B
Download the chart as an image for the presentation, and share the saved query or dashboard for interactive exploration
Exporting the visualization as an image satisfies the static presentation need, while sharing the saved query or dashboard gives stakeholders a live, interactive view. This combination covers both requirements without duplicating logic. It is the practical Databricks SQL workflow for mixing static and interactive sharing.
C
Take a screenshot of the SQL editor and paste it into the slides
Why it fails: A screenshot of the editor shows code rather than a rendered visualization and offers no interactivity. It also becomes outdated as soon as the query or data changes. While quick, it fails to deliver a proper chart for the presentation and cannot support stakeholder exploration, so it is the wrong choice here.
D
Copy the query text into the presentation slides and ask stakeholders to run it themselves
Why it fails: Embedding raw SQL in slides provides no visual and shifts execution burden to the audience, who may lack access or SQL skills. It also risks version drift if the query changes later. This approach fails both the presentation goal and the interactive exploration goal, making it unsuitable for the scenario.

Question 6mediummultiple choice

A data analyst needs to grant a colleague the ability to run an existing Databricks SQL query and view its results, but the colleague must not be able to edit the query text or change its schedule. The query is saved in the workspace. Which permission level should the analyst assign on the query object?

Trap 1: CAN EDIT

CAN EDIT allows the colleague to change the query text, which violates the requirement that they must not edit the query. It also typically implies broader control, including the ability to alter the schedule or delete the query. This over-privileges the colleague and does not meet the least-privilege constraint described.

Trap 2: CAN VIEW

CAN VIEW allows a user to see the query and its results but does not by itself grant the ability to run the query interactively. The colleague needs to execute the query to get fresh results, so view-only access is insufficient. It also does not clearly separate run permission from edit permission, which is the distinction the scenario requires.

Trap 3: CAN MANAGE

CAN MANAGE is the highest permission level and includes editing, deleting, and changing permissions. It far exceeds what the colleague needs and directly contradicts the requirement that they must not edit the query or its schedule. Assigning it would create unnecessary risk and violate least privilege.

A
CAN EDIT
Why it fails: CAN EDIT allows the colleague to change the query text, which violates the requirement that they must not edit the query. It also typically implies broader control, including the ability to alter the schedule or delete the query. This over-privileges the colleague and does not meet the least-privilege constraint described.
B
CAN VIEW
Why it fails: CAN VIEW allows a user to see the query and its results but does not by itself grant the ability to run the query interactively. The colleague needs to execute the query to get fresh results, so view-only access is insufficient. It also does not clearly separate run permission from edit permission, which is the distinction the scenario requires.
C
CAN RUN
CAN RUN grants the ability to execute the saved query and see its results without allowing edits to the query text or its schedule. This precisely matches the requirement: the colleague can run the query and view output, but cannot modify it. It is the least-privilege permission that still enables the needed action.
D
CAN MANAGE
Why it fails: CAN MANAGE is the highest permission level and includes editing, deleting, and changing permissions. It far exceeds what the colleague needs and directly contradicts the requirement that they must not edit the query or its schedule. Assigning it would create unnecessary risk and violate least privilege.

Question 7mediummultiple choice

A data analyst needs to share a notebook with a colleague who should be able to run the code but not modify it. Which permission level should the analyst grant to the colleague?

Trap 1: Can Manage

Granting 'Can Manage' provides full administrative control, allowing the user to change permissions, delete the notebook, and modify all content. This level of access is far too broad for a user who only needs execution rights and poses a significant security risk to the notebook's stability and integrity.

Trap 2: Can Edit

The 'Can Edit' permission allows a user to modify the notebook's content, add or remove cells, and change the code structure. This level of access exceeds the requirement, as the user should be restricted from making changes, and unintended edits could disrupt the results of the analytical pipeline.

Trap 3: Can View

The 'Can View' permission allows a user to open and read the notebook but does not provide the capability to execute code cells. Since the analyst specifically requires the colleague to run the code, this permission is insufficient to meet the functional requirements of the task at hand.

A
Can Manage
Why it fails: Granting 'Can Manage' provides full administrative control, allowing the user to change permissions, delete the notebook, and modify all content. This level of access is far too broad for a user who only needs execution rights and poses a significant security risk to the notebook's stability and integrity.
B
Can Run
The 'Can Run' permission allows a user to attach the notebook to a cluster and execute its cells. It specifically prevents the user from modifying the notebook's code or changing its settings, making it the appropriate choice for analysts who need to run reports without altering the source data processing logic.
C
Can Edit
Why it fails: The 'Can Edit' permission allows a user to modify the notebook's content, add or remove cells, and change the code structure. This level of access exceeds the requirement, as the user should be restricted from making changes, and unintended edits could disrupt the results of the analytical pipeline.
D
Can View
Why it fails: The 'Can View' permission allows a user to open and read the notebook but does not provide the capability to execute code cells. Since the analyst specifically requires the colleague to run the code, this permission is insufficient to meet the functional requirements of the task at hand.

Question 8mediummultiple choice

A data analyst is modeling a Delta table in Databricks SQL that stores product inventory snapshots. The table has columns snapshot_date (DATE), product_id (STRING), warehouse_id (STRING), and quantity_on_hand (INT). Queries frequently filter on snapshot_date and then join to a product dimension. The analyst wants to minimize the amount of data scanned for date-filtered queries while keeping the table simple and avoiding manual file management. Which approach best achieves this in Databricks SQL?

Trap 1: Convert the table to a view that filters snapshot_date to the last…

A view that restricts snapshot_date to the last 30 days would change the data returned and break historical analysis beyond that window. It also does not reduce scanned data for arbitrary date filters because the view still reads underlying files. This approach alters semantics rather than optimizing storage layout, and it fails the requirement to keep the table simple and complete.

Trap 2: Use Z-ORDER BY on product_id and warehouse_id when writing the…

Z-ORDER clustering improves data skipping for the columns specified, but the scenario's main filter is on snapshot_date. Clustering on product_id and warehouse_id would not efficiently prune files for date-range queries, so scanned data for date filters would remain high. Z-ORDER also requires periodic OPTIMIZE runs, adding maintenance that the analyst wanted to avoid.

Trap 3: Create a Bloom filter index on product_id to speed up date-range…

Bloom filter indexes help with equality lookups on high-cardinality columns like product_id, but they do not provide file pruning for date-range predicates. Date-filtered queries would still scan all files because snapshot_date is not part of the index. This approach does not address the primary access pattern and adds unnecessary complexity without reducing scanned data for the date filter.

A
Convert the table to a view that filters snapshot_date to the last 30 days.
Why it fails: A view that restricts snapshot_date to the last 30 days would change the data returned and break historical analysis beyond that window. It also does not reduce scanned data for arbitrary date filters because the view still reads underlying files. This approach alters semantics rather than optimizing storage layout, and it fails the requirement to keep the table simple and complete.
B
Use Z-ORDER BY on product_id and warehouse_id when writing the table.
Why it fails: Z-ORDER clustering improves data skipping for the columns specified, but the scenario's main filter is on snapshot_date. Clustering on product_id and warehouse_id would not efficiently prune files for date-range queries, so scanned data for date filters would remain high. Z-ORDER also requires periodic OPTIMIZE runs, adding maintenance that the analyst wanted to avoid.
C
Create a Bloom filter index on product_id to speed up date-range queries.
Why it fails: Bloom filter indexes help with equality lookups on high-cardinality columns like product_id, but they do not provide file pruning for date-range predicates. Date-filtered queries would still scan all files because snapshot_date is not part of the index. This approach does not address the primary access pattern and adds unnecessary complexity without reducing scanned data for the date filter.
D
Partition the Delta table by snapshot_date using PARTITIONED BY (snapshot_date) in the CREATE TABLE statement.
Partitioning by snapshot_date lets Databricks SQL prune files for date-filtered queries, reducing data scanned. Because Delta Lake manages partition metadata automatically, the analyst avoids manual file management. This directly matches the scenario's need to minimize scanned data for date predicates while keeping the table simple, and it works with subsequent joins to a product dimension.