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:

The dashboard is slow because the dataset contains 3 years of timestamp-level interaction data, and usage has grown substantially in the last 6 months.
Even though they are using a Tableau extract, that extract still contains millions of granular timestamp rows, which Tableau must aggregate every time the dashboard loads.

The consultant needs to:
- Improve performance
- Without changing the dashboard design
- Without extra cost
- And without altering which product features are visualized

✔ Why D is correct
Tableau Prep is included in the Tableau Creator license, so it adds no additional cost.

Using Tableau Prep to:
- Aggregate raw timestamp rows → daily product-level rows
- Output a clean, aggregated extract to Tableau Server / Tableau Cloud
- Retain the same visual structure in the dashboard (daily granularity)

This results in:
- Far fewer rows in the extract
- Much faster dashboard performance
- No change to the dashboard experience
- No added software cost

This matches all requirements.

❌ Why the other options are wrong

A. Add extract filters to limit the number of product features visualized
Reduces visible data → changes functionality
The question states they need least impact to the visualization
Not acceptable

B. Invest in an ETL tool to aggregate the data
The question explicitly says without additional cost
Buying an ETL tool violates that requirement

C. Decrease extract refresh to once a day
Does not improve dashboard performance
Only changes data latency
The extract still contains 3 years of detailed records

⭐ Summary
To speed up a dashboard built on massive timestamp data:
- Aggregate upstream
- Reduce row count
- Keep the same daily visuals
- Avoid extra cost

➡️ Correct Answer: D. Leverage Tableau Prep to aggregate the data to the daily product level.

Explanation:

Requirements:
Dashboard is shown on big screens in command centers.
Needs to keep updating automatically (no human clicking Refresh).
Data source is already a real-time (live) connection.
Environment cannot access the internet (so no Tableau Exchange / cloud services).

So the problem isn’t refreshing the data (it’s already live), it’s refreshing the view in the browser.

Why A works
Using the Tableau JavaScript / Extensions API in a small internal web app, you can:

- Embed the dashboard.
- Call refreshDataAsync() or reload the viz on a timer (e.g., every 60 seconds).
- Host this web page on the company’s internal web server (no internet needed).
- Point the command-center screens to this internal URL.

That gives hands-off, automatic, up-to-date dashboards.

Why the others don’t meet the requirement

B. Schedule a prep flow
Prep flows refresh / reshape data, not the displayed dashboard. Also unnecessary with a live connection.

C. Download a sandboxed extension from Tableau Exchange
Tableau Exchange requires internet access, which this environment does not have.

D. Switch to extracts and schedule refreshes
That changes from real-time to batch, and still doesn’t auto-refresh the browser view of the dashboard.

So the best solution is to embed the dashboard in a custom web app that uses the Extensions/JS API to refresh it on a schedule — Option A.

Explanation:

Tableau's built-in geocoding can automatically recognize standard geographical fields like State and City. However, it does not natively geocode exact street addresses (like "101 Random Place Rd" or "57 Alphabet St") to specific latitude and longitude coordinates, which are necessary for precise plotting.

Custom Geocoding: The consultant must use an external service or tool (like a geocoding API or a custom script) to translate the combination of Street Address 1, Street Address 2, City, and State into unique Latitude and Longitude values.

The resulting Latitude and Longitude fields would then be brought into the Tableau data source and assigned the Geographic Role (Latitude/Longitude), allowing the consultant to plot the exact store locations on the map.

Why Other Options Are Incorrect:

B. Change the data type of Street Address 1 and Street Address 2 to the Geographic role.
Incorrect. Assigning a geographic role to a string field like Street Address 1 only tells Tableau that the data represents a geographic location. It does not perform the translation (geocoding) of the street address text into usable latitude/longitude coordinates, which is the missing piece of data.

C. Establish a hierarchy of State > City > Street Address 1 > Street Address 2.
Incorrect. Creating a hierarchy helps with drilling down into the data, but it does not add the necessary latitude and longitude coordinates required for mapping the exact street addresses.

D. Add a Map layer to the visualization.
Incorrect. Adding a map layer (e.g., in recent Tableau versions) allows you to overlay different sets of marks (like stores and driver routes), but it does not solve the fundamental problem of the data lacking the coordinates needed to locate the Street Address on any map layer.

📚 References
Tableau Help: Custom Geocoding

Tableau's documentation guides users to custom geocode when they have location data (like street addresses or custom territories) that is not automatically recognized by the default map server, necessitating external data preparation to obtain latitude and longitude coordinates.

Explanation:

Why B and D Are the Correct Causes

Tableau Server and Tableau Cloud generate workbook and view URLs using this structure:
https://.../site-name/#/site/site-id/project-name/workbook-name/views/view-name

When a dashboard is republished:

Option B (different project) → The /project-name/ segment in the URL changes (e.g., from /Sales to /Marketing). All old bookmarks instantly break because the project path is now invalid.
Option D (new name) → The /workbook-name/ segment changes (e.g., from /SalesDashboard to /SalesDashboard_v2). The old URL no longer resolves to any workbook, so bookmarks fail.

These are the two most common and well-documented reasons bookmarks break after a republish.

Why the Other Options Are Incorrect

A. New credentials were embedded into the data source.
Embedding or changing credentials affects authentication and data access, but it does not change the URL of the workbook or view. Bookmarks continue to work (users might be prompted to re-authenticate at worst).

C. Tableau Server was upgraded.
A server upgrade does not alter project names, workbook names, or content IDs. Existing URLs remain valid across version upgrades (this is a core Tableau compatibility guarantee).

References
Tableau Help → “Why do bookmarks break after republishing?” (official KB article): explicitly lists “Published to a different project” and “Published with a different workbook name” as the primary causes.

Tableau Community → “Broken bookmarks after republish” (top-voted thread since 2018): 99 % of cases are project or name changes.

Tableau Server REST API documentation → Workbook and View URLs are built from project LUID + workbook LUID + view LUID; only moving projects or renaming workbooks changes the friendly URL path.