Scenario practice questions

Create a Databricks job that runs every five minutes, downloads the latest model version, and calls the Model Serving REST API to overwrite the endpoint configuration with the new numeric version.

Why it fails: A periodic job that rewrites the endpoint configuration adds latency between promotion and serving, requires compute and credentials, and risks race conditions during redeploys. It also duplicates functionality that aliases already provide natively. This is operationally heavier and less reliable than serving an alias, and it briefly disrupts the endpoint on every update.

Serve the model by name with the version pinned to the numeric version that is currently in production, then re-create the endpoint whenever a new version is registered.

Why it fails: Pinning to a numeric version freezes the endpoint to that exact artifact, so a newly promoted version is never served until someone edits or recreates the endpoint. That directly violates the requirement for automatic pickup. Numeric pinning is appropriate for reproducible rollbacks, but not for a continuously promoted production model that must follow the latest champion.

Export the MLflow model to a local directory, upload the artifacts to DBFS, and configure the endpoint to load the model from that DBFS path.

Why it fails: Model Serving endpoints are configured with registered model entities or serving features, not raw DBFS artifact paths. Even if artifacts live in cloud storage, the endpoint needs registry metadata, signatures, and dependency information to build the serving container. Manually copying artifacts bypasses lineage and versioning and cannot satisfy automatic promotion-driven updates.

MLflow Model Registry webhooks that notify an external service whenever a model version is registered, letting that service host the model.

Why it fails: Webhooks only emit event notifications; they do not host or serve a model. Using them would require building and operating an external inference service, which contradicts the requirement to manage the endpoint natively in Databricks. Webhooks are useful for triggering CI/CD or retraining workflows, but they provide no prediction API or scale-to-zero behavior on their own.

A Databricks job that runs a Python script loading the model and starting a Flask web server on a driver node, exposed via a public URL.

Why it fails: Running Flask on a job cluster driver is not a supported production serving pattern: the URL is not stable, the cluster terminates, and there is no built-in authentication or autoscaling. It also cannot scale to zero in a managed way. This approach lacks the reliability, security, and lifecycle management that a native serving endpoint provides.

A SQL warehouse with a user-defined function that loads the model artifact and returns predictions for incoming queries.

Why it fails: SQL warehouses execute SQL workloads and cannot load arbitrary Python model artifacts as a general inference engine, nor do they expose a model prediction REST API with cold-start semantics. While some AI functions exist, they do not replace Model Serving for custom registered models. This choice misuses the warehouse and cannot deliver the required endpoint behavior.

SparkTrials automatically selects the best hyperparameters.

Why it fails: SparkTrials does not inherently select the best hyperparameters; it merely coordinates the parallel execution of the search space defined by the user. The selection of the best model is still based on the objective function and the optimization algorithm specified within the hyperparameter tuning configuration provided by the scientist.

SparkTrials provides built-in visualization of the parameter space.

Why it fails: Visualization of hyperparameter results is typically handled by MLflow's UI or other dedicated plotting libraries like matplotlib. SparkTrials focuses on the backend compute orchestration and parallel task scheduling, rather than front-end reporting or graphical representation of the search space, which remains separate from the core optimization engine functionality.

SparkTrials forces the use of a GPU-enabled cluster.

Why it fails: SparkTrials is compute-agnostic and can run on clusters with or without GPUs. While GPUs might accelerate specific training tasks, SparkTrials does not enforce a hardware requirement; it simply manages the distribution of tasks to whichever executors are available in the current Databricks cluster configuration for the user.

Configure a provisioned throughput endpoint to reserve dedicated capacity for the model.

Why it fails: Provisioned throughput reserves dedicated capacity to deliver predictable, low-latency performance, but it keeps resources allocated and is not compatible with scaling down to zero replicas when idle. The scenario prioritizes scaling to zero, so reserving dedicated capacity conflicts with that goal. Provisioned throughput is better suited to steady, latency-sensitive workloads that must avoid cold starts entirely.

Increase the workload size to Large to reduce cold-start latency when scaling up from zero.

Why it fails: Workload size controls the CPU and memory allocated per replica, not how quickly the endpoint initializes after scaling from zero. A larger workload size may even lengthen container startup because more resources must be provisioned. It does not provide payload logging, and it does not by itself enable scaling to zero. The scenario's two requirements are met by scale-to-zero and inference tables, not by resizing the workload.

Set the endpoint's minimum replicas to one so that a warm replica is always available.

Why it fails: Keeping a minimum of one replica prevents the endpoint from ever reaching zero, which contradicts the explicit requirement to scale down to zero when idle. While it would reduce cold-start latency by keeping compute warm, it sacrifices the cost-saving behavior the team asked for. This setting is the opposite of scale-to-zero and therefore cannot be one of the correct choices here.

It is always the cheapest option for low-traffic models.

Why it fails: Provisioned throughput is usually more expensive than serverless options because it involves paying for dedicated reserved capacity. For low-traffic models, a serverless or auto-scaling endpoint is generally more cost-effective as it can scale down to zero when not in use, avoiding unnecessary costs for idle resources.

It eliminates the need to provide a model signature.

Why it fails: The requirement for a model signature is determined by the MLflow model format and the serving framework, not by the chosen infrastructure type. Regardless of whether you use provisioned or serverless endpoints, you must always define a model signature for schema validation and robust inference behavior.

It is the only way to deploy non-Python models.

Why it fails: Databricks supports a variety of models through its MLflow integration, and infrastructure selection (provisioned vs. serverless) does not restrict the programming language or model type. The core requirement is that the model is correctly logged using the appropriate MLflow flavor to be served regardless of deployment mode.

A Unity Catalog volume holding Parquet files of the computed features.

Why it fails: Volumes store arbitrary files and are not tables, so other notebooks cannot query them with SQL or join them directly without reading and parsing files. They also lack schema enforcement, primary-key semantics, and time-travel features that Delta tables provide. This approach adds manual file management and does not deliver the scheduled, queryable feature table the scenario requires.

A Delta Live Tables pipeline with expectations defined on each feature.

Why it fails: Delta Live Tables is a pipeline framework for building reliable data transformations, and expectations enforce data quality, but it is not a feature catalog. It does not provide point-in-time joins, feature discovery by name, or the training-serving consistency guarantees of the Feature Store. Using it here would reinvent feature management primitives that the platform already provides.

An MLflow experiment with logged artifacts containing the feature vectors.

Why it fails: MLflow experiments track runs, parameters, metrics, and artifacts for model development, not reusable feature datasets. Artifacts are files attached to runs and are not queryable tables, so other jobs cannot join them efficiently. This would duplicate feature data per run and provide no refresh schedule or feature discovery, entirely missing the requirement.

mlflow.start_run() and mlflow.end_run()

Why it fails: mlflow.start_run() and mlflow.end_run() delimit a run but do not log any data by themselves. They are necessary to create a run context, but without additional logging calls, no parameters or metrics are recorded. They do not satisfy the need to capture hyperparameters and metrics, and they do not prevent artifact saving if other calls are used.

mlflow.log_artifact() and mlflow.log_model()

Why it fails: mlflow.log_artifact() saves an arbitrary file as an artifact, while mlflow.log_model() persists a model in MLflow format. Both operations create artifacts in the run's artifact store, which directly contradicts the requirement to avoid saving model artifacts. They are used when you need to store files or models, not for lightweight metadata logging.

mlflow.set_tag() and mlflow.set_experiment()

Why it fails: mlflow.set_tag() adds a tag to a run, and mlflow.set_experiment() sets the active experiment for subsequent runs. Neither function logs hyperparameters or metrics; tags are metadata for organization, and set_experiment only changes the default experiment context. They are useful for categorization but do not record the numeric values required for model evaluation.