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.