Explanation:

The goal is to ensure that a specific user, when connecting from Tableau Desktop, is permanently restricted to seeing only a predefined subset of data. This security filter must be inherent to the data source itself and cannot be something the user can modify or bypass in Desktop.

Here’s why a Data Source Filter is the correct and only robust choice for this scenario:

Embedded in the Data Source Definition: A Data Source Filter is applied at the connection level and becomes a fundamental part of the data source's definition. When this filtered data source is published to Tableau Server, the filter is preserved.

Enforced in Tableau Desktop: When a user in Tableau Desktop connects to this published data source, the Data Source Filter is applied immediately and automatically. The user cannot see, modify, or remove this filter. They can only build workbooks on top of the already-filtered dataset.

Consistency with End-Content Viewers: Because the same published data source is used to create workbooks and is then used by viewers on Tableau Server, the RLS is consistent. Both the content creator (in Desktop) and the final consumer (on Server) see the exact same, security-trimmed view of the data.

Why the other options are incorrect:

B. Context Filter: A context filter is a worksheet-level filter used for performance optimization. It is part of a workbook's specific view and is not part of the data source definition. A user in Tableau Desktop can easily modify or remove a context filter, so it provides no reliable security.

C. Apply Filter to All Using Related Data Sources: This is an action within a workbook that applies a filter across multiple sheets. It is a dashboard interaction feature and has nothing to do with defining a secure data source for publishing.

D. Extract Filter: While an extract filter does create a subset of data, it is applied during the creation of a .hyper extract file. The key distinction is its behavior after publishing:

If you publish an extract to Server, the filter is "baked in" and the user in Desktop would see the subset.
However, the question specifies the user will "create new content in Tableau Desktop." If the user connects to the published data source and creates a new extract locally in Desktop, they could potentially configure the extract filter differently, bypassing the intended security. A Data Source Filter is more secure because it governs both live connections and any extracts created from it on Server.

Key Concept:
Feature: Data Source Filters for Row-Level Security (RLS).
Core Concept: To enforce a data-level security policy that is consistent for both content creators (in Tableau Desktop) and consumers (on Tableau Server), the filter must be applied at the data source level. This embeds the security directly into the connection, making it immutable by the end-user and ensuring it is the foundation for all workbooks built from that data source.

Explanation

The requirement is:
For each quarter, compare its profit against the median profit of the last 4 quarters (including the current one).
Example: For 2020 Q4, the comparison should be against the median of 2020 Q1–Q4.

Why C works:
WINDOW_MEDIAN(expression, 3, 0) looks backward 3 rows and includes the current row.
This creates a 4-quarter window (current + 3 previous).
Tableau then calculates the median profit within that window.

The comparison SUM([Profit]) > WINDOW_MEDIAN(...) determines whether the current quarter’s profit is greater than the median of those 4 quarters.

❌ Why not the others?

A. INDEX(), INDEX() + 3
INDEX() returns the position of the row in the partition.
Using INDEX() in this way does not correctly define a rolling 4-quarter window.

B. FIRST(), FIRST() + 3
FIRST() references rows relative to the start of the partition.
This would always compare against the first 4 rows, not a rolling window.

D. LAST()-3, LAST()
LAST() references rows relative to the end of the partition.
This would only compare against the final 4 quarters, not dynamically for each quarter.

🔗 Reference
Tableau Help: WINDOW Functions
Tableau Best Practices: Rolling Window Calculations

👉 Exam takeaway:
Use WINDOW_MEDIAN with offsets (3,0) to create a rolling 4-quarter comparison window.

Explanation:

This approach correctly separates the two distinct security requirements: Row/Data-Level Access and View/Visualization-Level Access.

Control Data Access (Group 1 vs. Groups 2 & 3):
Group 1 (Viewers who cannot see any information on profitability) must be prevented from seeing any data rows related to profit.
A User Filter (a calculated field using the ISMEMBEROF() function placed on the Filter Shelf) is the standard and most straightforward Tableau method for implementing Row-Level Security (RLS).
The consultant applies a User Filter to the data source that only allows Groups 2 and 3 to see the underlying data required to calculate profit and profit margin. Group 1's data is filtered out entirely.

Control Visibility within the View (Group 2 vs. Group 3):
Group 3 (Viewers who can see profit margin but not the value of profit) must see the aggregated margin but not the component raw profit value.
This is achieved by creating a calculated field for the raw [Profit] measure that only returns a value for Group 2:

IF ISMEMBEROF("Group 2") THEN [Profit] ELSE NULL END

Explanation:

A Sankey diagram is not a native chart type in Tableau.
To build one easily—especially for non-expert users—you use a Viz Extension.

Why Viz Extensions?
Sankey charts require complex data prep (path curves, table calcs, densification).
Tableau Cloud does support sandboxed Viz Extensions.
Tableau Exchange includes Sankey-style extensions such as:
- Sankey Diagram Extension
- Advanced Sankey & Network Graph Extensions

These allow users to drag and drop fields to produce a Sankey without custom calculations, which fits the shipping clerk’s need for a direct and easy workflow.

Therefore, A is correct.

❌ Why the Other Options Are Wrong

B. Use Show Me
Tableau Show Me does NOT include Sankey as a chart type.
Users cannot build a Sankey using Show Me.

C. Download an Accelerator
Accelerators provide prebuilt dashboards, not new chart types.
They do not provide Sankey visualizations unless specifically designed for the dataset.
They do not create custom chart types like Sankeys.

D. Download a Connector
Connectors are used to bring in data from external systems.
They do not create visualizations.

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.