- What is the best interpretation and correction?
Answer: The asterisk means multiple customer names underlie the mark; show a meaningful aggregate or a detailed tooltip view.
When you see ATTR() in Tableau, think about what it's designed to do: return a single value if all rows in a partition share the same value, or return an asterisk (*) if they differ. This question is testing whether you understand that signal and how to respond to it appropriately.
In a bar chart aggregated by region, each mark represents many customers. When you drop ATTR(Customer Name) into the tooltip, Tableau checks whether every customer behind that mark has the same name. Since each region contains many different customers, the values disagree — and Tableau displays * to tell you exactly that. The correct response, answer B, is to recognize the asterisk as a many-to-one problem and either replace the field with a meaningful aggregate (like COUNTD(Customer Name)) or use a detail-level tooltip view to list individual customers.
A is wrong because an asterisk from ATTR does not indicate nulls — it indicates multiple distinct values. Switching to MIN would suppress the asterisk by arbitrarily picking one customer name, which is misleading rather than informative. C confuses the asterisk with a display alias issue; aliases affect how values appear, not whether ATTR returns a single value. D misidentifies the asterisk as a truncation artifact. Tooltip truncation shows ellipses (...), not an asterisk — the * is a deliberate Tableau signal about data granularity, not a rendering limitation.
Your study tip: memorize the ATTR contract — one distinct value returns that value; multiple distinct values return *. Whenever you see an asterisk in a tooltip or a computed field, your first question should be "am I at the wrong level of detail?"
- How should the Viz in Tooltip filtering be configured?
Answer: Use selected fields and pass State, but do not pass Product Category.
When configuring a Viz in Tooltip, you control which source fields are passed as filters into the target viz. The key distinction is between passing all source fields versus selected fields — and this choice determines exactly how the tooltip viz gets filtered.
Here, the source marks are defined by both State and Product Category. The goal is to filter the trend by State alone, keeping all Product Categories visible. This means you need granular control: pass State (so the trend scopes to the hovered state) but deliberately exclude Product Category (so the trend aggregates across all categories). That's precisely what "Use selected fields" lets you do — B is correct.
Choice A fails because using all source fields would pass both State and Product Category into the tooltip viz, filtering the trend down to a single category. A user hovering over "California / Furniture" would see only Furniture sales in California, not all categories — which contradicts the stated requirement.
Choice C inverts the logic entirely. Passing only Product Category would filter the trend by category and ignore State, giving you the opposite of what's needed. Placing State in tooltip title text is cosmetic only; it doesn't drive filtering.
Choice D misunderstands how Viz in Tooltip filtering works. Disabling filtering removes all context-passing, so the tooltip viz would display unfiltered global data regardless of what mark you hover over. There's no "target label" mechanism that substitutes for filter passing.
Study tip: When you see a Viz in Tooltip question, ask yourself two things: what should filter the target viz, and what should not? If the answer splits those two, "selected fields" is almost always the right configuration choice.
- Which configuration best provides this behavior?
Answer: Create a URL action that runs on Menu and insert the account identifier into the URL.
When a question describes a link in a tooltip that must open an external system using a dynamic value and only when the user deliberately clicks, you're being tested on two things simultaneously: the correct action type and the correct run trigger.
URL actions are Tableau's mechanism for opening external URLs from a dashboard. They allow you to embed field values directly into the URL using the syntax <Field Name>, making the link dynamic per selected mark. The trigger options — Select, Hover, and Menu — control when the action fires. "Menu" places a named link inside the tooltip that only executes when the user explicitly clicks it, which is exactly what the passage requires. D is correct: a URL action with Menu trigger and the account identifier inserted into the URL satisfies every requirement.
A is wrong because it uses the Hover trigger. Hover fires automatically when the user moves their cursor over a mark — there's no deliberate click involved, so the link would open unintentionally and constantly.
B is wrong on two counts: filter actions filter data within Tableau sheets; they don't open external systems. Additionally, even if a filter action could target an external URL (it can't), it has no mechanism for constructing a dynamic external link.
C is wrong because Tableau does not automatically detect or append field values to a static URL typed into the tooltip text box. Without configuring a URL action, the identifier simply won't be included dynamically.
A useful rule of thumb: whenever you need a dynamic external link on deliberate click, think URL action + Menu trigger. Those two decisions together are the complete solution.
- What should the author do?
Answer: Select the target line's Marks card and clear Show Tooltips for that marks layer.
When working with dual-axis charts in Tableau, remember that each axis gets its own independent Marks card. This separation is the key insight for any question about controlling behavior — formatting, mark type, color, or tooltips — differently across two overlaid measures.
Because each Marks card operates independently, you can toggle tooltip visibility per layer. On the target line's Marks card, simply unchecking "Show Tooltips" silences that layer's tooltip while leaving the sales circles' tooltips completely intact. That's exactly what option A describes, making it the correct approach.
Option B is far too destructive — disabling tooltips at the worksheet level removes them for all marks, not just the target line, and captions are a poor substitute for interactive tooltips that appear on hover. Option C misunderstands the problem entirely: moving the target to Detail removes it from the axis, which would eliminate the line from the visualization rather than just suppressing its tooltip. Option D is a visual trick, not a functional solution — making a mark transparent hides it visually but doesn't disable its tooltip; users hovering in that area could still trigger an unwanted popup, and you'd also lose the visible target line the author wants to keep.
A useful pattern to remember: whenever a Tableau question involves treating two overlaid measures differently, your first instinct should be the individual Marks cards. Tableau's dual-axis architecture is specifically designed to let authors customize each layer independently, and exam questions frequently test whether you know that granularity exists at the marks layer level, not just the worksheet level.
- Which annotation strategy is most appropriate?
Answer: Create an area annotation around the rectangular operating range.
When Tableau asks about annotations, the key distinction to understand is that there are three annotation types — mark, point, and area — and each serves a fundamentally different purpose. Mark annotations attach to specific data points, point annotations attach to arbitrary coordinates, and area annotations describe a region of the view. Recognizing which unit you're describing (a store, a coordinate, or a zone) tells you which annotation type to reach for.
Here, the analyst wants a single label describing a rectangular zone, not any individual store. That's precisely what an area annotation is built for — you drag to define a rectangular region on the canvas and attach descriptive text to that space as a whole. Answer A is correct because it matches the annotation type to the object being described: a zone, not a mark.
Answer B falls into a common trap: placing a mark annotation on the "center store" might look visually centered, but it ties the label to a data point. If that store's data changes or it moves out of the range, the annotation shifts with it — the zone label becomes unreliable. Answer C compounds the problem by multiplying point annotations at each corner, creating four separate labels instead of one unified callout, which is the opposite of what the scenario requires. Answer D takes the mark annotation trap to its extreme — annotating every store inside the range defeats the entire purpose of having a single, clean zone description.
As a study strategy, remember: mark = one data point, point = one coordinate, area = a region. Exam questions often describe a spatial or logical grouping and test whether you reach for area instead of defaulting to mark annotations.
- How should the author make the displayed sales amount respond to changes in the view?
Answer: Edit the annotation and insert the aggregated Sales field as dynamic text.
When you see a question about annotations in Tableau, ask yourself: is the displayed value static (typed manually) or dynamic (pulled from the data)? That distinction is exactly what this question tests.
Annotations in Tableau support dynamic field insertion, meaning you can embed actual measure or dimension values that update automatically as filters change. When you edit a mark annotation and insert the aggregated Sales field using the Insert menu, Tableau replaces the hardcoded text with a live reference to whatever value the mark currently holds. So when the date filter changes and Sales becomes $385,000, the annotation reflects that instantly. That's why C is correct — it directly solves the problem by making the annotation responsive to the data.
A is a trap because switching to a point annotation at the mark's coordinates still doesn't make the dollar amount dynamic — you'd still be manually typing a static number, just at a different anchor type. The annotation type isn't the issue; the static text is.
B misunderstands the problem entirely. Adding Sales to Detail adjusts what Tableau encodes in the view, but it does nothing to update manually entered text inside an annotation. The typed "$420,000" stays frozen regardless of what's on the Marks card.
D is a workaround that doesn't actually fix the annotation — it redirects attention to the caption, which is a separate element, and leaves the broken annotation in place. Captions also aren't tied to individual marks.
Your study tip: whenever you see annotation behavior on the exam, think Insert menu = dynamic, typed text = static. That single distinction will resolve most annotation questions quickly.
- Which type of annotation should the author use?
Answer: A point annotation anchored at the desired axis location
When working with Tableau annotations, the key distinction to understand is that each annotation type is designed for a specific anchoring behavior. Recognizing what you're attaching an annotation to will always point you to the right choice.
In this scenario, the author wants to label a specific coordinate location — a combination of profit and sales values — where no actual data mark exists. This is precisely the use case for a point annotation. A point annotation in Tableau anchors directly to a set of axis coordinates, independent of any data mark, making D the correct answer. It lets you pinpoint an exact (x, y) location on the plot and label it meaningfully, like flagging a strategic target on a scatter plot.
The wrong answers each reflect a misunderstanding of how the other annotation types work. A describes a mark annotation, which must attach to an existing data mark on the view — it cannot float at an empty coordinate. Since no data mark exists at the desired location, this type simply won't work here. B describes an area annotation, which covers a rectangular region of the view rather than a precise point; it's useful for highlighting zones or quadrants, not a single coordinate pair. C is a fabricated option — Tableau does not have a "caption" annotation type. Captions in Tableau are view-level text objects, not coordinate-anchored annotations.
A helpful memory hook: think of the three real annotation types by what they attach to — a mark (existing data point), an area (a region), or a point (any coordinate). Match the annotation to what you're targeting, and you'll never mix them up.
- Which change most directly addresses the blank tooltip while preserving state-specific filtering?
Answer: Revise the target worksheet's inactive-state filter so it does not conflict with the passed State.
Whenever you see a question about Viz in Tooltip behavior, focus on the data flow between the source sheet and the target (embedded) worksheet. The source sheet passes a filter value — here, the hovered State — to the target worksheet, which then renders based on its own filters and data. If the target worksheet has a conflicting filter that excludes the very value being passed, the result is a blank viz.
That's exactly what's happening here. The target trend worksheet has a fixed filter that excludes inactive states. When you hover over an inactive state on the map, the source sheet correctly passes that State value to the target — but the target's fixed filter blocks it before any marks can render. The historical sales data exists, but the filter prevents it from appearing. Revising that fixed filter (answer C) so it doesn't conflict with the dynamically passed State value directly resolves the blank tooltip while still allowing state-specific context to display correctly.
Answer A is a red herring — expanding the source tooltip filter to all available fields doesn't resolve the target worksheet's internal filter logic, which is where the conflict lives. Answer B misdiagnoses the problem entirely; the tooltip isn't blank because of display space — no marks are reaching the view in the first place. Answer D, converting State to an attribute, affects how values are aggregated in the source view but does nothing to change the target worksheet's fixed filter that's blocking the data.
A useful rule of thumb: when a Viz in Tooltip renders blank, always ask whether the target worksheet's own filters could be excluding the value being passed from the source. That's the most common culprit.
- Which approach best satisfies the requirements?
Answer: Add a mark annotation to the West region mark and insert the relevant field values.
Tableau offers three types of annotations — mark, point, and area — and knowing the behavioral differences between them is key to answering questions like this one. The critical requirements here are two: the callout must move with the mark as axis ranges change, and it must disappear if the mark is filtered out.
A mark annotation is anchored directly to a specific data point (the mark itself). When that mark moves because the axis rescales, the annotation travels with it. More importantly, if the mark is removed from the view by a filter, the annotation vanishes too, because it has no mark to attach to. This is exactly what the question demands, making B the correct approach. Inserting field values (like region name and sales figure) also keeps the label dynamic rather than hardcoded.
A is tempting but wrong: a point annotation is pinned to fixed axis coordinates, not to a data mark. If the axis rescales or the mark shifts, the annotation stays at those original coordinates — it won't follow the data. It also remains visible even after the mark is filtered out, failing both requirements.
C describes an area annotation, which is anchored to a region of the canvas defined by axis positions and header values. Like a point annotation, it doesn't truly follow a mark and won't disappear when the mark is filtered away.
D is incorrect because a worksheet caption is static descriptive text that appears below the view. It has no connection to individual marks and satisfies neither requirement.
Your study tip: memorize this hierarchy — mark annotation follows the mark, point annotation follows coordinates, area annotation follows a canvas region. Filter behavior is the deciding factor on exam questions.
- Which configuration best meets both requirements?
Answer: Keep tooltips enabled but clear the option to include command buttons.
When publishing worksheets in Tableau, tooltips have two distinct components: the explanatory content (text, formatting) and command buttons (Keep Only, Exclude, View Data, etc.). Questions like this test whether you know these can be configured independently — you don't have to choose between tooltips working or not working.
Tableau's tooltip settings include a checkbox labeled "Include command buttons" that controls whether interactive commands appear when users hover over marks. Clearing this option removes Keep Only, Exclude, and similar commands while leaving your custom tooltip text fully intact. That's exactly what the scenario requires — explanatory tooltips stay visible, but commands that could alter the view are hidden. So D is correct: keep tooltips enabled, but uncheck the command buttons option.
A is wrong because clearing Show Tooltips disables tooltips entirely, which directly violates the first requirement. Moving text to the caption is a poor substitute — captions are static and don't respond to mark hover interactions. B misunderstands the problem: removing dimensions from the Marks card would strip context from your visualization and doesn't selectively remove command buttons from tooltips — it changes what marks exist and what data they encode. C introduces a fictional setting — "disable selection by category" isn't a Tableau tooltip configuration option, and leaving all command buttons enabled contradicts the second requirement entirely.
The key study tip here: on Tableau exam questions involving tooltips, always remember that content and commands are separate settings. Whenever a scenario asks you to show information but restrict interactivity, look for the granular option that toggles commands independently rather than disabling the whole feature.
