Tableau Quiz: Multiple Data Sources
10 questions · exam conditions
0:00
Multiple Data SourcesQuestion 1 of 10

A workbook uses two separately governed published data sources: Actual Sales and Regional Quotas. The data-source owners will not permit either published source to be modified or replaced. The workbook needs an aggregate comparison by Region, a field available in both sources.

Which approach can combine the sources in the workbook without modifying the published data sources?

Create a physical cross-database join directly between the two published data sources using Region.
Create a union of the published data sources and assign nulls to measures that do not align.
Blend the published data sources in the worksheet, using Region as an active linking field.
Create a relationship between the published data sources by dragging both onto the logical data model.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Multiple Data Sources

Practice Multiple Data Sources in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Multiple Data Sources, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A workbook uses two separately governed published data sources: Actual Sales and Regional Quotas. The data-source owners will not permit either published source to be modified or replaced. The workbook needs an aggregate comparison by Region, a field available in both sources.

Which approach can combine the sources in the workbook without modifying the published data sources?

  1. Create a physical cross-database join directly between the two published data sources using Region.
  2. Create a union of the published data sources and assign nulls to measures that do not align.
  3. Blend the published data sources in the worksheet, using Region as an active linking field. (correct answer)
  4. Create a relationship between the published data sources by dragging both onto the logical data model.
Explanation: 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.

Question 2

Sales is the primary source in a blended worksheet and contains records only for East and West. Quotas is the secondary source and contains East, West, and North. Region from Sales is in the view, and the analyst expects North to appear even though North has no sales.

What change most directly allows North to appear while retaining the blended comparison?

  1. Make Quotas the primary source and use its Region field to establish the view's domain. (correct answer)
  2. Keep Sales primary and replace the secondary quota aggregation with an ATTR aggregation.
  3. Keep Sales primary and deactivate the Region linking field before adding quota values.
  4. Make Sales an extract so Tableau can infer regions found only in the secondary source.
Explanation: 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.

Question 3

A blended worksheet uses Sales as the primary source and Targets as the secondary source. The view contains Region and Month, and Targets has exactly one target row for each Region-Month combination. The developer wants a variance calculation using fields from both sources.

Which calculation is appropriate for the blended view?

  1. SUM([Sales]) - [Targets].[Target], leaving the secondary target at its stored row-level value.
  2. { FIXED [Region] : SUM([Sales]) - SUM([Targets].[Target]) }, using one cross-source LOD expression.
  3. SUM([Sales] - [Targets].[Target]), subtracting the secondary target separately from every primary row.
  4. SUM([Sales]) - SUM([Targets].[Target]), aggregating measures from both sources at the view level. (correct answer)
Explanation: 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.

Question 4

A company stores annual customer transactions in twelve files with identical columns. Analysts need one continuous transaction history and must calculate customers who purchased in more than one year. The files are accessible through the same file-based connection.

Which approach is most appropriate for preparing the workbook?

  1. Blend each file as a separate source and use the first year as the primary transaction domain.
  2. Join the files by Customer ID so each customer's annual transactions appear in adjacent columns.
  3. Union the files within one data source so their transaction rows form a single logical history. (correct answer)
  4. Relate every annual file by Customer ID while omitting transaction date from the relationship clauses.
Explanation: 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.

Question 5

A published workbook uses a live warehouse connection, an extracted spreadsheet, and a second independently extracted database source. Users assume that all three sources represent the same refresh time whenever the workbook opens.

Which publishing plan most responsibly addresses the workbook's data freshness?

  1. Configure credentials and refresh behavior for each connection, schedule both extracts, and document possible timing differences from live data. (correct answer)
  2. Schedule only the first extract because refreshing any workbook extract automatically refreshes every source used by that workbook.
  3. Embed credentials only for the live connection because extracted sources inherit authentication and schedules from the live source.
  4. Convert only the spreadsheet to a live connection because this forces all remaining connections to query at workbook-open time.
Explanation: 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.

Question 6

A workbook must compare order revenue with shipping cost. The Orders table contains one row per order line, while the Shipments table can contain several package rows for the same order line. Analysts need to slice results by product attributes from Orders and carrier attributes from Shipments.

Which data-modeling approach most responsibly supports the analysis while reducing the risk of duplicated revenue?

  1. Physically join Orders to Shipments on Order ID and sum revenue and shipping cost in each view.
  2. Relate Orders and Shipments as logical tables using the applicable order-line keys, preserving their separate levels of detail. (correct answer)
  3. Union Orders and Shipments after renaming revenue and shipping cost to a common measure field.
  4. Keep both tables as unrelated data sources and manually synchronize every filter used in the workbook.
Explanation: 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.

Question 7

A workbook currently uses a development data source. The developer plans to replace it with a production data source. Several calculations reference Order ID, Revenue, and Order Date. In production, the corresponding fields currently have different names, and one date field is stored as text.

Which action should be taken before or during the replacement to minimize broken workbook content?

  1. Align the corresponding field names and data types, then validate calculations and field references after replacement. (correct answer)
  2. Hide the development fields before replacement so Tableau matches production fields using their column positions.
  3. Convert every development field to a string so Tableau can replace fields regardless of their semantic roles.
  4. Duplicate every worksheet before replacement because field compatibility is evaluated only at the worksheet level.
Explanation: 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.

Question 8

Transactions contains one row per sale with Region and Order Date. Targets contains one row per Region and calendar month. A workbook must compare monthly sales with monthly targets without repeating a target for every transaction.

Which modeling choice best aligns the sources at the intended analytical grain?

  1. Relate the tables by Region only and rely on the month displayed in each worksheet to restrict matches.
  2. Relate the tables by Region and a month value derived from Order Date that matches the target month. (correct answer)
  3. Join the tables by Region only and average the repeated target values in every downstream calculation.
  4. Union the tables after converting Order Date and target month to a shared text representation.
Explanation: 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.

Question 9

A workbook combines a governed Sales source that enforces row-level security with a local HR file containing employee compensation. Employee email is available in both sources, and the workbook blends selected fields for managers.

Which statement best describes the responsible security design for this workbook?

  1. The Sales source's row-level security automatically restricts matching HR rows because Employee Email is used as a linking field.
  2. Making Sales the primary source secures HR data because secondary-source rows cannot be accessed independently.
  3. A hidden HR worksheet prevents unauthorized users from querying compensation through downloaded workbook content.
  4. The HR source needs its own access controls because security rules in one source do not automatically propagate to another. (correct answer)
Explanation: 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.

Question 10

A dashboard contains two worksheets based on an Orders data source and two worksheets based on an independently connected Support data source. Both sources contain a field named Region, but no relationship has been defined between them. A Region filter from Orders is configured with Apply to Worksheets > All Using This Data Source.

What should the workbook developer expect when a user selects a region?

  1. All four worksheets will filter because fields with identical names are automatically treated as related.
  2. Only the Orders worksheets will filter because the selected filter scope is limited to its data source. (correct answer)
  3. Only the Support worksheets will filter because secondary data sources inherit filters from primary sources.
  4. No worksheets will filter because a dashboard filter requires every worksheet to share one connection.
Explanation: 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.