Databricks-DA-Assoc Creating Dashboards and Visualizations Practice Question
An analyst is preparing a Databricks SQL dashboard for an executive review and needs to ensure the numbers shown are trustworthy and reproducible. The analyst wants to document the data lineage and make the dashboard resilient to schema changes in the source tables. Which TWO actions should the analyst take? (Choose two.)
⚠ Common exam trap
The trap here is assuming that more frequent refreshes or broader permissions improve trustworthiness, when the real drivers are version-controlled SQL and explicit, fully qualified table references.
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
✓
Use fully qualified three-level namespace names such as catalog.schema.table in the dataset query.
Trustworthy, reproducible dashboards depend on a versioned, reviewable source of SQL and on unambiguous object references. Storing the query in a Git-backed workspace folder provides history and peer review, while using fully qualified catalog.schema.table names makes dependencies explicit and guards against silent redirection when defaults change. Together these practices support lineage documentation and resilience, unlike refresh tuning, type coercion, or over-permissive grants.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Convert every numeric column to a string in the query so formatting is consistent.
Why it's wrong here
Casting numbers to strings breaks numeric aggregation and sorting, and it prevents the visualization from applying correct axis scales or number formats. It also obscures the true data type in lineage information rather than clarifying it. This action would make the dashboard less trustworthy, not more, and does nothing to protect against upstream schema changes.
- ✓
Use fully qualified three-level namespace names such as catalog.schema.table in the dataset query.
Why this is correct
Referencing tables with their full catalog.schema.table names removes ambiguity about which object is being read, especially in a Unity Catalog environment with many similarly named tables. It makes the dependency graph explicit for lineage tools and reduces the chance that a session default schema change silently points the query at a different table. This improves resilience against schema and workspace reorganizations.
- ✗
Grant the dashboard viewers CAN MANAGE permission on the underlying tables.
Why it's wrong here
Viewers only need permission to run the shared query or to view the dashboard; granting CAN MANAGE on source tables violates least privilege and increases the risk of accidental schema changes. It also does not document lineage or make the pipeline more resilient. Security hardening is valuable, but this specific grant is the opposite of what a well-governed executive dashboard should do.
- ✓
Create the visualizations from a saved Databricks SQL query that is stored in a Git-backed workspace folder.
Why this is correct
Saving the SQL as a named query and storing it in a Git-backed workspace folder gives the dashboard a versioned, reviewable source of truth. Reviewers can see exactly which SQL produced each number, changes are tracked in commits, and the query can be re-used across dashboards. This directly supports reproducibility and lineage documentation, which is what the executive review requires.
- ✗
Enable the dashboard's scheduled refresh to run every minute.
Why it's wrong here
Refresh frequency controls how often results are recomputed, not whether the query is correct or traceable. A one-minute schedule increases compute cost and load on the warehouse without adding any lineage documentation or protection against schema changes. It could even mask problems by repeatedly returning stale-looking results. It does not address the analyst's stated goals of trustworthiness and reproducibility.
About these practice questions
Courseiva writes every Databricks-DA-Assoc question from scratch — 291 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
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.