A fintech company deploys a credit-risk model to a real-time endpoint. They monitor accuracy and latency. After a regulatory change, the data schema for incoming requests changes (a new field is added). The endpoint starts returning errors. What is the most appropriate action?

Retrain the model on the new schema immediately.

Increase the endpoint's compute resources to handle the new schema.

Update the serving pipeline to handle the new schema and map it to the model's expected input.

Reject all requests until the schema is reverted.

A media company deploys a content-recommendation model to two real-time endpoints: one for mobile users and one for desktop users. The mobile endpoint receives 80% of the traffic. The team notices the desktop model's accuracy is degrading. What is the most likely cause related to data splitting?

The training data was split evenly between mobile and desktop, but the serving data is skewed toward mobile.

The desktop endpoint has a smaller autoscaling configuration than the mobile endpoint.

The mobile endpoint is using a different model version than the desktop endpoint.

The desktop endpoint is not receiving enough traffic to keep the model warm.

In the context of real-time inference, what does 'data splitting' refer to?

Partitioning the dataset into training, validation, and test subsets

Dividing the input features into separate columns for the model

Replicating the dataset across multiple servers for high availability

Shuffling the data to remove any ordering bias before training

Why is it important to manage data distribution across multiple serving endpoints?

To avoid skew and ensure that the model performs consistently across all endpoints

To prevent any single endpoint from becoming a bottleneck

To ensure that each endpoint receives an equal number of requests

To reduce the cost of running multiple endpoints

What is the primary reason to monitor the performance of a real-time inference endpoint?

To track the number of requests served for billing purposes

To automatically scale the endpoint based on request volume

To detect when the model's accuracy degrades due to data drift or skew

To ensure that the endpoint is always available and never goes down

DatabricksCertified Machine Learning Associate

Domain 4Objective 6

Split Data Between Endpoints for Realtime Interference MACHINE-LEARNING-ASSOCIATE Practice Questions (Page 3)

Part of the Section 4: Model Deployment domain, which makes up ~30% of our current practice bank. Databricks does not publish an official question count, but from its 90-minute exam (~35–60 total, ~11–18 in this domain), expect 2–3 from this objective — we provide 23 practice questions to prepare you well beyond it. (estimate)

23questions here

5free pages

4concepts

Questions 11–15

11expert · hard
A fintech company deploys a credit-risk model to a real-time endpoint. They monitor accuracy and latency. After a regulatory change, the data schema for incoming requests changes (a new field is added). The endpoint starts returning errors. What is the most appropriate action?
Select an answer first
12application · medium
A media company deploys a content-recommendation model to two real-time endpoints: one for mobile users and one for desktop users. The mobile endpoint receives 80% of the traffic. The team notices the desktop model's accuracy is degrading. What is the most likely cause related to data splitting?
Select an answer first
13foundation · easy
In the context of real-time inference, what does 'data splitting' refer to?
Select an answer first
14foundation · easy
Why is it important to manage data distribution across multiple serving endpoints?
Select an answer first
15foundation · easy
What is the primary reason to monitor the performance of a real-time inference endpoint?
Select an answer first

Finished these 5 questions?

Review the revealed explanations, or continue through the curriculum.

Next 5 questions →Back to MACHINE-LEARNING-ASSOCIATE

Free Basic Practice is a study aid with revealable answers — not a scored exam. Examers.io is independent and not affiliated with or endorsed by Databricks. “MACHINE-LEARNING-ASSOCIATE” is a trademark of its owner, used for identification only.