Creating Dashboards and Visualizations practice questions

Hardcode the date ranges directly inside the visualization editor to prevent users from accidentally querying large partitions of the underlying sales table.

Why it fails: Hardcoded date ranges remove the parameterisation the scenario demands, so users cannot filter dynamically and every range change needs manual editing. This would be acceptable for a one-off fixed-period report, not for a dashboard serving variable stakeholder selections.

Export the raw revenue dataset into local browser memory and build JavaScript-based time-series filters within a custom HTML visualization card.

Why it fails: Browser-side aggregation bypasses Databricks SQL warehousing, so dynamic filters cannot push down predicates to the underlying tables and the full dataset must be transferred. It would suit a small static dataset, not an aggregated revenue trend needing efficient warehouse execution.

Create separate static dashboards for every possible date combination required by different department stakeholders across the organization.

Why it fails: Static dashboards cannot respond to user selections at query time, so each date combination requires separate maintenance and no dynamic filtering occurs. This suits fixed executive reporting where parameters never change, not the interactive filtering the scenario requires.

Grant the user 'Can Edit' permissions on the dashboard.

Why it fails: Granting 'Can Edit' permissions provides broader access than necessary and violates the principle of least privilege. Users only need to view the dashboard and trigger refreshes, not modify the dashboard structure, layout, or underlying queries, which is what the 'Can Edit' permission level permits users to perform.

Enable the 'Run as owner' credential setting.

Why it fails: The 'Run as owner' setting ensures the dashboard queries execute with the permissions of the user who created them. This allows viewers to trigger refreshes and see updated data based on the owner's access rights, effectively decoupling the viewer's personal database permissions from the dashboard's operational data visibility requirements.

Share the dashboard using a personal access token.

Why it fails: Personal access tokens are designed for programmatic access and API authentication, not for end-user dashboard interaction. Using them for this purpose is a significant security risk and does not align with Databricks workspace sharing features, which are managed through standard permission settings within the platform interface.

Only the queries based on 'query_result' will be affected.

Why it fails: The exhibit shows that the 'date_filter' uses a 'global_parameter', not the 'query_result' source. Only the 'region_filter' is linked to 'query_result'. Therefore, the 'date_filter' applies globally across the dashboard, affecting all widgets configured to listen to this specific parameter, regardless of their individual data sources.

The filter will only update the visualization that created the filter.

Why it fails: Global parameters in Databricks dashboards are designed to be shared across multiple widgets. If the filter was meant to only affect one visualization, it would not be defined as a global parameter. The purpose of this configuration is to provide a unified filtering experience for the entire dashboard.

The filter will cause an error because the source is not defined.

Why it fails: The source is clearly defined as 'global_parameter' in the provided JSON snippet. This is a valid configuration for a dashboard filter in Databricks. There is no missing information that would trigger an error during the filter application process, as the system recognizes 'global_parameter' as a legitimate type.

Hard-code the width and height of all widgets in pixels.

Why it fails: Hard-coding dimensions in pixels creates a rigid layout that breaks on smaller screens. Widgets will either be cut off or require excessive scrolling, providing a poor user experience. Modern dashboard design requires flexible, relative sizing that adapts to the viewport dimensions of the device being used by the viewer.

Place all visualizations in a single vertical column.

Why it fails: While this ensures the content fits on a screen, it often leads to an extremely long page that requires significant scrolling. This obscures the 'at-a-glance' value of a dashboard. A multi-column grid layout is far superior for organizing information efficiently and ensuring that the most important insights are seen first.

Create separate dashboards for desktop and mobile users.

Why it fails: Maintaining multiple versions of the same dashboard is inefficient and error-prone. It doubles the workload for the analyst whenever updates are needed. The best approach is to leverage the platform's native responsive design capabilities to serve a single, unified dashboard that works seamlessly across all common device types and sizes.

Users with 'Can View' access can modify the underlying SQL queries of the dashboard widgets.

Why it fails: The 'Can View' permission is restricted to consuming and interacting with the dashboard, such as applying filters or refreshing the data. It does not grant the rights to modify the underlying SQL queries, ensuring that the dashboard's logic and business definitions remain consistent and secure from unauthorized tampering.

Dashboards automatically inherit all permissions from the underlying Delta tables in the Unity Catalog.

Why it fails: Dashboard permissions are distinct from data object permissions. While a user needs access to the underlying data to see results, dashboard permissions are managed separately at the workspace/artifact level. This separation of concerns allows for flexible access control where a user might see a summary dashboard without direct table access.

Only users with the Workspace Admin role can view dashboards created by other users.

Why it fails: Sharing is a fundamental capability in Databricks. Any user with 'Can Manage' or the owner of the dashboard can grant access to specific users or groups regardless of their administrative status. Limiting view access only to admins would render the collaborative nature of Databricks dashboards entirely ineffective for organizational business intelligence.

On the dashboard, use the visualization's menu to add a dashboard-level filter for the region field, then set the product-mix visualization to listen to that filter so it refreshes when the region changes.

Why it fails: Dashboard-level filters apply to all visualizations that share the same underlying dataset or field, but they do not create a click-driven cross-filter from one specific chart to another. They also affect every widget using that field, which may unintentionally filter unrelated charts. This approach is broader than the requested behavior and does not implement a targeted selection interaction between the two specific charts.

On the bar chart, open the visualization settings and enable the option that lets selections in this chart filter other widgets, then configure the product-mix query to use the region field as a dashboard parameter.

Why it fails: While Databricks SQL dashboards support cross-filtering via dataset fields, the described steps conflate two mechanisms. Cross-filtering is driven by shared dataset fields and the dashboard's filter configuration, not by a per-chart toggle plus a parameter. Adding a parameter to the product-mix query does not wire the bar chart's click to that parameter, so the product-mix chart would not update from the selection as intended.

Configure the product-mix query to include a parameter, then add a parameter widget to the dashboard and manually change its value whenever a region is selected.

Why it fails: A parameter widget requires the viewer to manually pick a value from a dropdown; it does not react to a click on a bar in another visualization. While parameters can filter queries, they are not driven by chart selection, so the product-mix chart would not update automatically when the stakeholder clicks a region. This adds manual steps and does not meet the requested interactive behavior.

Create a new query that computes percentages with a window function, then add it as a separate visualization.

Why it fails: Although a window function can compute percentages, this requires writing a brand-new query, which the scenario explicitly says to avoid. The existing query result already contains the category totals needed for a parts-of-a-whole view, so duplicating the visualization is simpler and meets the stated constraint. This approach adds unnecessary work.

Change the existing bar chart's Y-axis to a percentage scale, which converts the bars into percentage-of-total values automatically.

Why it fails: A bar chart's Y-axis can be formatted as a percentage, but that only changes how the existing values are labeled; it does not recompute each category as a share of the total. The bars would still represent absolute sales values. This does not produce a true percentage-of-total breakdown, so it fails the requirement.

Add a counter visualization for each category, since counters display a single value that can be formatted as a percentage.

Why it fails: Counters show one value each, so you would need many counters to cover all categories, and a counter does not compute a category's share of total automatically. This approach is cumbersome and does not present the categories as parts of a whole in a single chart. It is not the appropriate solution here.

Pie chart

Why it fails: A pie chart represents parts of a whole across categorical segments, so continuous transaction amounts would need arbitrary binning first. It suits proportional breakdowns by category, not the shape, spread or skew of one continuous numerical variable.

Line plot

Why it fails: A line plot connects points in sequence, implying an ordered or temporal x-axis, which misrepresents unordered transaction amounts. It suits trends over time, whereas distribution of one continuous variable requires binning values into a histogram.

Scatter plot

Why it fails: A scatter plot encodes two numerical variables as x and y positions, so a single variable has no second axis to plot against. It suits correlation or relationship analysis between paired measures, not the frequency distribution of one continuous field, which a histogram shows.

Change the chart type to a scatter plot.

Why it fails: Changing to a scatter plot will likely increase visual clutter because it displays every individual data point as a distinct marker. This approach fails to address the underlying issue of data density and makes it even harder to identify trends, as points will likely overlap significantly on the screen.

Filter the dataset to only include the last seven days.

Why it fails: Filtering to a one-week window obscures the long-term context requested by the requirement of viewing sales trends over the past year. While it cleans up the chart, it sacrifices the primary analytical goal of comparing performance across different seasons and quarters, rendering the dashboard less useful for strategic planning.

Increase the chart size to fill the entire screen width.

Why it fails: Increasing the physical dimensions of the chart does not resolve the density of the data points. The chart will still contain the same number of overlapping points, meaning the underlying issue of visual complexity remains unresolved despite the larger display area provided to the end-user for their analysis.

Convert all visualizations into a single complex query.

Why it fails: Combining all visualizations into one complex query often creates a bottleneck. If one part of the query is slow, the entire dashboard stalls. It is generally better to use separate, optimized queries for each visualization so that the SQL warehouse can execute them in parallel and cache them individually.

Add more users to the dashboard to increase processing power.

Why it fails: Adding more users does not increase the processing power or compute resources assigned to a SQL warehouse. In fact, increasing user concurrency without scaling the warehouse size can lead to resource contention, causing the queries to run slower due to wait times within the serverless or pro warehouse environment.

Switch the dashboard to manual refresh mode only.

Why it fails: While manual refresh prevents background processing, it does not improve the performance of the query itself when the user actually triggers it. The user still experiences the slow load time. Performance improvements must come from optimizing the execution plan or utilizing caching, not simply deferring the execution time.

Pie Chart

Why it fails: Pie charts are intended for showing parts of a whole for categorical data, not the distribution of a continuous variable. Using a pie chart for continuous data like age would require arbitrary binning and result in a poor representation that fails to show the underlying frequency distribution.

Line Chart

Why it fails: Line charts are designed to show trends over time or ordered categories. They connect individual points to show sequence and direction, making them inappropriate for illustrating the statistical distribution of a single variable, as there is no temporal or sequential relationship between age groups in a distribution.

Scatter Plot

Why it fails: Scatter plots are used to show the relationship between two different variables. While you could plot age on one axis, it would not effectively display the frequency distribution of age alone. It would simply show individual points, failing to highlight the density or frequency patterns clearly.

Hard-code the security logic into the SQL queries.

Why it fails: Hard-coding security logic into queries is prone to error and difficult to maintain. It violates best practices for centralized access management. Instead, Databricks provides robust identity and access management (IAM) features at the workspace level that should be used to control data access securely and consistently.

Export the dashboard as a PDF and email it to the team.

Why it fails: Exporting to PDF creates a static, insecure copy of the data. Once emailed, the analyst loses control over who can see the information and cannot ensure the data is up-to-date. This approach undermines the security features of the Databricks platform and risks unauthorized data dissemination.

Make the dashboard public and add a password to the title.

Why it fails: Making a dashboard public exposes the data to anyone with the link, regardless of a password in the title. This is a severe security vulnerability. Access must always be managed through the official Databricks workspace permission settings, which authenticate users before granting any access to the content.

Define the visualization type in the SQL query code.

Why it fails: Visualization types are selected via the UI, not defined in the SQL query. The SQL query simply retrieves the data; the transformation into a chart, graph, or table happens at the visualization layer within the dashboard editor, keeping the logic and the presentation layers distinct and maintainable.

Upload a CSV file containing the final report data.

Why it fails: Uploading static CSV files is not how interactive dashboards work. Dashboards should be connected to live data sources in the SQL warehouse to ensure that the information shown is always up-to-date. Using static files defeats the purpose of an interactive, real-time analytics environment provided by the Databricks Lakehouse.

The widget type is set to 'line' instead of 'bar'.

Why it fails: Choosing 'line' versus 'bar' is a stylistic choice and does not inherently make a trend 'incorrect'. While some trends are better shown with one type than the other, the type setting alone does not cause a calculation or data display error in the underlying values of the trend line.

The X-axis for widget 2 is not properly aligned to the date range.

Why it fails: The exhibit explicitly shows that widget 2 is configured with the 'date' X-axis. Unless there is a data quality issue in the source table, the X-axis configuration itself is valid. If the trend is wrong, the issue likely lies within the query logic or the aggregation method.

The 'revenue' column is incompatible with the 'line' chart type.

Why it fails: Revenue is a numerical value, which is perfectly compatible with line charts. Line charts are actually the preferred visualization for revenue trends over time. There is no technical incompatibility between a numerical metric and a line chart that would lead to an incorrect trend display in this context.

Alerts

Why it fails: Alerts are designed to notify users when a specific query result meets a defined condition (e.g., 'sales fall below $1000'). They are not intended for sending scheduled snapshots of a full dashboard. They serve a different purpose, focusing on proactive monitoring rather than general report distribution.

Query Snapshots

Why it fails: While snapshots are part of the process, 'Query Snapshots' is not a formal feature name in Databricks for scheduled delivery. The functionality for scheduling is managed through the subscription service, which handles the rendering of the dashboard and the distribution to the specified email recipients on the defined cadence.

Data Refresh Jobs

Why it fails: Data refresh jobs manage the execution of queries to update the underlying cache or materialized views. They do not have the built-in capability to format a dashboard as a visual report and email it to stakeholders. The subscription service is specifically responsible for the email delivery aspect of this task.

Heatmap

Why it fails: Heatmaps are best for identifying patterns in large matrices or density distributions. They are less effective for direct, side-by-side comparison of specific categorical values. While a heatmap can show trends, it is not the standard choice when the primary goal is a simple, precise comparison between two categorical values.

Bubble Chart

Why it fails: Bubble charts represent data using circle sizes, which makes them very difficult to compare precisely. Human perception is poor at comparing the area of circles, leading to inaccurate conclusions. This makes bubble charts a poor choice for simple side-by-side comparisons where accuracy is the primary goal for the analyst.

Stacked Area Chart

Why it fails: Stacked area charts are designed for visualizing the total volume of several variables over time. They make it very difficult to compare the values of the individual categories themselves because the baseline for each segment above the first one changes constantly, hiding the true magnitude of each category's contribution.

It permanently changes the data in the underlying table.

Why it fails: Parameters are used for filtering or customizing SELECT queries at runtime. They have absolutely no impact on the underlying data. Any suggestion that a parameter could modify table contents is fundamentally incorrect, as SQL queries for dashboards are inherently read-only operations designed to protect data integrity and prevent unauthorized changes.

It forces every user to run the exact same query.

Why it fails: Parameters do the opposite; they allow each user to customize the execution of the query based on their specific needs, such as selecting a different date range or category. This flexibility is what makes dashboards useful for a wide audience with varying analysis requirements, rather than a rigid, one-size-fits-all report.

It creates a copy of the database for each user session.

Why it fails: Creating a database copy for every user session would be extremely resource-intensive and is not how Databricks operates. Parameters simply pass values into the query execution context, which is an efficient, standard practice for filtering datasets that does not involve duplicating or creating any additional storage resources.

Alerts only function if the dashboard is currently open.

Why it fails: Alerts are independent of the dashboard interface. They run on a schedule defined in the background, regardless of whether a user has the dashboard open or not. This is exactly why they are effective for monitoring, as they can catch issues in real-time without requiring constant manual oversight.

Alerts automatically delete data that triggers the condition.

Why it fails: Alerts are strictly for monitoring and notification purposes. They do not have the permissions or the functionality to delete, modify, or perform any write operations on the underlying data. Their role is to observe and report, ensuring that the integrity of the data lakehouse remains strictly protected.

Alerts are only compatible with Python-based notebooks.

Why it fails: Alerts are a core feature of Databricks SQL, which uses SQL queries as its primary interface. They do not require Python-based notebooks to function. Any query saved in the SQL editor can be used as the basis for an alert, provided it returns results in a format the alert can evaluate.

Add a trend line to the chart.

Why it fails: Trend lines show the general direction of the data, but they do not highlight specific instances that exceed a certain threshold. While useful for high-level analysis, a trend line will not draw attention to individual data points that violate a specific business rule or threshold, failing the requirement.

Change the chart type to a pie chart.

Why it fails: A pie chart is entirely unsuitable for time-series data or threshold monitoring. It cannot represent the chronological sequence of error counts and would make it impossible to see if the errors occurred on specific days, let alone highlight those days that exceeded a threshold of 50 errors.

Filter out all days with fewer than 50 errors.

Why it fails: Filtering the data removes the context entirely. The user would lose visibility into the normal error counts, which is often important for comparison. Highlighting the values is superior to deleting the rest of the data, as it keeps the full story intact while still identifying the critical anomalies.

Manually refresh the dashboard every morning.

Why it fails: Manual processes are prone to human error and inconsistency. If the analyst forgets, the data remains stale. Automation is the standard for professional reporting environments in Databricks, as it ensures consistent updates without requiring human intervention, leading to higher reliability and trust in the dashboard's data.

Re-run the SQL queries in a notebook and export the results.

Why it fails: This approach is inefficient and creates a disconnect between the data processing and the visualization layer. It requires manual steps that can be automated within the dashboard itself. Using the built-in dashboard scheduler is significantly more scalable and maintainable than running notebook-based exports for reporting purposes.

Ask the SQL warehouse to stay running indefinitely.

Why it fails: Keeping a SQL warehouse running indefinitely is a waste of compute resources and money. It does not actually trigger the refresh of the dashboard itself. Scheduling is about the timing of the query execution, not the state of the warehouse, which should be managed by auto-stop settings.