- Which data-modeling approach most responsibly supports the analysis while reducing the risk of duplicated revenue?
Answer: Relate Orders and Shipments as logical tables using the applicable order-line keys, preserving their separate levels of detail.
Whenever you see a question about combining tables with mismatched granularity — one row per order line versus multiple rows per order line — your first instinct should be to think about fan-out, the duplication that occurs when a one-to-many join inflates aggregate values.
Tableau's logical layer relationships were designed precisely for this scenario. When you relate Orders and Shipments on the order-line key, Tableau keeps each table at its native level of detail and only joins them contextually when a visualization requires fields from both. This means revenue stays aggregated at the order-line grain and shipping cost stays aggregated at the package grain, with no row multiplication. Slicing by product attributes from Orders or carrier attributes from Shipments works correctly because each table answers only its own questions. B is the right approach.
A is the classic trap: a physical join on Order ID multiplies every revenue row by the number of matching shipment rows. If an order line has three packages, revenue gets counted three times — a silent, dangerous inflation that's easy to miss in a dashboard.
C is structurally wrong. Unioning two tables with fundamentally different semantics (revenue vs. shipping cost) into a single measure column creates a mixed-grain, ambiguous field. You'd have to filter and calculate carefully just to get back to what a relationship gives you automatically.
D is operationally fragile. Manually synchronizing filters across unrelated data sources is error-prone, doesn't scale, and puts the burden of data integrity entirely on the analyst every time the view changes.
On the Tableau exam, when you see mismatched granularity between tables, relationships — not joins — are almost always the safest, most scalable answer.
- What should the workbook developer expect when a user selects a region?
Answer: Only the Orders worksheets will filter because the selected filter scope is limited to its data source.
When you see a question about dashboard filters in Tableau, the key concept to anchor on is filter scope — specifically, how the "Apply to Worksheets" setting interacts with data source boundaries.
In Tableau, each filter belongs to a specific data source. When you set a filter's scope to All Using This Data Source, you're telling Tableau to apply that filter to every worksheet drawing from that same connection — and only those worksheets. The filter doesn't cross into independently connected sources, even if a field with an identical name exists there. Here, the Region filter lives on the Orders source, so it propagates only to the two Orders worksheets. That makes B the correct answer.
A describes a common misconception: that matching field names imply a relationship. Tableau doesn't treat name similarity as a join or blend condition. Without an explicitly defined relationship or a shared data source, the two Region fields are completely independent objects.
C gets the logic backwards. There's no concept in Tableau where a secondary source inherits filters from a primary one automatically across independent connections. Cross-source filtering requires intentional configuration, such as using a data blending relationship or a dashboard filter set to "All Using Related Data Sources."
D overstates the restriction. A dashboard filter absolutely can filter worksheets — it just respects the scope you've defined. The filter works fine; it simply won't reach worksheets outside its assigned data source.
As a study tip, always trace the filter's owner (which data source it belongs to) and its scope setting together — those two pieces determine exactly which worksheets respond.
- What change most directly allows North to appear while retaining the blended comparison?
Answer: Make Quotas the primary source and use its Region field to establish the view's domain.
Whenever you see a blending question about missing members, think about domain control — Tableau's view domain is always dictated by the primary source. If a value doesn't exist in the primary source's linking field, it simply won't appear in the view, regardless of what the secondary source contains.
Here, Sales is primary and has no North records, so North is invisible to the view even though Quotas contains it. The most direct fix is choice A: make Quotas the primary source. Because Quotas contains East, West, and North, its Region field defines the full domain. Sales then becomes secondary, and its quota-less regions just show null — exactly the blended comparison the analyst wants, now with North visible.
Choice B is tempting but misunderstands the problem. ATTR is an aggregation function used to return a single value when all rows agree; it doesn't add missing dimension members to the view. The domain gap remains.
Choice C — deactivating the Region link — would actually break the blend's ability to match quota values to the correct region. You'd lose meaningful row-level alignment between the two sources, not gain new rows.
Choice D is a misconception about extracts. Extracts optimize performance and enable offline access, but they don't give Tableau the ability to infer dimension values from a secondary source into the primary source's domain. The domain rule still applies.
Study tip: On blend questions, always ask "which source owns the view?" The primary source controls what rows appear. If you need values that only exist in the secondary source to show up, that source needs to become the primary.
- Which approach is most appropriate for preparing the workbook?
Answer: Union the files within one data source so their transaction rows form a single logical history.
When you see a question about combining files with identical structures in Tableau, your first instinct should be to think about stacking rows, not merging columns. The core question is always: do these files share the same schema and need to be treated as one continuous dataset?
That's exactly the scenario here. Twelve files, identical columns, one unified transaction history needed — this is a textbook use case for a Union. A Union appends rows from each file vertically beneath one another, creating a single table where every transaction from every year lives in the same dataset. This makes calculating multi-year customers straightforward: you simply count distinct years per Customer ID within one source. Option C is the right approach.
Option A is wrong because blending is designed for combining different data sources with different granularities, using a linking field. It would create a primary/secondary relationship that limits your ability to analyze transactions holistically — multi-year customer calculations become awkward and unreliable at the row level.
Option B describes a Join, which combines tables horizontally by matching keys. Joining these files by Customer ID would explode your data into wide, repeated columns per year — a structural mess that makes row-level transaction analysis extremely difficult and produces duplicate records.
Option D describes Tableau's Relationships feature, which is powerful for multi-table models but is not appropriate when you simply want to stack identical structures. Omitting the transaction date from the relationship clause would further compromise analytical accuracy.
Study tip: Remember the rule of thumb — same columns, need more rows? Union. Different tables, need to link by a key? Relate or Join.
- Which action should be taken before or during the replacement to minimize broken workbook content?
Answer: Align the corresponding field names and data types, then validate calculations and field references after replacement.
When replacing a data source in Tableau, the core challenge is ensuring that existing calculations, field references, and visualizations survive the swap intact. Tableau maps fields between sources by matching field names and data types — if those don't align, fields break and calculations fail silently or throw errors.
The right move, as described in A, is to proactively align field names and data types in the production source before or during replacement. If "Order ID," "Revenue," and "Order Date" exist with matching names and types in production, Tableau can map them automatically. After replacement, you then validate to catch anything that slipped through — especially the text-stored date field, which needs to be converted to a proper date type to preserve date calculations.
B is a trap based on a misconception — Tableau does not use column positions to match fields when replacing a data source. It uses field names. Hiding fields does nothing to assist the mapping process.
C suggests converting all development fields to strings, which would actually cause breakage. Date and numeric calculations depend on correct data types; stripping that semantic information guarantees more broken content, not less.
D misunderstands how Tableau handles data source replacement. Compatibility is evaluated across the entire workbook — calculated fields, parameters, and shared dimensions — not just at the worksheet level. Duplicating worksheets doesn't protect anything.
As a study tip: whenever you see a question about data source replacement or migration in Tableau, anchor your thinking to name alignment and data type compatibility — those are the two levers Tableau uses to automatically resolve field mappings.
- Which publishing plan most responsibly addresses the workbook's data freshness?
Answer: Configure credentials and refresh behavior for each connection, schedule both extracts, and document possible timing differences from live data.
When a workbook contains multiple connection types — live, extracted, and independently scheduled — you need to think about each source as its own data pipeline with its own authentication and refresh requirements. Tableau does not treat a workbook as a single unified refresh unit; every connection is managed independently.
Answer A is correct because it reflects exactly how Tableau Publishing actually works. Each extract must be individually configured with credentials and a refresh schedule. Documenting the timing gap between the live warehouse connection and the two extracts is equally important: the live source reflects real-time data while extracts only reflect their last refresh, so users need to understand that the three sources may never be perfectly synchronized at workbook-open time.
Answer B describes a feature that simply does not exist. Refreshing one extract in a workbook has no effect on other extracts or live connections — each runs on its own schedule and must be configured separately.
Answer C conflates two separate concepts: credential embedding and refresh scheduling. Live connections do not "share" authentication or schedule behavior with extracted sources. Each source requires its own credential configuration, and extracted sources require their own independent refresh schedule regardless of what the live source does.
Answer D misunderstands how live connections function. Converting the spreadsheet to a live connection does not propagate live-query behavior to the other sources. The remaining extracted database source still refreshes only on its own schedule, so the problem of timing inconsistency is not resolved.
A useful rule of thumb: on Tableau exam questions, whenever you see multiple mixed connection types, assume every source must be managed independently — credentials, schedules, and documentation all belong to each connection individually.
- Which statement best describes the responsible security design for this workbook?
Answer: The HR source needs its own access controls because security rules in one source do not automatically propagate to another.
When working with blended data sources in Tableau, a critical principle to internalize is that security rules are source-specific — they live in the system that enforces them and do not travel across the blend boundary. Keeping this in mind makes this question straightforward.
The HR file is a local extract with no built-in access controls. Even though it's blended with a governed Sales source, that governance applies only to Sales data. The HR compensation fields enter the workbook on their own terms, completely unprotected. This is why D is correct: the HR source requires its own independent access controls, because security in one source has no jurisdiction over another.
A is the most dangerous misconception here — it implies that using Employee Email as a linking field somehow extends the Sales source's row-level security to HR rows. It does not. The link field determines which rows join, not who is permitted to see the joined data. B is similarly flawed: making Sales the primary source controls which Sales records are visible, but secondary-source records are still queryable through the blend; "primary" does not mean "governing authority over all sources." C appeals to common sense but misunderstands how Tableau workbooks work — a hidden sheet is a UI convenience, not a security layer. Anyone who downloads the workbook and inspects the underlying data connections or uses Tableau's built-in tools can still access that content.
A good rule of thumb for the exam: every data source in a blend must be secured independently. Never assume that a governed source acts as a security umbrella for unprotected sources blended alongside it.
- Which modeling choice best aligns the sources at the intended analytical grain?
Answer: Relate the tables by Region and a month value derived from Order Date that matches the target month.
When comparing data from two tables that live at different grains — transactions at the individual-sale level versus targets at the month-region level — your central challenge is defining a relationship that "meets" both tables at the right level of detail without distorting either side. In Tableau's logical layer, relationships are the right tool because they preserve each table's native grain and only join rows at query time based on what the visualization needs.
The right approach, answer B, is to relate the two tables on both Region and a derived month value (e.g., MONTH([Order Date]) matched to the target month field). This ensures Tableau pulls exactly one target row per region-month combination, aligning the two sources at the intended monthly grain cleanly and automatically.
A is tempting but flawed. Relating only on Region leaves month matching to whatever happens to be on the worksheet, which is fragile and unreliable — Tableau won't guarantee a correct month-level join just because a month dimension is in the view. You'd risk incorrect or inflated matches.
C introduces a fundamental modeling error: a regular join on Region alone repeats the target value for every transaction row in that region, regardless of month. Averaging those repeated values downstream is a band-aid that creates unnecessary complexity and is prone to errors, especially when transaction counts vary.
D is a misuse of Union. Unions stack rows from two tables vertically, meaning sales and targets would end up in the same column — the tables would lose their distinct roles, making comparison calculations nearly impossible.
The study tip: whenever your two sources live at different grains, always ask "what fields uniquely identify a row in the coarser table?" — those are exactly the fields your relationship or join needs to include.
- Which approach can combine the sources in the workbook without modifying the published data sources?
Answer: Blend the published data sources in the worksheet, using Region as an active linking field.
When you see a question about combining multiple published data sources in Tableau without touching those sources, you should immediately think about data blending — Tableau's purpose-built feature for exactly this situation.
Data blending works entirely at the worksheet level. You designate one source as primary and the other as secondary, then activate a linking field (here, Region) that exists in both. Tableau queries each source independently and joins the aggregated results in the view — no modifications to either published source required. That makes C the correct approach.
Here's why the other options don't work. A is a trap: physical cross-database joins in Tableau require editing the data source itself — you'd have to open a published source and restructure its connection layer, which the problem explicitly forbids. B describes a union, which appends rows from two tables into one. Unions work only within a single connection or between compatible physical tables; they cannot span two separate published sources, and they're semantically wrong here anyway since you need a side-by-side comparison, not stacked rows. D sounds appealing because relationships are Tableau's modern multi-table feature, but relationships also require you to drag tables into a data source's logical model — meaning you'd need to edit or create a new data source combining both published ones, which violates the constraint.
The study tip to remember: blending is the only Tableau technique that combines data across independently governed published sources without modifying either one. If a question emphasizes that published sources are locked or owned by others, blending is almost always the intended answer.
- Which calculation is appropriate for the blended view?
Answer: SUM([Sales]) - SUM([Targets].[Target]), aggregating measures from both sources at the view level.
When working with blended data sources in Tableau, the fundamental rule is that each source is aggregated independently before values are combined. Tableau cannot mix row-level fields across sources in a single calculation the way it can within one source — the link between sources only exists at the aggregate level displayed in the view.
This makes D the correct approach. SUM([Sales]) - SUM([Targets].[Target]) aggregates Sales within the primary source and Target within the secondary source separately at the view's level of detail (Region/Month), then subtracts the two results. Since Targets already has one row per Region-Month, SUM([Targets].[Target]) simply returns that single target value — clean and correct.
A is tempting but flawed: you cannot subtract a raw, unaggregated secondary field from an aggregated primary measure. Tableau requires that secondary source fields be aggregated when used in blended calculations; mixing aggregate and non-aggregate values will produce an error.
B fails because LOD expressions (FIXED, INCLUDE, EXCLUDE) cannot span multiple data sources in a blend. LODs operate entirely within a single source's context, so attempting a cross-source LOD expression is not supported syntax in Tableau.
C is the subtler trap. SUM([Sales] - [Targets].[Target]) attempts row-level subtraction inside the aggregation, which requires Tableau to match individual rows across sources — something blending cannot do. Blending joins happen at the aggregate level, not the row level.
Study tip: In any blend question, ask yourself: "Am I aggregating each source separately before combining?" If yes, you're on safe ground. Row-level cross-source math is always a red flag.
