Tableau Quiz: Data Blending
10 questions · exam conditions
0:00
Data BlendingQuestion 1 of 10

An analyst must combine a governed published sales data source with a separate published planning data source. The sources cannot be physically joined in the workbook. Sales is transactional, while planning data is stored at the monthly region level.

Which statement best describes why data blending can satisfy this requirement?

Blending copies both published sources into one extract and performs a row-level full outer join.
Blending sends separate queries, aggregates the results, and combines them using worksheet linking fields.
Blending permanently modifies the published sources so they share one physical data model.
Blending unions the planning rows below sales rows and reconciles their different field structures.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Data Blending

Practice Data Blending 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 Data Blending, 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

An analyst must combine a governed published sales data source with a separate published planning data source. The sources cannot be physically joined in the workbook. Sales is transactional, while planning data is stored at the monthly region level.

Which statement best describes why data blending can satisfy this requirement?

  1. Blending copies both published sources into one extract and performs a row-level full outer join.
  2. Blending sends separate queries, aggregates the results, and combines them using worksheet linking fields. (correct answer)
  3. Blending permanently modifies the published sources so they share one physical data model.
  4. Blending unions the planning rows below sales rows and reconciles their different field structures.
Explanation: When you see a question about combining published data sources in Tableau, focus on how the mechanism works under the hood — not just what it produces. Data blending is fundamentally a query-time process, not a physical data transformation. Blending works by issuing separate, independent queries to each data source. The primary source (sales, here) returns its results first, and Tableau then queries the secondary source (planning) and aggregates those results to the linking field level before combining them in the worksheet view. This is exactly why blending handles granularity mismatches so naturally — the planning data is already aggregated at the monthly-region level before it's joined into the view. Answer B captures this precisely: separate queries, aggregated results, combined via linking fields. Answer A is wrong on two counts — blending does not create a merged extract, and it does not perform a full outer join. Blending produces a left join behavior (unmatched secondary records are excluded), and no extract is generated from the combination. Answer C describes something that simply doesn't exist in Tableau; blending is entirely non-destructive and read-only with respect to your published sources. Nothing is permanently modified. Answer D confuses blending with a union. Unions append rows vertically and require compatible field structures — blending combines aggregated results horizontally by matching on linking fields, which is a fundamentally different operation. A reliable study tip: remember that blending = left join at the aggregate level, at query time. If an answer suggests blending touches the underlying data sources, creates extracts from them, or stacks rows, it's describing a different feature entirely.

Question 2

Sales is the primary source and Targets is secondary. Both are linked by Region. A filter based on the secondary field Plan Status is set to Approved. Some sales regions have only draft targets or no target record.

What limitation should the analyst consider when interpreting the filtered view?

  1. The secondary filter restricts which target records are returned but does not inherently filter the primary sales records, so sales regions without an approved target can still appear with a null target value. (correct answer)
  2. The secondary filter converts the blend to an inner join, removing every sales region that lacks an approved target record from the view.
  3. The secondary filter is automatically promoted to a data source filter shared by both the sales and targets connections.
  4. The secondary filter demotes Sales to a secondary source because restricting target records narrows the overall domain of the view.
Explanation: When working with data blending in Tableau, the most important concept to internalize is that the primary source always drives the view. Blending is not a join — it's a left relationship where every row from the primary source appears first, and the secondary source contributes aggregated values where a link match exists. When you place a filter on a field from the secondary source (like Plan Status from Targets), that filter controls which secondary records are eligible to match — but it does not remove primary source rows from the view. A sales region without an approved target record simply returns null for any secondary measures, yet still appears in the visualization. This is exactly what A describes: the secondary filter limits which target rows participate, but sales regions without a match are retained with null target values, which can mislead an analyst into thinking those regions have no activity rather than just no approved plan. B is wrong because data blending never converts to an inner join based on a secondary filter. Inner join behavior would require restructuring the data source relationship entirely, not applying a filter. C is incorrect because secondary source filters are scoped to that source only — they are never automatically promoted to a shared data source filter affecting the primary connection. D reverses the logic entirely; applying a filter to the secondary source has no effect on which source is designated primary or secondary, and nothing "demotes" Sales. As a study tip: whenever you see a question about filtering in a blended data source, ask yourself — which source is primary? Primary source rows always survive secondary filters.

Question 3

On a new worksheet, an analyst first drags Region from the Targets data source into the view. The analyst then adds SUM(Sales) from the Sales data source using Region as the linking field. The worksheet omits sales-only regions, even though another worksheet in the workbook displays them.

Which explanation best accounts for the difference between the worksheets?

  1. Targets became primary on this worksheet because it supplied the first field, so its region domain controls the blend. (correct answer)
  2. Sales became primary when its measure was added because measures always override dimensions when blending.
  3. The workbook has one permanent primary source, but the region filter is synchronized differently by worksheet.
  4. The source with more rows becomes primary automatically, so Tableau selected Targets after estimating query size.
Explanation: When Tableau blends two data sources on a worksheet, the primary source is whichever one you interact with first — specifically, whichever source contributes the first field dragged into the view. This is a per-worksheet designation, not a workbook-wide setting. The primary source's domain of values defines what appears in the view; the secondary source is then left-joined to it, meaning only matching values from the secondary appear. In this scenario, the analyst drags Region from Targets first, making Targets the primary source on that worksheet. When SUM(Sales) is added from Sales, Targets' region list controls the view. Any region that exists in Targets but not in Sales shows up (with null for Sales), but regions that exist only in Sales are excluded — exactly what the question describes. That makes A correct. B is wrong because the type of field — measure versus dimension — has no bearing on which source becomes primary; only the order of first interaction matters. C is wrong because Tableau does not maintain a single workbook-wide primary source; the designation is set independently on each worksheet, which is actually why two worksheets can show different regions. D is wrong because Tableau never uses row count or query size estimation to assign primary status — that concept simply doesn't exist in Tableau's blending logic. For the exam, remember this rule: the first field placed in the view determines the primary source for that worksheet, and the primary source's domain acts like the "left" side of a left join during blending.

Question 4

Orders contains Customer ID as an integer. Survey Results contains the corresponding Customer ID as a string, including values such as "1042". The fields have been assigned the same name, but Tableau does not establish a usable blend relationship between them.

What should the analyst do to enable reliable blending by customer?

  1. Assign both Customer ID fields the same aliases and keep their underlying data types unchanged.
  2. Create a converted key with matching data types, then define the relationship using those fields. (correct answer)
  3. Change both Customer ID fields to discrete so Tableau can compare their displayed values.
  4. Place both original fields on Detail so Tableau can infer a cross-type relationship automatically.
Explanation: When Tableau attempts to blend two data sources, it needs a shared field with compatible data types to establish the link. If one source stores Customer ID as an integer and the other stores it as a string like "1042," Tableau cannot match those values reliably — even if the field names are identical. The field name alone is never enough; the underlying values must be comparable. The fix described in B is the correct approach: create a calculated field in one (or both) sources that converts the data type so both keys are the same type — for example, using STR([Customer ID]) to convert the integer to a string, or INT([Customer ID]) to convert the string to an integer. Once you have matching types, you can explicitly define the blend relationship using those converted fields, giving Tableau a clean, reliable link. A is a trap — aliases only change the display label of a field, not its underlying data type or values. Tableau's blend engine works on raw values, not aliases, so this does nothing to resolve the mismatch. C confuses discrete/continuous (a visual encoding property) with data type; making a field discrete doesn't change whether it's a string or integer. D is wishful thinking — Tableau has no mechanism to automatically infer cross-type relationships from fields placed on Detail. It won't silently resolve a type mismatch for you. Study tip: Whenever a blend isn't working despite shared field names, your first diagnostic question should be "do these fields have the same data type?" Type mismatches are the most common hidden cause of broken blends on the Tableau exam.

Question 5

Orders records activity by Store and exact Order Date. Staffing records monthly labor hours by Store and Month Start Date. Tableau has activated relationships on Store and the two date fields because their names and types were aligned. Most daily order marks show null staffing hours because staffing dates occur only on the first day of each month.

What is the most appropriate way to create a valid store-month comparison?

  1. Keep the exact-date link active and replace null staffing hours with zero before aggregating.
  2. Remove the Store link and blend only on the exact dates that happen to match.
  3. Convert staffing hours to a daily average and retain both existing active linking fields.
  4. Create matching month-level fields, deactivate the exact-date link, and blend on Store and Month. (correct answer)
Explanation: When blending data sources in Tableau, the grain of your linking fields must match the grain of your data — otherwise, Tableau can only join records where values align exactly, leaving everything else as null. That's precisely the trap this scenario describes: Orders records activity daily, Staffing records it monthly, and Tableau's auto-activated date link requires an exact match. Since staffing dates only appear on the first of each month, nearly every daily order record finds no match and returns null hours. The correct path is D. By creating month-level fields in both sources (for example, truncating Order Date to month), deactivating the mismatched exact-date link, and blending on Store plus Month, you align the granularity of both sources. Now every order in a given month links to that month's staffing hours — producing a clean, valid comparison. A is tempting but fundamentally broken: replacing nulls with zero before aggregating treats "no match found" as "zero labor hours," which distorts your analysis. The underlying grain mismatch is never fixed. B discards the Store link entirely, which removes a critical dimension and would incorrectly mix staffing across stores that happen to share a date. C converts staffing hours to a daily average but keeps both mismatched active links — this still won't resolve the join failure for the vast majority of daily records, because the exact-date link still demands a matching date that usually doesn't exist. A useful rule of thumb: before blending, always audit the grain of each linking field. If the granularities don't match, create derived fields that do — then activate only the links that reflect those matched levels.

Question 6

Sales is the primary source and contains the regions East and West. Targets is the secondary source and contains the regions East and North. Region is the active linking field. The worksheet uses Region from Sales, SUM(Sales), and SUM(Target).

Which result should the analyst expect from the blend?

  1. East, West, and North appear; West has a null target and North has null sales.
  2. Only East appears because it is the sole region found in both data sources.
  3. East and West appear; West has a null target, while North does not appear. (correct answer)
  4. East and North appear; North has null sales, while West is removed from the view.
Explanation: When working with data blending in Tableau, the most important rule to remember is this: the primary source drives the view. Whatever rows exist in the primary source will appear in the worksheet — the secondary source simply augments those rows with additional measures where a match exists. Here, Sales is the primary source containing East and West. Targets is the secondary source containing East and North. Because Region from Sales anchors the view, you'll always see East and West — those are your primary source rows. When Tableau looks for a matching region in Targets, it finds East and returns its target value. West has no match in Targets, so SUM(Target) comes back as null for West. That's exactly what C describes, making it the correct answer. Choice A is wrong because North cannot appear in the view — North only exists in the secondary source (Targets), and the primary source never surfaces rows that exist solely in the secondary. Choice B describes an inner join behavior, not a blend; blending doesn't filter the primary source down to only matching rows — it preserves all primary rows regardless of whether a secondary match exists. Choice D would only make sense if Targets were the primary source, which would surface North while leaving West without a match — but the question clearly states Sales is primary. A useful mental model: think of blending like a LEFT JOIN where the left table is always the primary source. Every row from the left (primary) appears; unmatched rows from the right (secondary) produce nulls, and rows that exist only on the right are invisible entirely.

Question 7

Sales is primary and Store Directory is secondary. The sources are currently linked only by Region. A worksheet displays Region and ATTR(Store Manager). Each region contains several stores, and different stores can have different managers. Tableau displays an asterisk for Store Manager in several regions.

The analyst now needs one mark for each store with its manager. What change most directly resolves the ambiguity?

  1. Replace ATTR(Store Manager) with MIN(Store Manager) while retaining one region-level mark.
  2. Convert Store Manager to a measure and average it across the secondary records in each region.
  3. Add Store to the view and blend relationship so each mark resolves at the store level. (correct answer)
  4. Make Store Manager an inactive linking field and preserve Region as the only active link.
Explanation: When you see asterisks in a blended data view, Tableau is telling you something important: the linking granularity is too coarse to resolve unique values. ATTR() returns a single value only when every secondary record in a group agrees — if multiple stores in a region have different managers, Tableau has no way to pick one, so it displays * instead. The root fix here is adjusting the blend level, not the aggregation function. Right now, the blend joins Sales to Store Directory only at the Region level, so each regional mark pulls in multiple store managers simultaneously. The solution in C — adding Store to the view and updating the blend relationship to link on Store — creates one mark per store and gives the secondary source a precise join key. Now each mark maps to exactly one manager, and ATTR() resolves cleanly. A is wrong because swapping ATTR for MIN doesn't change the granularity problem; it just hides it by arbitrarily picking the alphabetically first manager. The ambiguity isn't resolved — it's suppressed, giving you misleading data. B is wrong for a similar reason: Store Manager is a string, so averaging it is meaningless. Even if you could convert it, averaging names produces nonsense and still doesn't give you one mark per store. D is wrong because deactivating the Store Manager linking field while keeping only Region as the link moves away from store-level resolution. You'd still have multiple managers per region mark — the asterisks wouldn't go away. Study tip: On Tableau blend questions, asterisks always signal a granularity mismatch. Ask yourself: "What level does the view need to be at so each secondary group contains only one value?" Then add that dimension to both the view and the blend relationship.

Question 8

A company stores daily sales transactions in one data source and annual sales quotas in another. The sources are blended using Salesperson and Year. Sales is the primary source. A worksheet displays Salesperson, Year, total sales, and annual quota.

Assuming each salesperson has one quota record per year, what is the expected effect of using data blending rather than physically joining quota to each transaction?

  1. The annual quota is repeated for every transaction and must be divided by the transaction count.
  2. Each source is aggregated by the linking fields before the annual quota is combined with sales. (correct answer)
  3. Daily sales are averaged to the annual level before they are matched to the annual quota.
  4. Only salespeople with records in both sources remain because blending uses matching rows only.
Explanation: When you encounter a question about data blending in Tableau, focus on when aggregation happens. Unlike a traditional join — which combines raw rows before any aggregation — data blending aggregates each source independently at the level of the linking fields, then combines the results. That sequencing is the heart of this question. In this scenario, the primary source (Sales) aggregates all daily transactions up to the Salesperson + Year level, producing a single total sales figure per salesperson per year. The secondary source (Quotas) similarly aggregates to that same level — which, since each salesperson already has one quota per year, simply returns that single quota value. Tableau then stitches these two aggregated results together. The result is a clean, one-row-per-salesperson-per-year view with no duplication or distortion. That's exactly what B describes. A is wrong because it describes behavior from a row-level join, where quota would be stamped onto every transaction row and inflate when summed. Blending never exposes raw secondary-source rows to the primary source's unaggregated data. C is wrong because daily sales are summed, not averaged — blending doesn't change your aggregation function, it just applies it before the blend occurs. D describes an INNER JOIN, not blending. Blending behaves more like a LEFT JOIN: all primary-source records appear, and secondary-source values appear where a match exists (or show null where they don't). A useful rule of thumb: blending = aggregate first, join second. Whenever a question asks what happens to row-level data across blended sources, remind yourself that neither source ever "sees" the other's unaggregated rows.

Question 9

Sales must remain the primary source because the worksheet must retain every sales region. Customer Activity is secondary. In the deployed Tableau environment, using COUNTD(Customer ID) directly from the secondary source is unsupported for the blend. The required result is the distinct customer count for each Region and Quarter.

Which approach best addresses the limitation while preserving the required primary domain?

  1. Preaggregate distinct customers by Region and Quarter outside the blend, then blend that result as a measure. (correct answer)
  2. Duplicate Customer ID in the secondary source and use a standard row count after blending.
  3. Add Customer ID as an active linking field so Tableau can count primary and secondary rows together.
  4. Convert Customer ID to a continuous measure and sum its values within each blended region.
Explanation: When Tableau blends data sources, it queries each source separately and joins the aggregated results — meaning functions like COUNTD() on a secondary source field are often unsupported or unreliable in deployed environments. The key insight here is that you must work with this architectural constraint, not against it, while keeping Sales as the primary source (which anchors the regional domain). The cleanest solution is A: preaggregating the distinct customer count by Region and Quarter in the secondary source before the blend occurs. This means the secondary source already contains a single numeric value per Region/Quarter combination, so Tableau simply retrieves and displays that pre-computed measure — no unsupported COUNTD() call happens inside the blend at all. B is flawed because duplicating Customer ID doesn't solve the distinctness problem. A row count after blending would overcount customers who appear in multiple transactions, giving you transaction volume, not unique customer count. C misunderstands how link fields work. Adding Customer ID as a linking field forces row-level matching between sources, which actually breaks the regional aggregation you need and doesn't resolve the COUNTD() restriction — it just changes how Tableau tries (and fails) to join the data. D is a red herring. Customer IDs are typically alphanumeric identifiers, not meaningful numeric values. Even if they were integers, summing them produces a mathematically meaningless number, not a distinct count. When you see blend-related questions, ask yourself: "Is the aggregation happening before or inside the blend?" Preaggregation is almost always the safe escape hatch when native blend functions are restricted.

Question 10

Sales is the primary source, and Target is a numeric field from the secondary source. An analyst needs a blended calculation representing total sales divided by total target at the level of detail displayed in the worksheet.

Which calculation most appropriately implements the requested ratio?

  1. [Sales]/[Target][Sales] / [Target]
  2. SUM([Sales]/[Target])SUM([Sales] / [Target])
  3. SUM([Sales])/SUM([Target])SUM([Sales]) / SUM([Target]) (correct answer)
  4. ATTR([Sales])/SUM([Target])ATTR([Sales]) / SUM([Target])
Explanation: When working with data blending in Tableau, the critical concept is aggregation before division. Because blended data sources operate at the level of detail of the primary source, you must aggregate each field independently before combining them — otherwise Tableau can't reconcile row-level values across sources. The correct approach, C — SUM([Sales])/SUM([Target])SUM([Sales]) / SUM([Target]) — aggregates each field fully before dividing. This produces a single, meaningful ratio: total sales over total target at whatever grain is displayed in the view. It's clean, predictable, and exactly what the analyst needs. A — [Sales]/[Target][Sales] / [Target] — attempts a row-level division without any aggregation. In a blended context, Tableau can't perform unaggregated row-level math across sources, so this will either error or produce unexpected results. You must aggregate blended fields explicitly. B — SUM([Sales]/[Target])SUM([Sales] / [Target]) — wraps the division inside SUM, which means Tableau tries to divide row by row first, then sum. This is mathematically wrong for a ratio: summing individual row-level ratios is not the same as total sales divided by total target. It's a classic order-of-operations trap. D — ATTR([Sales])/SUM([Target])ATTR([Sales]) / SUM([Target]) — uses ATTR, which returns the field's value only if every row in the partition has the same value, otherwise it returns an asterisk (*). Sales is a measure that varies across rows, so ATTR is the wrong aggregation function here and will almost certainly return *. Your study tip: whenever you're building a ratio in Tableau (especially with blending), always aggregate numerator and denominator separately using SUM before dividing. Never divide inside an aggregation.