Courseiva

Databricks-DA-Assoc Creating Dashboards and Visualizations Practice Question

An analyst has a Databricks SQL dashboard with a table visualization showing order details, including an order_date column. A stakeholder wants to see only orders from the last 30 days but also wants the ability to change the date range without editing the query. The analyst adds a date-range parameter to the query and a parameter widget to the dashboard. After publishing, the stakeholder reports that changing the parameter does not affect the table. Which action should the analyst take to resolve this?

⚠ Common exam trap

The trap here is assuming the parameter mechanism itself is broken and switching to a different filter type, when the usual cause is that the parameter is not referenced in the query or the dashboard was not refreshed.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Verify that the parameter is referenced in the query's WHERE clause using the correct parameter syntax and that the query was saved and the dashboard refreshed after the change.

For a parameter to affect a visualization, the query must reference it, typically in a WHERE clause, and the dashboard must reflect the saved query version. If the parameter is defined but unused, or the dashboard was not refreshed after saving, changing the widget value will not alter results. Verifying the reference and refreshing addresses the most common causes of this symptom.

Answer analysis

Option-by-option breakdown

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

  • ✓

    Verify that the parameter is referenced in the query's WHERE clause using the correct parameter syntax and that the query was saved and the dashboard refreshed after the change.

    Why this is correct

    A parameter only affects results if the query actually uses it in a filter, such as in the WHERE clause with the correct syntax. If the parameter was defined but not referenced, or the dashboard was not refreshed after saving, the widget will not change the output. Confirming the reference and refreshing the dashboard ensures the parameter is wired to the query and the latest version is published.

  • ✗

    Change the parameter's data type from DATE to STRING so that the date-range selection is passed correctly to the query.

    Why it's wrong here

    Changing the data type to STRING would likely break date comparisons in the WHERE clause, since the query expects a DATE type for order_date. The issue is not the parameter type but whether the parameter is used and whether the dashboard reflects the saved query. Altering the type introduces a new problem rather than fixing the lack of effect the stakeholder observed.

  • ✗

    Recreate the table visualization from scratch and re-add the parameter widget, because parameters only apply to newly created visualizations.

    Why it's wrong here

    Parameters are not restricted to newly created visualizations; they apply to any query that references them, regardless of when the visualization was created. Recreating the table would not fix a missing parameter reference or an unrefreshed dashboard and would waste effort. The actual cause is more likely a query or refresh issue, so this action does not reliably resolve the stakeholder's problem.

  • ✗

    Convert the parameter to a dashboard-level filter by adding the order_date field to the dashboard filters and removing the parameter widget.

    Why it's wrong here

    While dashboard-level filters can filter by date, the scenario describes a parameter that was added but not affecting the table. Switching mechanisms does not address the root cause, which is likely that the parameter is not referenced in the query or the dashboard was not refreshed. This change may also alter the intended viewer experience and does not guarantee the parameter-driven behavior the analyst originally configured.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

One of 291 original Databricks-DA-Assoc practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Databricks exam blueprint

This Databricks-DA-Assoc practice question is part of Courseiva's free Databricks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the Databricks-DA-Assoc exam.