ML Workflows
Free Databricks Certified Machine Learning Associate practice — 6 questions on ML Workflows, with explanations. No sign-up. Full 12-question mixed test →
A data scientist is building a churn model. Before splitting the data into train and test sets, they compute the mean target value for each category of a high-cardinality 'customer_segment' column across the FULL dataset, and use these means as a new numeric feature. The model achieves 98% AUC on the test set but performs poorly in production. What is the MOST likely cause and correct fix?
Computing target-mean encodings on the entire dataset (including test rows) leaks information about the test labels into the training features, inflating validation metrics. The correct approach is to fit the encoding strictly on the training split (or within each CV fold) and apply the already-fitted mapping to validation/test data, exactly as with any other transform requiring fit/transform separation.
A team needs to impute missing values in a 500-million-row Spark DataFrame for two numeric columns, replacing missing values with the column median computed at scale, and wants the fitted imputation logic reusable inside an MLflow pipeline stage. Which approach should they use?
pyspark.ml.feature.Imputer is the distributed, scalable estimator designed for this exact use case: it computes statistics (mean or median) in a distributed manner, supports strategy='median', and produces a fitted ImputerModel that can be composed as a Pipeline stage, ensuring the same imputation is consistently applied to train/validation/test/production data without recomputation or leakage.
A data scientist converts a 50GB pandas DataFrame to pandas API on Spark using ps.from_pandas(df) so multiple analysts can run distributed transformations on it. They notice that a downstream groupBy-and-sort operation runs extremely slowly, funneling almost all computation through a single task. What Spark configuration is the most likely cause and correct adjustment?
The pandas API on Spark 'compute.default_index_type' option controls how the default index is generated. The default 'sequence' type computes a monotonically increasing index that requires a single-partition pass, creating a bottleneck on large conversions. Setting it to 'distributed' (or 'distributed-sequence') allows index creation to happen in parallel across partitions, which is the documented performance recommendation for large from_pandas conversions.
A retailer wants to forecast next month's sales using two years of daily historical data with strong seasonal and trend patterns. An analyst uses sklearn.model_selection.train_test_split(df, test_size=0.2, random_state=42) with shuffle=True (the default) to create train and test sets. What is the primary problem with this approach for this modeling goal?
For time-dependent data, a random shuffle-based split violates the temporal ordering: rows from later dates can end up in the training set while earlier dates end up in test, so the model effectively 'sees the future' during training. The correct approach is a chronological split (e.g., train on the first N months, test on the most recent period) or a time-series-aware cross-validation strategy.
A team registers features in Databricks Feature Store for a fraud detection model. When constructing a training set with FeatureLookup, they must ensure that each labeled transaction only receives feature values that were known at the time the transaction occurred, not values computed afterward. Which mechanism enables this?
Feature Store's FeatureLookup supports a timestamp_lookup_key parameter that performs a point-in-time join, matching each label row to the most recent feature values available as of that row's timestamp, preventing future feature leakage automatically as part of create_training_set().
Which statement BEST describes why fitting a StandardScaler (or any Spark ML feature transformer) only on the training set, then using .transform() with that already-fitted model on the validation and test sets, is the correct practice to avoid data leakage?
Data leakage occurs whenever information from validation/test data influences how a model or preprocessing step is fit. Deriving scaling statistics from the full dataset (including validation/test) would let the model indirectly 'see' those data points' distributional properties, inflating evaluation metrics. Fitting exclusively on training data guarantees an honest estimate of generalization performance.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →