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:

The problem is that a standard "Percent of Total" table calculation recalculates based on the data present in the view. When you filter the view by [Region], the total changes, and therefore the percentage for the remaining region becomes 100%.

To fix this, you need a calculation that defines both the numerator and the denominator independently of the view's filters.

Numerator: {FIXED [Region]: SUM([Sales])}
This calculates the total sales for each region, regardless of any filters applied to the view (except for context filters and extract filters). It gives you a fixed sales number for "Central," "East," etc.

Denominator: {FIXED : SUM([Sales])}
This is a grand total LOD. It calculates the sum of sales across the entire dataset, fixed at the database level. It ignores all filters in the view (except context/extract filters), so it will always return the same total number.

The Result: Dividing the fixed regional sales by the fixed grand total gives you a true, static percentage of the overall total for each region. This percentage will not change when you apply a filter to the [Region] field because both parts of the calculation are computed against the full, unfiltered dataset.

Why the Other Options are Incorrect:
A. {FIXED [Region]: SUM([Sales])} / SUM([Sales]): The denominator SUM([Sales]) is a measure that is still dependent on the view's filters. If you filter the view to one region, the denominator becomes the sales for that one region, making the calculation Regional Sales / Regional Sales = 100%. It does not solve the problem.

B. {FIXED [Region]: SUM([Sales])} / { [Sales] }: This is syntactically incorrect. { [Sales] } is not a valid LOD expression. LOD expressions require an aggregation function like SUM, AVG, etc.

D. {FIXED [Region]: SUM([Sales])}: This only calculates the total sales per region. It does not perform the percentage calculation at all, so it cannot fix the percent of total problem.

Reference & Key Concepts:
FIXED LOD Expressions: Compute values using the specified dimensions, ignoring all other dimensions and filters in the view (with the exception of Context Filters and Data Source Filters).

Order of Operations: LOD expressions are computed after data source filters but before most other types of filters. This is why they can be used to "lock in" a value that is immune to view filters.

Use Case for Grand Total LOD ({FIXED : ...}): Creating key performance indicators (KPIs) or percentages that should always be relative to the entire dataset, not the filtered view.

For the exam, remember that when you need a percentage of total that should not recalculate when a dimension is filtered, you must use a FIXED LOD for both the numerator and the denominator. The denominator must be a grand total LOD ({FIXED : SUM([Measure])}) to remain constant.

Explanation:

The provided dataset contains monthly average high and low temperatures (e.g., January to May), not daily temperature readings. To create a line graph showing daily fluctuations, the consultant needs actual daily data points, not monthly aggregates.

✅ Why B is correct:
The current data lacks the granularity needed for daily visualization.
You cannot interpolate or simulate daily fluctuations from monthly averages without introducing assumptions.
The most accurate and actionable approach is to request a dataset that contains daily temperature values (e.g., one row per day with high/low temps).

❌ Why not the others?

A. Pivot the data
Pivoting would restructure columns (e.g., turning "Avg High Temp" and "Avg Low Temp" into rows), but it does not create daily granularity.
Pivoting is useful for reshaping, not for increasing temporal resolution.

C. Create a Level of Detail (LOD) calculation
LOD expressions aggregate data, not generate finer granularity.
You cannot use LOD to fabricate daily data from monthly averages.

🔗 Reference
Tableau Help: Granularity and Aggregation
Tableau Community: Visualizing Daily Trends from Aggregated Data

👉 Exam takeaway:
When the required visualization demands finer granularity than the source data provides, request a more detailed dataset.

Explanation:

Why Explorer Is the Correct (and Lowest-Cost) Choice

The managers need three specific capabilities:

- View dashboards – supported by all roles
- Create Data-Driven Alerts – supported by Explorer and higher (Viewer cannot create alerts)
- Perform ad hoc analysis on existing published data sources (create new workbooks from published data sources, save them to the server) – supported by Explorer and higher

Explorer (sometimes called Explorer (can publish) when the site setting is enabled) is the only role that delivers all three requirements while being significantly cheaper than Creator.

Viewer → can view and subscribe to alerts but cannot create Data-Driven Alerts nor build/save new workbooks
Explorer → can do everything the managers need
Creator → overkill and typically 3–4× the price of Explorer
Site Administrator → unnecessary administrative privileges and even more expensive

In most Tableau Cloud/Server pricing tiers (2024–2025), Explorer costs roughly $35–42/user/month versus $70–100+/user/month for Creator, making it the clear choice when the goal is minimizing licensing costs.

Why the Other Options Are Incorrect

A. Viewer
Cannot create Data-Driven Alerts (only subscribe to existing ones) and cannot create or save new workbooks → fails two of the three requirements.

B. Creator
Works perfectly but is the most expensive option and unnecessary since the managers only need to work with existing published data sources, not build new data sources or use Prep.

C. Site Administrator
Grants full administrative rights (user management, site settings, etc.) — far beyond what is needed and extremely costly/insecure.

References:
Tableau Pricing & Roles (2025): Explorer explicitly listed as able to “Create and publish content from existing data sources” and “Create and manage data-driven alerts”.
Tableau Help → Data-Driven Alerts: “Explorers and Creators can create alerts; Viewers can only subscribe.”
Tableau Blueprint → Role Minimization: “Assign Explorer (not Creator) when users only need ad hoc analysis on published data sources and alerting.”

Answer: D – Explorer is the only role that meets all functional requirements at the lowest possible licensing cost.

Explanation:

Why Tableau Public?

The client wants:

- Interactive Tableau visualizations embedded on a public website
- Data is small (< 5,000 rows) and updated infrequently via manual refresh
- Cost is a priority

Tableau Public is:

- Free
- Designed specifically for public-facing, embeddable visualizations
- Well-suited for small datasets and manual refresh workflows
- Perfect when there is no requirement to keep the data private (all workbooks on Tableau Public are publicly accessible)

So Tableau Public meets all requirements at no additional cost.

Why not the others?

A. Tableau Cloud licensed per user
Licensing is per user, which becomes expensive if the visualization is public (unlimited viewers).
Better for secure, authenticated internal use, not open public websites.

C. Tableau Embedded Analytics
Typically involves enterprise-level licensing and is intended for authenticated, integrated experiences.
Overkill and more costly for a small, infrequently updated public viz.

D. Tableau Server licensed per core
Requires infrastructure + core-based licensing = most expensive option.
Not appropriate when cost is a priority and Tableau Public satisfies requirements.

✅ Use Tableau Public (B) to publish and embed the dashboard on the public website at minimal cost.