Salesforce-Tableau-Consultant Practice Test Questions

Explanation:

The core issue is performance degradation in a specific workbook. The key detail is that the workbook only uses 37 of the 103 fields available in the data source. Tableau Server processes queries more efficiently when it can work with a smaller, more focused dataset.

Let's analyze why option C is the best practice and why the others are not:

C. Use filters, hide unused fields, and aggregate values. (Correct): This is a fundamental best practice for optimizing Tableau workbooks.
Hide Unused Fields: By hiding the 66 unused fields (103 total - 37 used) from the data source pane within the workbook, you instruct Tableau to ignore these fields during query execution. This reduces the amount of metadata and data Tableau needs to process, leading to faster performance.
Use Filters: Applying context filters or data source filters limits the number of rows of data that need to be fetched and rendered. This is one of the most effective ways to improve performance.
Aggregate Values: Displaying data at a higher level of aggregation (e.g., SUM(Sales) instead of individual transaction records) reduces the data volume that needs to be visualized and speeds up query times.

A. Split some visualizations on the dashboard into many smaller visualizations on the same dashboard. (Incorrect): This would likely decrease performance, not improve it. A single dashboard with many individual visualizations forces the server to execute multiple queries simultaneously when the dashboard loads, increasing the load and potentially slowing down the overall render time.

B. Connect to the data source via a custom SQL query. (Incorrect): While a well-written custom SQL query can sometimes be optimized, it is not the primary best practice in this scenario. The problem isn't the query logic itself but the sheer volume of unused fields being brought into the workbook. A custom SQL query also adds complexity and can be harder to maintain. The simpler, standard approach is to use Tableau's built-in features to hide unused fields.

D. Restrict users from accessing the workbook to reduce server load. (Incorrect): This is not a solution to a performance problem; it is a workaround that undermines the purpose of the workbook. The goal is to improve the workbook's efficiency so it can be used as intended. Restricting access does not fix the underlying technical issue and is not a recommended best practice for performance tuning.

Reference:
This aligns with core Tableau performance best practices, often found in Tableau's official training and documentation under topics like "Optimizing Workbook Performance" and "Best Practices for Efficient Workbooks." The principle of minimizing the data footprint (both rows and columns) is a primary recommendation.

Explanation:

Why it’s correct:
A Sankey visual shows flows across stages (e.g., Freshman → Sophomore → Junior → Senior) with link widths proportional to how many students move from one major to another. It’s designed exactly for path/transition analysis between categorical steps.

Why the others aren’t:
A. Chord Chart: Shows relationships between categories arranged in a circle, not ordered stage-to-stage paths. Better for bidirectional connections than sequential flows. Data to Viz
B. Tree Chart: Displays hierarchical parent-child structure, not many-to-many transitions over grade levels.
C. Radar Chart: Used for comparing multivariate measures on radial axes, not movement between categories.

References:
Tableau (official): “Sankey charts work best when there are multiple inputs and outputs or when there are complex flows and relationships to represent.” Tableau
Tableau Exchange (viz extension): “Sankey Diagram is used to show the flow of data between multiple categories.”

Explanation:

Why it’s correct:
Tableau Catalog (which is included in the Data Management Add-on) provides the features the client wants: data lineage, impact analysis, metadata/data dictionary, curation, and data quality warnings—all across connected sources like data lakes and the Tableau environment.

Why the others aren’t:
A. Tableau Catalog without Data Management Add-on: Tableau Catalog is part of the Data Management Add-on; you don’t get Catalog without it.
C. Tableau Prep Conductor: Used to schedule/monitor Prep flows, not to provide cataloging/lineage for assets.
D. Tableau Catalog with Tableau Server Management Add-on: Server/Advanced Management focuses on security, manageability, scalability—not lineage/collaboration metadata.

Explanation:

Fixed-Sized Layouts within a Single Dashboard: This is the correct and most efficient method. Tableau allows a single dashboard to have different layouts optimized for various devices. When you design a dashboard, you can select 'Device Preview' and then add specific layouts for 'Desktop', 'Tablet', and 'Phone'. This means you only have one workbook to maintain on the server, but each device type gets a custom-tailored view. The fixed size ensures that the layout will appear as designed, without the elements shifting or resizing in a way that could break the user experience.

Why other options are incorrect:
B. Build one dashboard and fix the size of the dashboard: Fixing the size of a single dashboard to, for example, a desktop resolution, will lead to a poor experience on smaller devices like phones. The user would have to zoom and pan to see the content, making it difficult to interact with.

C. Build one dashboard and set the size to Automatic: Setting the size to Automatic tells Tableau to automatically resize the dashboard to fit the screen. While this might seem convenient, it can lead to unpredictable results. Charts may become too small to be readable, text can overlap, and the overall design can break on different screen sizes, especially on phones and tablets.

D. Build one dashboard for each type of device and fix the size of the layouts: This is inefficient. While it could technically work, it creates three separate workbooks (one for each device) that would need to be published and maintained. Any changes to the underlying data or calculations would have to be applied and tested on all three dashboards, which is a major time drain and a source of potential errors. The single-dashboard, multiple-layout approach is the best practice for streamlined development and maintenance.

Explanation:

{ FIXED [Order ID] : SUM([Sales]) } computes total sales per order (independent of the view).
{ FIXED [Region] : AVG( { FIXED [Order ID] : SUM([Sales]) } ) } computes, for each region, the average of those per-order totals.
Comparing them flags orders whose total is greater than the regional average order total—exactly what’s required.

Why others aren’t:
A. Compares row-level [Sales] to per-order totals (mismatch in granularity).
B. Compares per-order total to regional total sales, not the average per order.
D. Uses INCLUDE [Region] (view-dependent) and still averages the same inner value—doesn’t correctly fix the level like C does.

References:
FIXED LODs compute values at specified dimensions, independent of the view.
Overview of aggregation with LODs (how LODs reconcile with the view).

Explanation:

The Workbook Optimizer is a Tableau feature specifically designed to evaluate whether a workbook follows performance best practices. It provides actionable recommendations based on Tableau’s internal guidelines, covering areas like:

Data source usage
Calculations
Dashboard design
Filters and formatting

This tool is ideal for new users or consultants who want to quickly assess and improve workbook performance without manually inspecting every component.

❌ Why the other options are less suitable:
A. Inbuilt dashboards in Tableau Server: These are useful for monitoring server usage and user activity, but they don’t evaluate workbook design or performance best practices.
B. Performance Recording on Tableau Server: This records performance events but is more technical and diagnostic. It’s better suited for troubleshooting specific slow interactions, not general best practice evaluation.
C. Performance Recording in Tableau Desktop: Similar to option B, this helps analyze performance bottlenecks but doesn’t provide structured best practice feedback like the Workbook Optimizer does.

🔗 Reference:
Tableau Workbook Optimizer Overview

Explanation:

Why it’s correct:
Tableau Catalog (part of the Data Management add-on) lets you see end-to-end data lineage, impact analysis, external assets (databases, tables, fields), data quality warnings, and metadata. That visibility is exactly what you need to diagnose why multiple published data sources—pointing at the same underlying tables—are producing different answers (e.g., different joins, filters, extracts vs. live, field definitions).

Why the others aren’t:
A. Tableau Prep Conductor: Schedules/monitors Prep flows; it doesn’t provide cross-source lineage/impact analysis.
B. Ask Data: Natural-language querying of a data source; it doesn’t explain discrepancies between data sources.
D. Resource Monitoring Tool: Monitors server performance/health, not data lineage or source differences.

Explanation:

The key requirement is to identify Saturday and Sunday regardless of the workbook's data source's locale settings. The challenge is that the standard 'weekday' datepart in many systems, including Tableau, can be locale-dependent, meaning which day is considered the first day of the week (Sunday or Monday) can change.

Let's analyze the options:

Why B is Correct: The 'iso-weekday' datepart uses the ISO 8601 standard, which is locale-independent. In this standard:
Monday = 1
Tuesday = 2
Wednesday = 3
Thursday = 4
Friday = 5
Saturday = 6
Sunday = 7
Therefore, the calculation DATEPART('iso-weekday', [Order Date]) >= 6 will correctly return True for both Saturday (6) and Sunday (7) on any machine, in any locale. This perfectly meets the client's requirement.

Why the Other Options are Incorrect:

A. DATEPART('weekday', [Order Date])>=6: This uses the standard 'weekday' datepart. The behavior of this function depends on the data source's locale settings. In a U.S. locale, Sunday is considered the first day of the week (value 1), so Saturday would be 7. In this case, >=6 would catch Saturday (7) and Sunday (1? No, Sunday is 1, so it would be missed). This logic would fail. In a locale where Monday is the first day, it might work, but it is not reliable and violates the "regardless of locale" requirement.

B. DATENAME('iso-weekday', [Order Date])>=6: This is syntactically and logically flawed. DATENAME() returns a string (e.g., "Saturday", "samedi"), not a number. Comparing a string to the number 6 ("Saturday" >= 6) is invalid and will not work.

C. DATEPART('iso-weekday', [Order Date])=1 or DATEPART('iso-weekday', [Order Date])=7: This uses the correct 'iso-weekday' datepart but applies the wrong logic. As explained above, in the ISO standard, Monday is 1 and Sunday is 7. This calculation would flag Monday (1) and Sunday (7), which is not what the client wants. They specifically asked for Saturday and Sunday.

Reference & Key Concepts:
DATEPART() vs. DATENAME(): DATEPART() returns an integer, while DATENAME() returns a string. For numerical comparisons like finding a weekend, you must use DATEPART.

ISO 8601 Standard: This is an international standard for date and time representations. Its definition of the week (Monday as day 1) is critical for creating portable, locale-independent calculations.

Locale Dependence: Always be cautious of locale settings when working with dates. Functions that rely on a system's default first day of the week can produce different results when a workbook is opened in a different country. Using the 'iso-' prefix is the best practice to avoid this.

For your exam, remember that 'iso-weekday' is the key to solving any problem that requires a consistent, locale-independent definition of weekdays.

Explanation:

This scenario involves a high-volume transactional data source with:

Daily additions (new transactions added nightly)
Weekly corrections (incorrect transactions revised every Saturday)
Daily reporting needs (users need fresh data every day)
To balance performance and data accuracy, the best practice is:
Incremental extract refresh daily: Efficiently adds new data without reloading the entire dataset.
Full extract refresh weekly (Saturday): Ensures that corrected transactions are reflected in the data.
This approach minimizes server load while ensuring data integrity and freshness.

❌ Why the other options fall short:
B. Live connection: Not ideal for millions of rows; can cause performance issues and strain the database.
C. Incremental refresh every Saturday: Misses daily updates; users won’t see new transactions until Saturday.
D. Incremental refresh + secondary dataset: Overcomplicates the architecture and introduces maintenance challenges. A full refresh is simpler and more reliable for handling corrections.

🔗 Reference:
Tableau Extract Refresh Strategies
Best Practices for Publishing Data Sources

Explanation:

Option A:
A filter action on "Select" filters the table to show only orders for the clicked Sub-Category, reducing rows rendered from 10,000+ to a subset. "Exclude all values" when clearing selection keeps the table empty by default, minimizing load time and ensuring fast rendering.
Option B:
Highlight action on Sub-Category still renders all 10,000+ rows, only highlighting relevant ones, so no performance gain.
Option C:
Highlight action on All Fields also renders all rows, offering no speed improvement.
Option D:
Filter action on "Menu" is less intuitive, and "Show all values" when clearing selection renders all 10,000+ rows, slowing the dashboard.

Option A optimizes performance by limiting data rendered, aligning with Tableau best practices.

Reference:
Tableau Dashboard Actions