- Which method most appropriately preprocesses annual income while limiting bias and avoiding validation leakage?
Answer: Estimate regional medians from the training set, use a training-set fallback median, and apply them unchanged to validation.
When preprocessing data for a predictive model, your guiding principle should be: statistics used for imputation must come only from the training set, and they must be applied consistently to new data. This prevents "validation leakage," where information from the validation set illegally influences your preprocessing and inflates apparent model performance.
Answer A is correct because it follows this principle precisely. You calculate regional medians using only training data, create a fallback median (also from training) for any region too sparse to estimate reliably, and then apply those fixed values to the validation set without recalculating anything. Since income varies substantially by region, regional medians are far more accurate imputations than a single global median — and because thirty percent of one region's data is missing, a fallback prevents errors when a region has no usable training records.
Answer B introduces leakage by computing medians from the combined training and validation sets. The validation set's values are "peeking" into the imputation step, which artificially optimizes preprocessing for data the model is supposed to encounter cold. This produces overly optimistic evaluation metrics.
Answer C is tempting because it avoids imputation entirely, but deleting thirty percent of records in one region creates severe selection bias — your model learns from a systematically unrepresentative sample of that region's customers, likely degrading churn predictions for exactly that population.
Answer D seems symmetrical but is subtly wrong: imputing validation records using validation-set medians means your validation preprocessing differs from what would happen in production, making the evaluation unrealistic.
Study tip: Any transformation — scaling, encoding, imputation — should be fit on training data only and applied to all other sets. Treat your validation set as if it arrived after deployment.
- Which sequence should be used to create the daily-sales date field?
Answer: Convert each timestamp with the store's time-zone rules, then extract the resulting local date.
Whenever you see a question about time zones and date reporting, your guiding principle should be: always convert first, then extract. The local calendar date is a product of the local time, not the server time — so you must establish the local moment before you can label it with a date.
Here's why B is correct: a UTC timestamp like 2024-03-10 02:30 UTC could represent March 9th in a U.S. store (behind UTC) or March 10th in a European store (ahead of UTC). You must apply each store's specific time-zone rules — including any daylight-saving offset in effect at that exact moment — to convert the timestamp into local time. Only after that conversion can you extract the correct local date. This sequence guarantees each transaction lands on the calendar day the customer actually experienced.
A fails because extracting the UTC date first locks you into the wrong date before any conversion happens. Attaching a time-zone label afterward doesn't fix a date that was already extracted incorrectly.
C is tempting but dangerous: a single fixed offset cannot represent multiple time zones, and it completely ignores daylight-saving transitions, which shift offsets seasonally. One constant subtracted from every timestamp will misclassify transactions near those transition boundaries.
D is a patch, not a solution. Adjusting only end-of-month transactions is arbitrary and misses countless misclassifications that occur at the start and end of every single day across all time zones.
Your study tip: on any time-zone question, ask yourself, "Have I established the local moment before I extracted anything?" If the answer is no, the logic is flawed.
- What cleaning action and revised descriptive metric are appropriate?
Answer: Recode the zeros as missing and report an average of 5.0 days.
Whenever you encounter data-cleaning questions, ask two things: (1) Should these values be excluded or imputed? and (2) Does the recalculation reflect that change? Both steps must be correct together.
Here, eight orders have a recorded delivery time of zero — not because they were delivered instantly, but because they haven't been delivered yet. The business definition explicitly limits the average to completed deliveries, so those zeros are not valid data points; they are placeholders for missing information. The right move is to recode them as missing and remove them from the calculation entirely. That leaves 100−8=92 completed orders with a total of 460 days, giving an average of 92460=5.0 days. That's exactly what answer B does — correct cleaning action, correct arithmetic.
A is wrong on both counts: retaining the zeros treats "not yet delivered" as a real duration of zero days, which violates the business definition and artificially pulls the average down to 100460=4.6 days.
C gets the cleaning step right (recode as missing) but uses the wrong denominator — dividing 460 by 100 instead of 92, producing 4.6 days. This is a classic trap: students apply the correct filter conceptually but forget to adjust the count.
D uses mean imputation, replacing zeros with the current average. That technique is sometimes used to preserve sample size, but it distorts the distribution and is inappropriate when the business rule says to exclude incomplete records outright.
The key study tip: on data-cleaning questions, always verify both the method and the recalculated statistic — a correct concept paired with a wrong number is still a wrong answer. - Which preprocessing workflow produces the intended conversion metric?
Answer: Deduplicate valid orders, create one purchase indicator per user, and left-join it to all assigned users.
When designing conversion metrics in A/B testing, your first instinct should be to map the metric definition precisely to your data pipeline. Here, the metric is percentage of assigned users who complete at least one valid purchase — so your denominator must be all assigned users and your numerator must be distinct purchasers, nothing else.
Option D achieves exactly this. By deduplicating valid orders (eliminating payment-retry duplicates) and collapsing each user to a single purchase indicator, you get a clean binary per user. Left-joining that indicator to the full assigned-user table ensures users with no event rows are preserved as non-converters rather than silently dropped. The result is:
Conversion Rate=All assigned usersUsers with ≥1 valid purchase
Option A goes wrong by deduplicating on purchase amount rather than on order identity — two different orders of the same dollar value would be incorrectly collapsed into one, distorting the numerator.
Option B divides by session totals instead of assigned users, which is the wrong denominator entirely. Session counts fluctuate independently of assignment, making this metric meaningless for measuring user-level conversion.
Option C removes users without event rows before calculating conversion. This inflates your conversion rate by shrinking the denominator — it excludes exactly the non-converters you need to count, introducing selection bias into the metric.
A reliable study tip: whenever a question involves user-level metrics, always ask yourself two things — who is in my denominator? and have I correctly deduplicated my numerator? These two checks will catch most preprocessing errors on exam questions like this. - Which preprocessing decision and transformed validation value are appropriate?
Answer: Fit the scaler on training data only and transform the validation value to 3.
Whenever you see a question about preprocessing in predictive modeling, ask yourself: whose statistics should define the transformation, and why? The core principle is that a scaler must be fit on training data alone, then applied consistently to all other datasets — validation, test, and future production data.
Here's why: standardization transforms a value using z=σx−μ. For a validation customer spending 80, you apply the training mean (50) and standard deviation (10): z=1080−50=3. This is exactly what A does — fit on training, transform consistently. It's the correct answer.
B is wrong because refitting the scaler on validation data introduces data leakage in reverse — you'd be using future information (validation statistics) to define your transformation, making the pipeline inconsistent. When new customers arrive, you won't have their aggregate statistics to refit on.
C is wrong for the same fundamental reason: fitting on combined training and validation data contaminates the scaler with validation information. This inflates your model's apparent generalizability and makes the pipeline unreproducible for new data.
D is a plausible-sounding but incorrect distractor. Capping at two standard deviations (μ+2σ=70) and transforming to 2 arbitrarily discards valid signal. Nothing in the problem justifies truncating the value, and this isn't a standard preprocessing rule.
Study tip: Always think of your scaler as a "frozen recipe" learned from training data only — it must never be recooked using validation or test ingredients. - Which preprocessing treatment is most appropriate for those days?
Answer: Flag the observations as stockout-censored and estimate demand from comparable in-stock periods.
Whenever you see a question involving historical demand data for an optimization model, ask yourself: does the recorded value actually reflect true demand, or was demand artificially constrained? This distinction is critical in prescriptive analytics.
When a store runs out of stock, customers who would have purchased the item simply can't. The register records zero sales, but true demand was almost certainly greater than zero. This is called censored data — the observation doesn't reveal the full signal, only a lower bound. If you feed these zeros into a reorder model as if they represent true demand, the model systematically underestimates demand and will keep setting reorder quantities too low, perpetuating the stockout cycle. Answer B correctly identifies this problem: flag those days as stockout-censored and estimate latent demand using comparable in-stock periods (e.g., similar days of the week, seasonality, or neighboring stores). This preserves the integrity of the demand signal the model actually needs.
Answer A is tempting but fundamentally wrong — it confuses sales with demand. Only completed transactions were recorded, not what customers wanted. Using sales as a proxy for demand is only valid when inventory was available. Answer C compounds the error by also deleting legitimate zero-demand days (perhaps the store was open but nobody wanted that item), which discards genuinely useful signal and introduces selection bias. Answer D overcorrects recklessly — substituting the historical maximum inflates demand estimates with no statistical justification, likely driving excess inventory and waste.
Your takeaway: in any data-quality question involving operational constraints (stockouts, capacity limits, survey non-response), always ask whether the recorded value was prevented from reflecting true demand — that's the censoring red flag.
- Which preprocessing approach best supports both metrics without inflating revenue?
Answer: Aggregate shipments to one order-level record, then left-join that result to the orders file.
When you join a one-to-many relationship — like orders to shipments — every extra shipment row duplicates the order's revenue, inflating totals. That's exactly what happened here: the row count jumped from 10,000 to 14,000, and revenue appeared to grow by 28% even though no new sales occurred. Your goal is to preserve order-level granularity while still capturing shipment details like on-time delivery status.
Option A is the correct approach because it solves the fan-out problem before the join ever happens. By aggregating the shipments file down to one row per order first — for example, taking the maximum or minimum ship date to determine on-time status — you then left-join that collapsed result to the orders file. The result is one row per order, revenue is counted exactly once, and the on-time indicator is cleanly derived. Both metrics are supported without distortion.
Option B is tempting but flawed. Using "distinct revenue amounts" doesn't reliably de-duplicate revenue; if two shipments happen to share the same amount, the logic breaks, and the approach is structurally fragile rather than principled.
Option C arbitrarily keeps only the first shipment row, which risks losing on-time delivery data from subsequent shipments — you can't determine true delivery status by ignoring part of the record.
Option D divides revenue by shipment count, which is a mathematical patch rather than a structural fix. It produces fractional, nonsensical revenue per row and still leaves you with multiple rows per order.
The study tip: whenever a join increases your row count unexpectedly, ask which side has multiple rows and aggregate that side before joining — don't try to correct inflation after the fact. - How should the analyst handle this record before calculating profit-margin metrics?
Answer: Correct net sales to 1,250 using the trusted fields and document the consistency rule.
When a transaction file contains a derived field — one calculated from other fields — your first job as an analyst is to verify internal consistency before trusting any aggregated metric. Here, the data dictionary defines net sales as quantity×unit price−discount, so you can immediately audit the record: 10×125−0=1,250, not 12,500. The recorded net sales is off by a factor of ten. Because the quantity and unit price are verified against the source invoice, those fields are your trusted anchor. The correct move — answer C — is to recalculate net sales as 1,250, correct the erroneous derived value, and document the consistency rule you applied. Using corrupted data to calculate profit-margin metrics would silently inflate results.
Answer A is wrong because Winsorizing addresses extreme-but-valid outliers in a distribution, not arithmetic errors. The issue here isn't that 12,500 is statistically unusual — it's that it contradicts the formula. Applying Winsorization would leave the mistake intact. Answer B is wrong because deleting the record wastes perfectly good data. The source fields are verified and reliable; only the derived field needs correction. Wholesale deletion is a last resort when the record cannot be salvaged, not when a simple recalculation resolves the problem. Answer D is wrong because it inverts the trust hierarchy. Derived fields depend on component fields — if the components are verified, the derived total must be recalculated from them, not treated as authoritative.
A useful rule of thumb: verified components outrank derived totals. When the calculation chain is broken, fix the output, not the inputs. - Which cleaning procedure is most defensible?
Answer: Trim whitespace, normalize case, and apply an audited mapping of known equivalent city labels.
When cleaning categorical data for aggregation, your goal is to collapse artificial variation (typos, inconsistent formatting) while preserving meaningful distinctions between genuinely different values. That balance is the core tension this question tests.
The most defensible approach is C: trim whitespace, normalize case, and apply an audited mapping of known equivalents. Trimming removes trailing spaces (catching "New York "), case normalization merges "New York" and "new york," and an explicit, human-reviewed mapping lets you deliberately decide that "New York" and "New York City" should—or should not—be combined. Every merge is transparent and reversible. This is why C is correct.
A is the most dangerous distractor. Unrestricted fuzzy matching with a broad threshold will automatically merge strings based on character similarity, which means "Newark" and "New York" could be collapsed into the same category—silently destroying real geographic distinctions. Fuzzy matching is a useful tool, but only when constrained and audited.
B sounds systematic, but uppercasing alone doesn't resolve the whitespace problem or distinguish "NEW YORK" from "NEWARK." It addresses only one dimension of variation and creates a false sense of standardization.
D assumes the reporting tool has geographic intelligence it almost certainly lacks. Most BI tools treat strings as literals—"New York" and "new york" remain separate buckets. Deferring cleaning to downstream software is not a strategy; it's neglect.
Your study tip: whenever a data-cleaning question mentions merging categories, ask whether the merge is controlled and auditable. Automated or passive methods that merge without human review are almost always wrong on these exams.
- Which preprocessing design best handles future unseen channel values?
Answer: Fit a fixed training-based encoder with an Other category and map unseen values to that category.
When you see a question about categorical encoding in a deployed ML pipeline, the core tension is between training-time consistency and production-time flexibility. The model was built expecting a fixed set of input columns — any preprocessing that changes that structure after deployment will break the pipeline or silently corrupt predictions.
The right approach is D: fit your encoder once during training and include an explicit "Other" bucket to absorb any value that wasn't seen in training. This means unseen channels like "Podcast" or "TV" get mapped to the Other category, the column count stays identical to what the model was trained on, and predictions flow through without errors. The model may not perfectly represent these new channels, but it degrades gracefully rather than failing.
A is flawed because replacing unseen values with the most frequent production channel is data leakage-adjacent thinking — it uses batch-level statistics that weren't available at training time and introduces inconsistency across batches. B is arguably the most dangerous trap: dynamically creating new columns at scoring time directly violates the fixed-schema requirement and would crash most deployed models, since the feature space no longer matches what the model expects. C sounds sophisticated but is actually a serious mistake — refitting the encoder on production data changes the encoding of existing categories (e.g., which integer Email maps to), which can silently corrupt all predictions, not just those for unseen values.
As a study tip: in deployment questions, always ask yourself "does this change the schema or statistics the model was trained on?" If yes, it's almost certainly wrong.
