Free Databricks Certified Machine Learning Professional practice test: 30 questions with answers

Logging the full pipeline with its signature and the code version lets the exact preprocessing and input schema be reproduced later. A bare model file, a screenshot, or cell output cannot reconstruct the transformations that produced the training features.

SparkTrials dispatches each trial to the cluster so that the search scales with the number of workers. Trials keeps results on the driver, and fmin alone or a Python loop runs evaluations on a single process rather than distributing them.

A pipeline bundles the fitted transformers with the estimator, so the same fitted steps are reapplied to new data and training statistics are not recomputed on the test set. Running transformers twice, copying data to the driver, and deploying without artifacts all misunderstand what a pipeline provides.

Computing statistics on all rows lets test-set information influence the training features, so evaluation looks better than real performance on new data. Missing values, training speed, and generalization are not the consequences of this leak.

Feature tables in Unity Catalog share governed features across models and support point-in-time joins for training data. Tuning, free storage, and replacing the model registry are not what feature tables provide.

Point-in-time lookups match each label to feature values that existed at its timestamp, which blocks future information from entering the training set. Using the latest values for every label reintroduces leakage, and cluster placement and model type do not determine the lookup behaviour.

The MLflow Experiments UI shows runs with their parameters and metrics in tables and charts, which supports comparison across a search. The serving page, pipeline event log, and cluster log track deployments, pipelines, and compute rather than experiment runs.

Pandas UDFs and mapInPandas process batches in parallel on executors and can load the model once per worker, which scales well. Collecting to the driver, copying the model into every row, and running a notebook per row each remove the parallelism or waste resources.

TorchDistributor and Horovod launch training across multiple workers and GPUs, which is the distributed approach the question asks for. A single GPU loop does not distribute training, while the MLflow UI and VACUUM do not train models.

A signature documents the expected inputs and outputs, which lets MLflow and serving reject malformed requests early. Encryption, licensing, and metric logging are unrelated to the signature.

Unit tests verify individual functions against known inputs and expected outputs, which is what this check requires. Load tests, penetration tests, and canary deployments test performance, security, and rollout, not the correctness of a single function.

Retraining should respond to evidence that the model is degrading, such as falling metrics or sustained input drift. Fixed calendars can waste effort or miss changes, retraining on every row is costly and noisy, and notebook formatting has no bearing on model quality.

Population stability index and the Kolmogorov-Smirnov test quantify how far a feature's distribution has moved, which is the basis of drift detection. Run times, column counts, and cell counts describe the workflow rather than the data.

Lakehouse Monitoring computes profile and drift metrics on a schedule and writes them to monitoring tables, which is how drift is observed. It does not replace time travel, train models, or manage cluster scaling.

Gated promotion with tests and approval, combined with aliases that point to tested versions, makes releases repeatable and reversible. Manual copies, skipping staging, and overwriting without a rollback path each remove the checks and the record that promotion depends on.

Targets in the bundle configuration keep the code identical across environments while the settings differ per target. Hardcoding values, personal notebooks, and cluster-level configuration each make deployments error-prone and tie the code to one environment.

Recording the data version ties each model to the exact data it learned from, which is essential for reproducibility and for explaining changes between versions. It does not reduce artifact size, speed up the UI, or act as a precondition for logging a run.

Unity Catalog centralizes model governance, so access controls and lineage apply consistently across workspaces. Hardware speed, automatic run deletion, and free external hosting are not features of the registry.

Repointing the alias to the last good version restores service quickly and keeps the faulty version available for analysis. Deleting the model, waiting, or retraining unchanged each leave users with degraded predictions for longer.

Scheduled jobs with failure notifications automate retraining and alert the owners, and retry settings handle transient failures without manual action. Manual notebooks, warehouse query history, and interactive driver logs do not automate or alert on the retraining workflow.

Large scheduled scoring with no latency target is well suited to batch jobs, and writing results to a table serves reporting directly. Sub-second per-request latency, per-click calls, and one-row-at-a-time forms all need an online endpoint instead.

Mosaic AI Model Serving exposes registered models as managed REST endpoints with autoscaling. The DBFS root, Delta Sharing, and the Jobs API log store or share data and job information rather than serving predictions.

A canary deployment exposes only part of the traffic to the new version so that its behaviour can be checked before a full rollout. Big-bang, untested blue-green, and nightly recreation all move every user at once or skip validation.

Signature compatibility catches request mismatches, and load testing verifies latency and errors under realistic traffic before users depend on the endpoint. Dashboard colours, file name length, and author experience do not reflect whether the model will serve correctly.

Logging the required dependencies with the model lets the serving environment build with them, which keeps the deployment reproducible. Copying a laptop's packages, disabling checks, and serving from a notebook all bypass the dependency record and break reproducibility.

Minimum and maximum capacity in the autoscaling configuration define how far the endpoint can scale with demand. The notebook language, time zone, and catalog name are not capacity settings.

A 400 response indicates the request does not match what the endpoint expects, so comparing the payload to the logged signature is the fastest test. Notebook history, dashboard themes, and training year do not explain a malformed request.

Blue-green deployment keeps a known-good version live until the replacement is verified, so a switch back is immediate. Deleting, overwriting in place, or renaming the old version all remove the fast path back to a working state.

Error rate and latency against agreed thresholds directly show that the new version is harming users, which justifies an automatic rollback. Notebook favourites, README dates, and tag counts say nothing about how the endpoint is performing.

The traffic configuration assigns percentages to served entities, which is how a canary or A/B split is set up on an endpoint. Language, Spark runtime, and catalog ownership settings do not control how requests are divided between versions.