- Which calculation applies the correct unit conversion before creating the datetime?
Answer: DATEADD('second', INT([Epoch Milliseconds] / 1000), #1970-01-01 00:00:00#)
When converting Unix timestamps in Tableau, you need to understand two things: what the Unix epoch is, and what unit your raw data is in. Unix time counts seconds elapsed since January 1, 1970, 00:00:00 UTC — that's your anchor date. If your field stores milliseconds, you must divide by 1,000 before passing the value to DATEADD as seconds.
C is correct because it does exactly this. INT([Epoch Milliseconds] / 1000) converts milliseconds to whole seconds, and DATEADD('second', ..., #1970-01-01 00:00:00#) adds those seconds to the correct Unix epoch origin, producing a valid Tableau datetime.
A skips the unit conversion entirely — it passes raw millisecond values as if they were seconds. A 13-digit number treated as seconds would place your date thousands of years in the future, not in the modern era. B makes two mistakes at once: it uses 'millisecond' as the date part, which Tableau's DATEADD does not support as a valid unit, and it anchors to January 1, 1900 — the Excel/Tableau serial date origin — rather than the Unix epoch of 1970. D attempts a type-cast shortcut using DATETIME(STR(...)), but STR() converts a number to a string, and DATETIME() cannot reliably parse an arbitrary numeric string into a meaningful date — this will return null or an error.
As a study tip, remember the two-part checklist for Unix timestamp conversions: ① divide milliseconds by 1,000 to get seconds, and ② always anchor to #1970-01-01 00:00:00#. Mixing up the epoch origin or skipping the unit conversion are the two most common traps on this type of question.
- Which approach best prevents further precision loss and preserves exact relationship keys?
Answer: Cast the database column to a character type in the query or source before Tableau reads it.
When Tableau ingests a numeric column, it stores values as 64-bit floating-point numbers, which can only represent about 15–16 significant decimal digits precisely. An 18-digit account identifier exceeds that limit, so Tableau silently rounds the trailing digits — meaning the damage happens at the moment of ingestion, before you ever interact with the field.
The only reliable fix is to prevent Tableau from treating those digits as a number in the first place. Option A does exactly that: by casting the column to a character/text type at the database or query level, the identifier is transmitted as a string of characters, not a floating-point value. No arithmetic representation ever occurs, so no precision is lost — every digit arrives intact and can be used for exact matching.
Option B is a common misconception. Displaying more decimal places doesn't recover precision; it just shows more digits of an already-corrupted stored value. The rounding happened in memory, not in the display format.
Option C sounds appealing but is fatally flawed: it converts a field that has already been rounded into a string. You're preserving a broken value — the final digits are already wrong. Converting downstream doesn't undo upstream precision loss.
Option D is a distractor that conflates geographic roles with data type handling. Geographic roles affect how Tableau maps or visualizes data; they have no effect on floating-point precision.
The strategic takeaway: whenever you see identifiers, codes, or keys stored as numbers, your instinct should be "this should be a string." Precision loss at ingestion is irreversible — fix it at the source, not after the fact.
- Which action will reliably restore the postal codes while assigning the appropriate data type?
Answer: Reconnect to the raw CSV, assign the column a String type, and rebuild the extract.
When Tableau reads a numeric column, it strips leading zeros because integers simply don't store them — 02108 becomes 2108 with no recoverable trace inside the extract. Fixing this requires going back to the data source and telling Tableau to treat the column as text before the extract is built, so the leading zero is preserved from the start.
That's exactly what C does: reconnecting to the raw CSV lets you set the postal code column to String at the source level, after which rebuilding the extract captures 02108 as a true five-character string. The data is correct at every layer — source, extract, and visualization.
A is tempting but flawed: a custom number format can display a leading zero visually, but the underlying field remains a number. Any calculation, join, or export that references the raw value will still see 2108, not 02108, making this a cosmetic fix rather than a real one. B is a nonsensical path — converting a postal code to a Date type produces errors or meaningless results; there's no logical intermediate step that yields a clean string. D has the same core problem as A: aliases only change the display label in a dimension, not the stored value, so the data integrity issue persists downstream.
The key principle to remember is that data type decisions must be made at the source, not patched afterward. Whenever a question asks you to "restore" or "correct" data that was misinterpreted during ingestion, the reliable fix is always to return to the source, apply the right type, and reload — not to apply a visual workaround on top of bad data.
- Which preparation creates a compatible relationship key without changing the Customers table?
Answer: Create RIGHT("00000" + STR([Customer ID]), 5) in Orders and relate it to the String key.
When building relationships across tables in Tableau, the joined fields must match exactly — same data type and same formatted value. Here, the challenge is padding a numeric [Customer ID] like 42 into the zero-padded string "00042" that the Customers table expects.
The reliable approach is to concatenate enough leading zeros and then trim to exactly five characters from the right. RIGHT("00000" + STR([Customer ID]), 5) works by first converting 42 to "42", prepending five zeros to get "0000042", then taking the rightmost five characters: "00042". This perfectly matches the Customers key, making C the correct answer.
A is flawed because it modifies the Customers table, which the question explicitly prohibits, and converting to a whole number drops leading zeros entirely — 00042 becomes 42.
B is a common trap. Applying a display format to a numeric field changes how it looks in a viz, but Tableau still uses the underlying numeric value 42 when evaluating relationship matches against a string "00042". Format masks never affect join logic.
D uses LEFT instead of RIGHT, which produces the wrong end of the padded string. LEFT("4200000", 5) gives "42000" — the opposite of what you need.
A good rule of thumb: when zero-padding strings, always anchor to the right side of the padded value, which is why RIGHT is your go-to function. Also remember that visual formatting in Tableau is purely cosmetic and never influences how relationship keys are compared.
- Which preparation strategy best satisfies both requirements?
Answer: Retain [Reading Text], create FLOAT([Reading Text]), and separately classify null originals versus failed conversions.
When working with mixed-content string fields in Tableau, your goal is to preserve information rather than collapse it. Ask yourself: what distinctions does the analyst need to maintain downstream? Here, two separate conditions matter — values that were never recorded (source nulls) and values that were recorded but meaningless (like "unknown"). Any strategy that merges these two conditions loses analytical precision.
Option B is correct because it uses a two-layer approach. Retaining [Reading Text] as the original string preserves the raw state of every record. Then, FLOAT([Reading Text]) performs the numeric conversion: valid text like "18.6" becomes 18.6, while "unknown" becomes null due to a failed cast. Now you have two null-producing scenarios you can distinguish — records where the original string was already null (source-missing) versus records where the original string existed but conversion failed (invalid text). A calculated field checking ISNULL([Reading Text]) separates these cleanly.
Option A fails because converting the field directly destroys the original string, making it impossible to tell whether a resulting null came from a source gap or a failed parse — exactly the distinction the analysts need.
Option C is worse still: replacing nulls and "unknown" with 0 actively fabricates numeric data, corrupting the measure entirely. A missing reading and an invalid reading are not zero readings.
Option D is a trap — you cannot format a string field as a numeric measure in Tableau. String fields don't participate in aggregations like SUM or AVG regardless of how they're formatted.
The key study tip: when a question involves preserving distinctions between data quality categories, the right strategy almost always involves keeping the original field and deriving a new one — never overwriting the source.
- Which expression uses an appropriate explicit pattern to parse the field as a datetime?
Answer: DATEPARSE("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", [Timestamp Text])
When working with DATEPARSE in Tableau, your job is to match every character in the format string to the corresponding part of the raw text — and the format tokens are case-sensitive in ways that matter enormously.
The timestamp 2025-07-09T16:04:27.125Z has a specific anatomy: a four-digit year, two-digit month, two-digit day, a literal T, a 24-hour hour, minutes, seconds, milliseconds, and a literal Z. For literal characters that aren't format tokens, you wrap them in single quotes. For milliseconds, SSS is the correct token. That logic maps perfectly to "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" — making B correct.
Here's where the distractors trip you up. A uses mm in the month position and hh for the hour. In Java-style date formatting (which Tableau follows), mm means minutes, not months — months require uppercase MM. Worse, hh is a 12-hour clock token; since the data uses a 24-hour clock, you need HH. A misassigns both. C avoids the issue of quoting literal characters by stripping the Z with REPLACE, but it also drops the entire time-precision portion — the pattern "yyyy-MM-dd HH:mm:ss" ignores milliseconds and assumes a space separator instead of T, so it will fail to parse the string even after the replacement. D has the right tokens for time but reverses the date order to dd-MM-yyyy, which doesn't match the year-first ISO 8601 structure of the source data.
A reliable memory trick: MM = Months (uppercase, like a proper noun), mm = minutes (lowercase, smaller unit), and HH always means 24-hour. Drill this case-sensitivity — it's one of the most common DATEPARSE traps on the exam.
- What is the appropriate correction?
Answer: Parse or assign both fields as Date & Time, then calculate the minute difference.
When working with date and time calculations in Tableau, the data type of your fields determines what information is actually stored and available for computation. If a field containing timestamp data (both date and time) is cast as Date only, Tableau discards the time portion entirely — treating 2025-08-01 23:50:00 and 2025-08-02 00:20:00 as simply 2025-08-01 and 2025-08-02. Any minute-level calculation then becomes meaningless, because the underlying granularity no longer exists.
The fix is straightforward: parse or assign both fields as Date & Time (also called datetime). This preserves the full timestamp, so DATEDIFF('minute', [Opened At], [Closed At]) correctly returns 30 minutes instead of the misleading 1-day equivalent. That's why A is the right answer — it restores the data type that the calculation actually requires.
B is a common trap: changing the display format of a Date field to show hours and minutes is purely cosmetic. It makes the field look like a datetime without actually storing time data, so calculations remain wrong. C is a fundamental misunderstanding — string subtraction is not a valid operation in Tableau, and formatted strings cannot replace proper datetime arithmetic. D fails because keeping the Date type and converting day differences to minutes produces a coarse approximation (whole days × 1,440) that ignores the real elapsed minutes and is mathematically incorrect for this scenario.
As a study tip: on Tableau exam questions involving time-based calculations, always verify the data type first. Display format and data type are separate concerns, and confusing them is one of the most common sources of incorrect results in practice.
- Which calculated field most reliably parses both formats?
Answer: IF CONTAINS([Order Date Text], "-") THEN DATEPARSE("yyyy-MM-dd", [Order Date Text]) ELSE DATEPARSE("MM/dd/yyyy", [Order Date Text]) END
When parsing mixed date formats in Tableau, your first instinct should be to ask: does every row share the same structure? If not, you need logic that identifies the format before parsing — and that's exactly what this question tests.
The reliable solution is B. It uses CONTAINS to detect which format each row uses, then routes it to the appropriate DATEPARSE call with an explicit format string. Because DATEPARSE ignores regional settings entirely, it produces consistent results regardless of the user's locale — exactly what the question requires.
A fails because DATE() leans on Tableau's implicit type-casting, which in turn depends on the computer's regional date settings. On a machine configured for day-first dates, 07/15/2025 could be misread or return null. This is precisely the dependency the question asks you to avoid.
C seems clever — replace / with - so everything looks like 2025-07-14 — but it breaks on the slash-format dates. 07/15/2025 becomes 07-15-2025, which doesn't match the pattern yyyy-MM-dd (it would need MM-dd-yyyy). One separator, two different orderings of year/month/day means a single DATEPARSE call still can't handle both.
D contains a critical error: it applies "dd/MM/yyyy" to slash-format dates, but 07/15/2025 is in MM/dd/yyyy order. Day 15 of month 07 works, but any date where the day exceeds 12 would either fail or silently produce a wrong date.
Study tip: On Tableau parsing questions, always check two things — does the solution handle format detection row by row? and does it eliminate regional setting dependency? If either answer is no, keep looking.
- Which calculation returns the embedded value as a date-compatible field?
Answer: DATEPARSE("yyyyMMdd", LEFT([Batch Code], 8))
When converting a string to a date in Tableau, your go-to function is DATEPARSE, which takes two arguments: a format string that describes the pattern of your date text, and the string itself. The format string uses tokens like yyyy (four-digit year), MM (two-digit month), and dd (two-digit day) — and the order of those tokens must exactly match the order of characters in your string.
Your batch code starts with eight characters in year-month-day order (e.g., 20250709), so the correct format string is "yyyyMMdd". You also need LEFT([Batch Code], 8) to extract those first eight characters. That's precisely what D does — making it the correct answer.
A is wrong on two counts: it uses "MMDDyyyy" (month-day-year order, which doesn't match), and it also uses an incorrect token DD — Tableau's format uses lowercase dd for day. B uses the right format string "yyyyMMdd" but calls RIGHT([Batch Code], 8) instead of LEFT. Since the date is at the beginning of the string, RIGHT would pull characters that include the -A suffix, breaking the parse entirely. C uses DATEPART instead of DATEPARSE — DATEPART extracts a numeric component (like the year or month) from an existing date field, not from a string. It's the wrong function for this job entirely.
A useful tip: on Tableau exam questions involving string-to-date conversion, always check three things — correct function (DATEPARSE), correct extraction side (LEFT vs. RIGHT), and correct format token order matching the actual string layout.
