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:

1. Open the workbook
Launch Tableau Desktop on the VM.
Open the file named CC.twb(x) on the desktop.
Open the worksheet Categorical Sales.

Part 1 — Compute Average Sales by Segment (per Category and Year)
Step 1: Build the basic view
Drag Category to Rows.
Drag Year(Order Date) (discrete, blue YEAR) to Rows to the right of Category.
Drag Segment to Columns.
Drag Sales to Text (Marks card).
This creates a crosstab of Sales by Category → Year → Segment.

Step 2: Convert Sales to Average Sales
You need a table calculation to compute average sales by segment per category and year.
Right-click the SUM(Sales) pill.
Select Quick Table Calculation → Average
(or manually create a calculated field if instructions require).
Important: If the instructions expect an explicit calculation instead of the quick table calc:
Create a new field:
WINDOW_AVG( SUM([Sales]) )
Then set Compute Using → Segment or Table Across depending on layout.
The value should now show average sales per segment for each Category + Year.

Part 2 — Compute YoY % Change of the Average Sales
Now you must compute year-over-year % change of that average sales table calculation.

Step 1: Create the YoY Calculation
Create a new calculated field:
Calculation: YoY % Change
Then set Compute Using → Segment or Table Across depending on layout.
The value should now show average sales per segment for each Category + Year.

Step 2: Create the YoY Calculation
Create a new calculated field:
Calculation: YoY % Change
(SUM([Sales]) - LOOKUP(SUM([Sales]), -1))
/
LOOKUP(SUM([Sales]), -1)
If you used WINDOW_AVG before, the YoY calc becomes:
(WINDOW_AVG(SUM([Sales])) - LOOKUP(WINDOW_AVG(SUM([Sales])), -1))
/
LOOKUP(WINDOW_AVG(SUM([Sales])), -1)

Step 2: Add the calculation to the view
Drag the new YoY % Change field onto Text (replace the existing value).
Right-click the field → Edit Table Calculation.

Step 3: Set Compute Using
Set Compute Using → Table Down (or Year) so the calculation compares each row’s year with the previous year.
You should now see YoY % change values for each Category × Segment.

3. Replace the Original Measure
The instructions say:
“Replace the original measure with the year-over-year percentage change in the crosstab.”
You have already done this by replacing the Text field with YoY % Change.

4. Save the Workbook
Go to File → Save.
You’re done.

Final Answer (Short Form)
Use a table calculation for average sales (WINDOW_AVG), then create a second table calculation using LOOKUP() to compute year-over-year % change, set the table calculation direction to Table Down, place it on the crosstab, and save the workbook.

✅ Explanation
If a customer already uses row-level security (RLS) inside their database, Tableau Cloud can leverage that same RLS only when using a live connection and only if the database can authenticate/identify the Tableau Cloud user.

To reuse existing database-level RLS, two requirements must be met:

✔ A. The Tableau Cloud username must exist in the database.
Correct.
Database-level RLS typically relies on a field such as username, email, or user ID to filter data. For Tableau Cloud to pass the user identity correctly, the database must recognize the user.

This is usually done via:
- SAML / OAuth passthrough
- Initial SQL (passing USERNAME() into the DB)
- Database mapping tables using Tableau username/email

✔ C. Only live data connections can be used.
Correct.
Tableau Cloud cannot embed database-managed RLS into extracts, because extracts store data after the security filter is applied.

To reuse database-side RLS:
You must use live connections so the database can apply security at query time.

❌ Why the others are incorrect
B. Both live and extract connections can be used.
Incorrect—extracts cannot leverage dynamic database RLS.

D. The RLS in database option must be configured in Tableau Cloud.
Incorrect—there is no such setting in Tableau Cloud.
RLS is defined and enforced in the database, not in Tableau Cloud.

Explanation:

The core of this problem is understanding the difference between how Table Calculations and Level of Detail (LOD) Expressions are evaluated in Tableau's order of operations.

Table Calculations: These are computed last, on the result set of the query that is already in the view (the "cached" data). They are dependent on the specific dimensions present in the view and are directly affected by any filters (except context filters) that reduce that result set. When you filter out a category, the "total" used in the Percent of Total table calculation recalculates based on the remaining visible categories, causing the percentages for the remaining items to shift and readjust to 100%.

FIXED LOD Expressions: These are computed during the query to the data source, at the same time as dimension and measure filters are applied. A FIXED LOD expression can define its own scope independently of the view.

Here’s why a FIXED LOD expression is the solution:
Independent Calculation of Total: The consultant can create a calculated field that defines the grand total of sales, ignoring any filters on Category.
// Calculated Field: Total Sales (Fixed)
{ FIXED : SUM([Sales]) }

Steady Denominator: The percent of total for each category can then be calculated as:
// Calculated Field: Steady Percent of Total
SUM([Sales]) / [Total Sales (Fixed)]

Impact of Filtering: Because the { FIXED : SUM([Sales]) } calculation is locked to the grand total of the entire dataset, it remains constant no matter which categories are filtered in or out of the view. The percentages for the visible categories will now be based on this unchanging denominator, so they will not readjust to 100% when other categories are hidden.

Why the other options are incorrect:
❌ A. Filter Category by using a Context Filter instead of a Dimension Filter. While a Context Filter does change the order of operations (it runs first and creates a new "context" for the data), it does not solve this problem. A Percent of Total table calculation is still computed on the result set after the context filter. If you filter out categories with a context filter, the table calculation's total will still be based only on the remaining categories, causing the percentages to readjust.

❌ B. Filter Category by using a Data Source Filter instead of a Dimension Filter. A Data Source Filter is the very first filter applied and restricts the data available to the entire workbook. This is the most permanent type of filter. It would permanently remove the categories from the dataset, but it doesn't help the calculation; it just makes the problem permanent. The table calculation would still recalculate its total based on the filtered data source.

❌ C. Create an aggregate expression, and then use that instead of the table calculation. A simple aggregate expression like SUM([Sales]) is still view-dependent. To get a percent of total, you would still need to divide by something. If you divide by the total of the visible view, you have the same problem. This option is too vague and does not provide a mechanism to create a steady, view-independent total.

Key Concept:
Core Concept: Level of Detail (LOD) Expressions vs. Table Calculations.

Key Takeaway: Use a FIXED LOD expression when you need to compute a value (like a grand total) that is independent of the dimensions and filters in the view. This is the standard solution for creating a "steady denominator" in percentage calculations that should not be affected by filtering within the view.

Explanation

The original calc mixes a row-level test with an aggregate inside the IF:
IF YEAR([Date])=2010 THEN COUNTD([OrderID]) END
This causes an aggregate/non-aggregate mismatch and, even if coerced, returns the same aggregated count on multiple rows rather than restricting the set being counted.
The correct pattern is to apply the condition inside the argument to the aggregate, so the aggregate only operates over the qualifying values:
COUNTD(IF YEAR([Date])=2010 THEN [OrderID] END)
For non-2010 rows, the IF returns null; COUNTD ignores nulls and counts distinct OrderIDs only for 2010.

Why the other options are incorrect
A. IF MIN(YEAR([Date]))=2010 THEN WINDOW_COUNTD([OrderID]) END
Introduces a table calculation (WINDOW_COUNTD), which depends on the view’s partitioning/addressing and is unnecessary here. It also mixes aggregate/table calc logic with a row-level condition, leading to fragile or incorrect results tied to the layout rather than the data.

B. IF YEAR([Date])=2010 THEN {COUNTD([OrderID])} END
The LOD {COUNTD([OrderID])} ignores the row-level condition and computes over the LOD’s scope, not just 2010. Additionally, this mixes row-level condition with an LOD aggregate inside IF, which is semantically wrong for restricting the counted set.

D. COUNT(IF YEAR([Date])=2010 THEN [OrderID] END)
Uses COUNT (non-distinct), which will count all qualifying rows, not distinct orders. The requirement is distinct orders, so COUNTD is necessary.