Salesforce-Tableau-Consultant Practice Test Questions

Explanation:

To minimize user impact and costs, the best practice is to consolidate into a single Tableau Cloud instance and use project folders to organize content by department (Finance, Strategy, Marketing).
Here's why this approach is optimal:

Cost-efficient: Tableau Cloud is priced per user and per instance. Using one instance avoids the overhead of managing and paying for multiple environments.
Simplified administration: One instance means centralized governance, permissions, and maintenance.
Project folders: These provide logical separation of content, allowing for department-specific access controls and organization without needing separate sites.

This setup mirrors the multi-site structure of Tableau Server but leverages projects in Tableau Cloud, which is the recommended way to segment content.

❌ Why the other options are less ideal:
B. Two sites + one server: Splitting between Cloud and Server increases complexity and cost. It also defeats the purpose of full migration.
C. Three separate Cloud instances: Expensive and harder to manage. Each instance requires separate licensing, user management, and governance.
D. All workbooks in a single project: Poor organization and access control. It’s harder to manage permissions and maintain clarity across departments.

🔗 Reference:
Tableau Cloud Migration Planning Guide
Organizing Content with Projects in Tableau Cloud

Explanation:

Why it’s correct:
Dynamic Zone Visibility (DZV) lets you conditionally show only the filters relevant to the current parameter selection (shops vs. warehouses).
A Show/Hide Button keeps all filters hidden by default and provides a clean, user-friendly way to reveal them on demand—while still only displaying the applicable ones.

Why not the others:
A. Doesn’t hide filters and forces users to scan scattered controls.
B. “Inform” doesn’t reduce clutter—irrelevant filters still show.
C. Hides all filters but, when shown, still displays irrelevant ones, causing confusion and slower filtering.

Explanation 💡

The client's original calculation, {FIXED [Customer ID]: COUNTD([Order ID])}, correctly calculates the total number of orders for each customer across the entire dataset, regardless of the view's filters or dimensions. This is why the result is higher than expected. When this field is aggregated using AVG over MONTH(Order Date), Tableau is taking the average of these total lifetime orders for all customers who made a purchase in that month, not the average number of orders per customer for that specific month.

To meet the client's expectation of "average number of orders per customer per month, broken down by region," the calculation needs to be rewritten to consider both the month and the region.

The correct approach is to create a calculation that first determines the number of orders per customer within each region. The month-by-month breakdown will then be handled by the view itself.

The formula {FIXED [Customer ID], [Region]: COUNTD([Order ID])} is the key.

FIXED [Customer ID], [Region]: This tells Tableau to calculate the number of distinct orders (COUNTD([Order ID])) for each unique combination of Customer ID and Region. This creates a new column in the data source that contains the total number of orders per customer, scoped to their region.
When this new field is added to the view, which is already broken down by MONTH(Order Date) and Region, the AVG aggregation will correctly calculate the average of these pre-computed values for each month.

Why the other options are incorrect:

A. {INCLUDE [Customer ID]: COUNTD([Order ID])}: An INCLUDE LOD expression includes the specified dimensions in the calculation's granularity while still being affected by the view's filters. While this would consider Customer ID, it would still be aggregated by the dimensions already in the view (MONTH(Order Date) and Region), potentially leading to incorrect or unexpected results because it does not create a fixed, pre-aggregated number of orders per customer. The correct approach is to fix the aggregation at the customer/region level first.
C. {EXCLUDE [Customer ID]: COUNTD([Order ID])}: This calculation would count the distinct orders for each combination of dimensions in the view, excluding Customer ID. This would essentially count the total number of orders for each month and region, which is not what the client wants.
D. {FIXED [Customer ID], [Region], [Order Date]: COUNTD([Order ID])}: This calculation is too granular. It would count the number of orders per customer, per region, per specific order date. Since COUNTD([Order ID]) for a single day would usually be 1 (unless a customer places multiple orders on the same day with different IDs), this calculation would return a value of 1 for most instances, and the average would be around 1, which is not the expected outcome of average orders per customer per month. The correct granularity should be at the customer and region level to count the total orders, and then the view's dimensions (MONTH(Order Date)) should be used to slice the average.

Explanation:

The question asks for a custom dashboard to track data source usage. This requires programmatic access to Tableau's underlying metadata. The standard Admin Insights dashboards are pre-built and not customizable.

B. GraphiQL Engine:
This is an interactive tool within Tableau Cloud/Server that allows admins to explore the metadata schema and build queries for the Metadata API. It is the primary way to design the queries needed for a custom dashboard.
C. Metadata API:
This is the programmable interface that a custom application (like the requested dashboard) would use to automatically retrieve the metadata (e.g., data sources, their connections to workbooks, usage stats) queried via GraphiQL.

Why Others Are Wrong:
A. Admin Insights:
This is a pre-built, static project for admins. It is not a data source you can connect to for building custom dashboards.
D. Tableau Catalog:
Catalog provides lineage and governance features through the UI (like the "Lineage" tab) and the Metadata API, but it is not a direct method for "downloading" bulk metadata for a custom dashboard. The API (option C) is the correct mechanism that powers Catalog's features.

Explanation:

Tableau Server supports version history for published data sources and workbooks. If versioning is enabled, users with appropriate permissions can:

View previous versions
Restore a prior version with a single click
Avoid republishing or manual recreation

This method is the least disruptive and most efficient, ensuring minimal impact on users while preserving metadata, permissions, and connections.

❌ Why the other options are less ideal:
A. Restore a Tableau Server backup: This is a drastic measure that affects the entire server—not suitable for reverting a single data source.
B. Delete and recreate manually: Time-consuming and error-prone. It risks breaking dependencies and losing metadata.
C. Download and republish: Better than B, but still requires manual effort and may disrupt linked dashboards or permissions.

🔗 Reference:
Tableau Version History and Restore

Explanation:

Why:
In Tableau (and most compute engines), operations on simpler, smaller types are cheaper.

Boolean logic is minimal (true/false), so it evaluates quickest.
Integers are numeric and efficient for arithmetic/comparisons.
Strings require more work (collation, length, encoding), so they’re slowest for comparisons/joins/aggregations.

Tip:
When possible, model flags as Boolean or integer keys instead of strings to improve calc, filter, and join performance.

Explanation:

Why:
B. Concurrent extract refreshes: Tableau Cloud has shared backgrounder capacity and scheduling constraints; heavy/concurrent refresh needs may favor Tableau Server (you control hardware and backgrounders).
D. Data storage usage: Tableau Cloud enforces storage limits per site/tenant, while Tableau Server storage is as large as the infrastructure you provision—so current/expected storage footprint is a determining factor.

Why not the others:
A. SSO is supported on both Cloud and Server.
C. Public, cloud-based data sources can be accessed from both; not a deciding factor.

Explanation:

The Performance Recording shows "Executing Query" as the bottleneck. This points to an inefficient filter that forces Tableau to scan a large portion of the extract.

The Problem:
A Relative Date filter (e.g., "Last 3 Months") is a complex, non-indexed filter. To apply it, Tableau must evaluate every single row in the "Created Date" column (containing 5 years of data) to see if it meets the relative condition. This is computationally expensive on a large dataset.
The Solution:
Replacing it with a simple filter on YEAR([Created Date]) is much more efficient. This creates a discrete, integer-based filter that can be optimized by Tableau's query engine, drastically reducing the query execution time.

Why Others Are Wrong:
A. Changing Dropdown to Custom List:
This is a UI change that has no impact on query performance.
C. Replacing TOTAL() with Grand Total:
TOTAL() is a table calculation that computes after the query. It is not the cause of the slow "Executing Query" step.
D. Replacing SUM() with WINDOW_SUM():
WINDOW_SUM() is also a table calculation that operates on the results of the query. It does not affect the initial data retrieval speed.

✅ Explanation

View Acceleration in Tableau Server/Cloud improves performance by precomputing the query results of a view in the background. When a user opens the accelerated view, Tableau loads the pre-fetched, cached data, making the view render significantly faster.
This feature is especially helpful for views with heavy queries, large datasets, or complex calculations.

Why the other options are incorrect
A. Only extract-based sources → ❌
View Acceleration works for both extract and live data sources, as long as the query results can be cached.

C. Rendering speed of visuals → ❌
Acceleration focuses on data retrieval performance, not on graphical rendering like shapes or maps.

D. Long-running queries with transient functions → ❌
Acceleration skips caching for views using non-cacheable, non-deterministic functions (e.g., NOW(), TODAY(), RANDOM(), USERNAME()).

📚 Reference
Tableau Official Documentation — Optimize Workbook Performance > View Acceleration
(Describes background precomputation and caching behavior)