Model Deployment practice questions

Re-train the model on a GPU cluster

Why it fails: Migrating a model to Unity Catalog is a metadata governance update, not a compute operation. The hardware used for training is independent of the registry location. You can migrate models regardless of whether they were trained on CPUs or GPUs, as the registry only stores the model artifacts and metadata.

Manually copy the MLflow artifacts to an external S3 bucket

Why it fails: Unity Catalog manages the storage of models automatically based on the catalog's configured storage location. Manual copying of artifacts is unnecessary and counter-productive, as it breaks the lineage tracking and governance provided by the platform. The platform handles backend storage synchronization whenever a model is registered or versioned.

Convert the model to an ONNX format

Why it fails: Unity Catalog supports various MLflow-compatible frameworks. Converting to ONNX is an optional optimization step for inference performance but is not a requirement for migrating an existing MLflow model into the Unity Catalog environment. The registry handles the native model flavor just as effectively as standardized exchange formats like ONNX.

The model name is too short

Why it fails: Databricks Model Serving does not impose a minimum character length constraint on model names beyond basic naming conventions. The provided name 'fraud-detection' complies with standard string requirements. Failure in deployment is typically related to resource availability, permission issues, or invalid schema definitions rather than simple string length constraints.

Scale-to-zero is not supported for production endpoints

Why it fails: Scale-to-zero is a fully supported and recommended feature for production endpoints in Databricks. It helps optimize costs by automatically shutting down compute resources when no requests are being sent to the endpoint. This configuration is standard practice for reducing operational expenditure in cloud-based model serving environments.

The configuration lacks an environment variable block

Why it fails: Environment variables are optional in Databricks Model Serving configurations. They are only required if the model code explicitly depends on them for runtime configuration, such as database credentials or API keys. Omitting them from the JSON payload will not cause a validation error during the creation of a new endpoint.

A list of the developer's favorite colors

Why it fails: Personal developer information has no relevance to the model's performance, stability, or reliability. Including such data in the evaluation process is a distraction from the technical and business objectives of MLOps. Evaluation criteria must be objective, measurable, and focused on the quality of the machine learning artifact.

The number of hours spent training the model

Why it fails: Training time is an operational metric that might interest a project manager, but it is not a primary criterion for production readiness. A model that takes 100 hours to train can be just as effective as one that takes 1 hour. Readiness is based on predictive accuracy, not computational effort.

A manual email to the stakeholder confirming completion

Why it fails: Manual processes like email notifications are prone to failure and lack the formal traceability required in mature MLOps environments. Production readiness should be determined by automated checks, CI/CD pipeline results, and formal status transitions within the MLflow Model Registry, not by informal, undocumented communications between team members.

Install libraries manually on the driver node using pip install.

Why it fails: Manual installation on a driver node is ephemeral and non-persistent across cluster restarts or scaling events. Production deployments must utilize declarative environment specifications like requirements.txt or conda.yaml to ensure consistency and reproducibility every time the inference endpoint spins up or scales during peak demand periods.

Create a custom Docker image and specify it in the model signature.

Why it fails: While custom images are useful, the model signature defines input/output schemas rather than the runtime environment itself. You must configure the model serving endpoint to use the specific container URI, not just define it within the model signature, to ensure the serving infrastructure loads the required library dependencies correctly.

Deploy the model as a library using the Databricks Workspace UI.

Why it fails: Deploying code as a library is intended for modular code sharing rather than serving real-time inference endpoints. Libraries do not provide the necessary REST API endpoints, load balancing, or automated scaling features required for serving models to external client applications reliably in a production environment.

Add a descriptive tag to the model version.

Why it fails: Adding tags is helpful for organization and metadata management, but it does not functionally ensure the model is ready for production. Production readiness requires passing rigorous validation tests, performance benchmarking, and formal stage transitions rather than just applying metadata labels to the model version within the registry.

Delete all previous versions of the model.

Why it fails: Deleting model versions is a poor practice that breaks model lineage and auditing capabilities. It is essential to keep previous versions for rollback purposes, compliance auditing, and A/B testing comparisons, as these are critical components of a professional MLOps strategy for maintaining high availability and model recovery.

Export the model as a CSV file.

Why it fails: Exporting models as CSV files is not a standard workflow for model deployment and does not preserve the complex serialization formats required by MLflow. Deployments rely on serialized artifacts like Pickled objects or MLmodel files which encapsulate the complete model state, architecture, and necessary runtime environment configurations.

The endpoint will automatically scale down to zero during off-peak hours.

Why it fails: The 'min_instances' parameter defines the floor of the cluster size. Setting this to 2 prevents the system from scaling down to zero, ensuring that the inference service remains active and ready to handle incoming requests at all times, regardless of the current load or time of day.

The endpoint will limit concurrency to two requests per instance.

Why it fails: The 'min_instances' parameter governs the number of compute nodes (instances) provisioned for the endpoint, not the concurrency limits per instance. Concurrency is typically managed by the serving framework's internal request handling and the size of the underlying instances, which are independent of the total instance count.

The endpoint will only support two concurrent users at any given time.

Why it fails: This parameter defines physical infrastructure scaling rather than application-level user concurrency. A serving endpoint with two instances can potentially handle hundreds or thousands of concurrent requests depending on the model's complexity, instance size, and request processing time, making this an incorrect interpretation of the underlying scaling logic.

Automatic conversion of Python code to C++.

Why it fails: Databricks does not perform automatic source-level code conversion to C++. While it optimizes runtime performance, it does so through managed environments and infrastructure rather than modifying the user's Python source code. Developers should focus on writing efficient Python code to ensure optimal inference speed and latency.

Direct write access to the production database.

Why it fails: Model serving endpoints are designed to provide inference services, not to execute arbitrary database modifications. Providing direct write access to a production database from an inference service is a significant security risk and architectural anti-pattern that violates the principle of least privilege required in secure production systems.

A Dockerfile.

Why it fails: A Dockerfile is used for building containers, not for defining the model's input/output schema. While containers may be used for deployment, the signature is a distinct MLflow feature that provides metadata about the model's interface, allowing for type checking and automated schema validation independent of the containerization approach.

A requirements.txt file.

Why it fails: The requirements.txt file is strictly for listing library dependencies. It does not provide any structural information about the model's expected inputs or outputs. While necessary for environment setup, it is distinct from the signature metadata which defines the data interface of the trained machine learning model.

A Jupyter notebook checkpoint.

Why it fails: Notebook checkpoints are internal file system snapshots used for version control of code within a notebook environment. They are not part of the standard MLflow packaging process and contain no metadata about the model's interface or inference requirements for deploying models to production serving endpoints.

Attach an interactive all-purpose cluster to the endpoint to process batch inference jobs concurrently.

Why it fails: Interactive all-purpose clusters are designed for exploratory data analysis and development, not for real-time model serving endpoints. Model serving uses specialized, optimized infrastructure rather than standard interactive notebook compute clusters.

Store model training datasets directly inside the endpoint configuration JSON payload.

Why it fails: Endpoint configurations reference registered model versions rather than embedding raw training datasets directly into payloads. Including datasets in configurations violates payload size limits and introduces severe performance and security bottlenecks.

Rely entirely on default CPU node types without specifying workload size parameters.

Why it fails: Default sizing might be insufficient for memory-heavy or GPU-accelerated deep learning models, leading to out-of-memory errors. Proper workload sizing tailored to model complexity is critical for maintaining stable endpoint performance.

A served entity whose entity_name is the full artifact URI of the model run and whose entity_version is the run ID.

Why it fails: Served entities reference registered models in Unity Catalog or the workspace Model Registry by model name, not raw artifact URIs or run IDs. Supplying an artifact URI would fail validation and would not provide the automatic latest-version behavior the scenario requires.

A served entity whose entity_name is `prod.ml.risk_model` and entity_version is set to the string `latest`.

Why it fails: The entity_version field does not accept the literal string `latest`; it expects a version number or is simply omitted. Using an invalid literal would cause endpoint creation or update to fail rather than gracefully tracking the newest registered version.

A served entity whose entity_name is `prod.ml.risk_model` and entity_version is set to the integer value of the currently newest version.

Why it fails: Setting entity_version pins the endpoint to one immutable model version. When a new version is registered, the endpoint continues serving the pinned one until an engineer edits the configuration manually, which directly violates the requirement of automatic updates without config changes.

The model must be logged with a specific flavor, such as scikit-learn.

Why it fails: MLflow supports multiple flavors, and Model Serving can handle various flavors like scikit-learn, TensorFlow, PyTorch, etc. However, the flavor is not a prerequisite; any supported flavor can be served. The key requirement is registration in the Model Registry, not the specific flavor.

The model must have a signature defined.

Why it fails: A signature is not strictly required to create a serving endpoint, but it is highly recommended for input validation. Model Serving can deploy models without a signature, but the endpoint may not enforce the expected input schema, potentially leading to runtime errors. Thus, it is not a hard prerequisite.

The model must be in the 'Production' stage.

Why it fails: While deploying from the Production stage is common, Model Serving can also serve models in other stages or versions. The stage is not a strict prerequisite; you can serve any model version by specifying its version number. However, for production use, it is best practice to promote to Production first.

Attach the model as a workspace file dependency and load it inside a custom pyfunc wrapper.

Why it fails: Bundling the model as a workspace file dependency freezes a copy of the artifact at deployment time. The endpoint has no mechanism to detect that the underlying registered model version changed, so the served model would remain stale until the endpoint is redeployed. It also sidesteps Unity Catalog governance, which the team explicitly wants to retain for version tracking.

Enable automatic model refresh by setting the endpoint's scale-to-zero policy to disabled.

Why it fails: Scale-to-zero controls whether compute instances shut down when idle; it has no relationship to model version resolution. Disabling it keeps an instance warm for latency reasons but does not cause the endpoint to re-read the registry. The team would still need to edit or recreate the endpoint whenever a new model version should be served.

Deploy the endpoint using the model's run ID instead of the model name.

Why it fails: Referencing an MLflow run ID pins serving to one specific logged artifact and provides no linkage to the Unity Catalog model version lineage, so newly registered versions would never be detected. It also bypasses the registry entirely, which means the endpoint cannot follow version updates and would require manual redeployment for every new model, defeating the goal of automatic version pickup.

{"dataframe_records": [[0.5]]}

Why it fails: This payload uses the dataframe_records key with a bare array of values, which is the format for the older dataframe_split or dataframe_records style used by MLflow scoring servers, not the dataframe_records format required by Databricks Model Serving. Databricks Model Serving expects dataframe_records to be a list of JSON objects with named columns, so a bare numeric array will fail schema validation against the named features column.

{"dataframe_split": {"columns": ["features"], "data": [[0.5]]}}

Why it fails: The dataframe_split format is valid for MLflow's local scoring server and is supported by some Databricks serving paths, but the question asks for the payload that matches the signature using the dataframe_records convention. While dataframe_split can work, dataframe_records is the canonical JSON record format for Databricks Model Serving and is what the REST API documentation recommends for named-column requests, making it the more precise match here.

{"inputs": [{"features": 0.5}], "parameters": {}}

Why it fails: The inputs/parameters envelope is the payload format for Databricks Foundation Model APIs and external model endpoints that proxy to providers, not for custom MLflow models served by Databricks Model Serving. Custom models registered in Unity Catalog expect dataframe_records or dataframe_split, so sending an inputs envelope will be rejected with an unsupported request format error before the model is ever invoked.

Register the model version with a stage of `Production` in the workspace Model Registry.

Why it fails: Model stages like `Production` are metadata labels that help organize lifecycle state; they do not configure endpoint scaling or latency behavior. Serving endpoints reference specific model versions by name and version regardless of stage. Assigning a stage does not keep replicas warm or size the compute, so it cannot satisfy the stated performance requirements.

Enable inference tables on the endpoint.

Why it fails: Inference tables log request and response payloads for monitoring and analysis. They do not influence latency, cold starts, or scaling behavior. While valuable for observability, enabling inference tables does not satisfy the performance and cost requirements described. This option is a distractor that conflates monitoring with performance tuning.

Set `scale_to_zero_enabled` to true on the served entity.

Why it fails: Enabling scale-to-zero allows the endpoint to drop to zero replicas when idle, which reduces cost but introduces cold-start latency when the next request arrives. That directly conflicts with the requirement to avoid cold-start delays for bursty traffic. Scale-to-zero is appropriate for development or infrequent workloads, not latency-sensitive production endpoints.

models:/ml_prod.churn.model_v3@champion

Why it fails: An alias-based URI serves whatever version currently carries that alias, and aliases must be reassigned manually or by a job after registration. Nothing about this URI causes new versions to be adopted automatically, so it still requires an administrative action per release. It is a valid deployment pattern, but it does not satisfy the stated automatic-update requirement.

runs:/<run_id>/model

Why it fails: A run-relative URI points at one specific MLflow run artifact and is immutable by design. It bypasses the Model Registry entirely, so there is no notion of a newest ready version to follow, and the endpoint would remain bound to that single run forever. This is used for quick testing, not for managed lifecycle deployment in Unity Catalog.

models:/ml_prod.churn.model_v3/3

Why it fails: Pinning an explicit numeric version freezes the endpoint on that one artifact. When a newer version is registered, the endpoint keeps serving version 3 and never moves forward, so the requirement for automatic pickup of new ready versions is not met. This URI is appropriate only when strict immutability of the served artifact is desired, which is the opposite of this scenario.

Install the third-party library on the driver node of the cluster used for training.

Why it fails: Installing a library on a training cluster only affects that cluster's runtime; it is not carried into the model artifact or the serving environment. Model Serving provisions a separate container based on the logged model environment. Unless the dependency is recorded in the model's requirements, a cluster-level install has no effect on the endpoint and the model will fail to import the library at serving time.

Configure the endpoint to use a Databricks Runtime version that includes the third-party library.

Why it fails: Databricks Model Serving does not let you pick an arbitrary Databricks Runtime version for custom models; it uses a managed serving environment. Relying on a runtime that happens to bundle the library is fragile and not a supported configuration path. The correct approach is to declare the dependency in the model's environment so the serving layer installs it, rather than hoping a specific runtime contains it.

Add the third-party library to the cluster's init script so it loads at startup.

Why it fails: Init scripts run on Databricks clusters, not inside Model Serving containers, and are not part of the model artifact. Adding a library via init script affects only the cluster where the script runs and does nothing for the serving environment. The dependency must instead be expressed in the logged model's environment so the serving layer installs it when building the model container.

Enable autoscaling on the endpoint by setting `max_instances` to a high value and leave `scale_to_zero_enabled` at its default of false.

Why it fails: Autoscaling with `max_instances` controls the upper bound of instances but does not by itself scale to zero. If `scale_to_zero_enabled` is false, the endpoint retains at least one instance, incurring cost while idle. The requirement is to minimize cost when idle, which demands scale-to-zero. This option addresses burst capacity but fails the idle-cost objective.

Deploy the model to a single-node cluster and expose it via a REST API using a Databricks job schedule.

Why it fails: A single-node cluster with a job-scheduled REST API is not a real-time serving solution. Jobs run on schedules and are not designed for low-latency, always-available inference. This approach also does not provide automatic scaling or scale-to-zero semantics. Databricks Model Serving is the managed service intended for this use case, making the cluster-based approach inappropriate.

Set `min_instances` to 0 and rely on the default `workload_size` to absorb traffic bursts without further configuration.

Why it fails: While `min_instances` of 0 allows the endpoint to scale down, the option ignores the need to size compute for bursts. The default `workload_size` may be too small for the expected traffic, causing latency or throttling. The scenario explicitly requires handling bursts, so workload size must be chosen deliberately. This option addresses only the idle-cost half of the requirement.

The model's training accuracy metrics

Why it fails: While tracking metrics is critical for model evaluation and versioning, Databricks Model Serving does not require specific accuracy scores to initiate an endpoint. The infrastructure focuses on the model artifact and signature to facilitate inference calls, rather than performance validation, which is handled at the CI/CD pipeline stage.

A Unity Catalog registered function

Why it fails: Unity Catalog functions are useful for data transformation but are not a mandatory prerequisite for deploying a basic MLflow model to a serving endpoint. While they can be used in feature pipelines, the serving endpoint specifically requires the model artifact and its associated schema to successfully load the environment.

A dedicated high-concurrency cluster

Why it fails: Model Serving endpoints in Databricks are managed services that run on dedicated serverless infrastructure. They do not require a user-managed High Concurrency cluster to function. The serving service handles the compute allocation dynamically based on the traffic configuration, abstracting away cluster management tasks from the deployment process entirely.

By requiring the user to provide a Dockerfile

Why it fails: While custom Docker images are supported for advanced use cases, they are not the standard way to ensure consistency. The default behavior is for Databricks to automatically generate the environment based on the MLflow environment logs, which simplifies the deployment process for the vast majority of data science projects.

By strictly enforcing the use of the latest stable libraries

Why it fails: Forcing the use of the latest libraries is detrimental to reproducibility. Models are highly sensitive to specific versions of libraries like scikit-learn or TensorFlow. Databricks ensures consistency by respecting the specific versions defined during training, rather than upgrading them to newer, potentially incompatible versions during the deployment process.

By running the model on the same training cluster

Why it fails: Serving endpoints run on dedicated, managed compute resources, not on user-created training clusters. Using a training cluster for serving is a significant anti-pattern, as it lacks the necessary autoscaling and isolation characteristics required for production-grade inference. Serving infrastructure is specifically optimized for low-latency request handling, distinct from batch processing.

Manually check the model accuracy once a year

Why it fails: Annual checks are insufficient for modern data environments where data distribution shifts can occur in minutes or hours. Drift management requires continuous or automated evaluation. Without frequent monitoring, models can degrade silently, leading to incorrect business decisions and a loss of trust in the machine learning system.

Re-deploy the model with new data every hour

Why it fails: Continuous re-deployment without evaluating for drift is inefficient and risky. It can lead to overfitting on noisy data or instability in production. A controlled approach involving validation and drift detection is much better than blindly cycling models. Automated retraining should only trigger based on performance thresholds or drift metrics.

Use a static model that never changes

Why it fails: Static models are highly prone to performance decay in non-stationary environments. As data patterns change over time, the model's relevance decreases. A robust MLOps strategy must account for the reality of data evolution, making static models a poor choice for any application where input data is subject to change.