Free Databricks Machine Learning Associate practice test

Feature tables require a primary key definition so that lookups can join a batch of entity IDs to the correct feature rows; the key can be any appropriately named column(s), it does not need to be literally called 'id'. There is no requirement that features be string-typed, and partitioning every column is not a feature table requirement (and would typically hurt, not help, performance).

Databricks Runtime for Machine Learning (ML Runtime) ships with common ML libraries (scikit-learn, XGBoost, MLflow, etc.) preinstalled, so no manual library management is needed. The standard runtime, even with Photon (a query-execution accelerator, not an ML library set) or a longer autotermination window, does not include these libraries. Disabling autoscaling is an unrelated scaling setting and does not itself add libraries.

The MLflow Experiments UI lists runs with parameters and metrics and supports comparison to select the best model. Delta Sharing (A), cluster metrics (C), and Git history (D) don't compare experiment runs.

mlflow.pyfunc.load_model() loads any MLflow-logged model as a generic Python function (pyfunc) wrapper, exposing a unified .predict() interface regardless of the original ML framework. This is the correct approach for framework-agnostic inference. Option C would work for XGBoost-specific loading but returns a native XGBoost Booster object, requiring the caller to know the framework. Option B would fail or behave incorrectly because the model was not saved with the sklearn flavor. Option A (mlflow.load_model) does not exist as a top-level MLflow function; this is a common misconception.

Unity Catalog is Databricks' unified governance layer that supports registering and governing models (via Unity Catalog Model Registry), feature tables (Feature Store in Unity Catalog), and Delta tables (datasets) under a single three-level namespace with consistent GRANT/REVOKE access control — this satisfies the unified access control requirement (Option F). Unity Catalog also provides automated data lineage that tracks column-level and table-level lineage across Spark operations, Delta Live Tables, and MLflow, connecting training datasets to model versions — this satisfies the lineage requirement (Option D). Option A is wrong because using separate systems (workspace ACLs + IAM) is the fragmented approach the question specifically asks to avoid. Option C is wrong because automated lineage IS available in Unity Catalog; manual tagging is a workaround, not a best practice. Option B is factually wrong — Unity Catalog does support ML asset governance natively. Option E describes a valid logging pattern but does not provide automated lineage or unified access control.

Option B is correct: passing registered_model_name to mlflow.sklearn.log_model() simultaneously logs the model as an artifact and registers it in the Model Registry in one call. Option C is a valid two-step approach but does not accomplish the task 'in a single call' as the question requires. Option A is incorrect because mlflow.log_artifact() is for files/directories and does not accept a Python object or a registered_model_name parameter. Option D misuses mlflow.set_registry_uri(), which sets the URI of the model registry server, not the model name; it does not trigger registration.

In MLflow 2.x, the recommended way to designate a model version for a role (such as production) is through aliases using client.set_registered_model_alias(). This assigns a human-readable alias (e.g., 'Champion') to a specific version number, allowing code to reference the model by alias rather than hard-coded version number. Option C uses the older stage-based API (Staging/Production/Archived) which is deprecated in MLflow 2.x in favor of aliases. Option B is incorrect because set_model_version_tag() adds a key-value metadata tag to a version — it does not create a functional alias that can be used to load the model by name. Option D is incorrect because update_model_version() is used to update the description field of a model version, not to assign an alias.

GPU-enabled ML Runtime clusters include GPU drivers and deep-learning libraries built for hardware acceleration, which materially speeds up training for frameworks like PyTorch or TensorFlow. Adding more CPU workers helps with data-parallel Spark workloads but does not accelerate the tensor operations deep learning relies on, and a bigger CPU driver or more cores on a single node does not substitute for GPU acceleration.

Log transformation (D) and power/Box-Cox transformations (E) are the standard, widely accepted techniques for reducing positive skewness in a continuous variable before linear modeling — they compress the long right tail and make the distribution more Gaussian-like. Option B (capping at 95th percentile) is a form of winsorizing used for outlier handling, not skewness correction, and discards information. Option A (dropping rows above mean+1 SD) would remove a large portion of valid data (roughly 16% by definition) and introduces significant bias. Option F (binning into categorical) loses the continuous nature of the variable and may not be appropriate for linear regression. Option C (z-score standardization) changes the scale and center but does NOT change the shape or skewness of the distribution.

The correct pairings are: (1) loan_amount (continuous) vs. loan_default (binary) → Point-biserial or Pearson correlation is appropriate; Pearson is a valid approximation for a binary outcome treated as 0/1 numeric and a continuous predictor. (2) employment_type (nominal categorical, no ordering) vs. loan_default (binary categorical) → Cramér's V is the correct measure of association between two categorical variables. (3) credit_grade (ordinal: A > B > C > D) vs. loan_default (binary, can be ranked) → Spearman rank correlation is appropriate when at least one variable is ordinal, as it respects the ordering of ranks. Option B incorrectly assigns Pearson to a nominal categorical variable (employment_type), which is invalid. Option C uses Cramér's V for a continuous vs. binary comparison and Spearman for a nominal variable, both of which are mismatches. Option D assigns Spearman to a nominal variable (employment_type has no ordering), which is incorrect.

One-hot encoding creates a binary column per category, avoiding a false ordinal relationship. Ordinal 1/2/3 (A) implies an order the colors lack, dropping (B) loses signal, and 'standardizing strings' (D) isn't a numeric encoding.

VectorAssembler takes multiple input columns — including both scalar and vector-type columns — and concatenates them into a single dense or sparse vector column. It is the standard Spark ML way to merge the outputs of parallel preprocessing branches (e.g., scaled numerics and one-hot-encoded categoricals) before feeding them to a model. Option C (VectorIndexer) automatically identifies and indexes categorical features within an existing feature vector; it does not combine separate columns. Option D (PCA) is a dimensionality reduction transformer that operates on a single existing feature vector; it does not assemble columns. Option A (ColumnTransformer) is a scikit-learn concept (not native to Spark ML) that applies different transformers to different columns; in Spark ML, VectorAssembler serves an analogous assembly purpose.

Options A, D, and F are correct. DeepSpeed ZeRO (stages 1–3) partitions optimizer states, gradients, and/or parameters across devices, directly reducing per-GPU memory usage — stage 3 can train models far larger than single-GPU memory. PyTorch FSDP (accessible via TorchDistributor on Databricks) similarly shards parameters, gradients, and optimizer states across all GPUs. Model parallelism (pipeline or tensor) distributes model layers or tensor partitions across GPUs so no single device holds the full model. Option B (Horovod AllReduce) is wrong for this scenario because AllReduce is data-parallel and requires each GPU to hold a full model replica — it does not address models that exceed single-GPU memory. Option E (gradient accumulation) addresses batch size, not model size; the model parameters must still fit in GPU memory. Option C is wrong; the Spark driver is a CPU-based JVM process and is not used for GPU-based deep learning training — increasing driver memory has no effect on GPU memory for model parameters.

Predicting a continuous numeric value is regression. Classification (D) predicts a category, clustering (B) groups unlabeled data, and dimensionality reduction (C) compresses features.

CrossValidator evaluates every combination in the ParamGrid across every fold. The ParamGrid produces 3 × 4 = 12 distinct hyperparameter combinations. With numFolds=5, each combination is trained and evaluated 5 times (once per fold). Therefore, 12 × 5 = 60 total models are trained. Training only 12 models ignores that each combination is trained separately for each fold — the whole purpose of k-fold CV is to evaluate each combination k times. 17 is an additive miscalculation with no basis in how CrossValidator works. 24 confuses k-fold CV with a single train/validation split and misapplies a factor of 2.

Hyperopt's fmin() always minimizes the returned loss value. When returning a dictionary, the correct format is {'loss': <value_to_minimize>, 'status': STATUS_OK}. Since RMSE should be minimized (lower is better), returning {'loss': rmse, 'status': STATUS_OK} is correct. Option D (returning RMSE directly as a float) is also technically valid since fmin() can accept a plain float return — but the dictionary format with STATUS_OK is the canonical and recommended approach and is what the exam tests. Option A and C return negative RMSE, which would cause Hyperopt to search for configurations that maximize RMSE (minimize negative RMSE = maximize RMSE), which is the opposite of the desired behavior. The dictionary form in Option B is the most complete and correct answer.

SparkTrials (option B) is the correct Hyperopt object that distributes individual trial evaluations across Spark workers, enabling parallelism. The training function must be picklable (option C) because Spark serializes and sends it to worker executors — non-serializable objects like open file handles or certain class instances will cause failures. Option D is wrong — plain Trials runs all evaluations sequentially on the driver. Option F is wrong — SparkTrials runs trials in parallel on workers, not sequentially on the driver. Option A is a true statement about SparkTrials (parallelism parameter), but it is less critical as a 'constraint' than the serializability requirement; it describes a feature, not a constraint. Option E is wrong — SparkTrials distributes work to worker nodes, including their GPUs if available.

Option B is correct: LinearSVC is a large-margin classifier whose output is a signed distance from the decision boundary (stored as rawPrediction), not a probability. It fundamentally does not produce calibrated probabilities. Option F is also correct: PySpark's BinaryClassificationEvaluator uses the rawPrediction column (which LinearSVC does populate) to compute AUC-ROC, so evaluation is still possible. Option C is wrong; standardization controls feature scaling and has no effect on probability output. Option D is a real technique (Platt scaling) but is not a built-in PySpark LinearSVC feature; applying OneVsRest wraps a different classifier entirely rather than calibrating LinearSVC. Option E is incorrect; calling .setProbabilityCol() on a fitted LinearSVC model does not generate probabilities — LinearSVC simply doesn't compute them. Option A is wrong because BinaryClassificationEvaluator CAN work with LinearSVC using the rawPrediction column.

Wrapping the MLflow model as a Spark UDF distributes scoring across the cluster and reuses the logged environment, giving scalable, consistent inference. It doesn't retrain per partition (C), it needs a logged model (A), and it scales beyond one row (B).

Structured Streaming can read a Delta table as an incrementally-updating source and score new rows as micro-batches arrive, achieving near-real-time latency (roughly seconds to a couple of minutes depending on trigger interval) without standing up a synchronous request/response service — exactly matching this requirement. Option 2 wrongly assumes any sub-few-minutes latency demands a synchronous API; streaming can hit this latency band without one. Option 3 is false — Delta tables support incremental/streaming reads, which is one of Delta Lake's defining capabilities. Option 4 is incorrect; this is a standard, well-supported Structured Streaming inference pattern.