A new hire asks for the correct end-to-end order of steps to take the safety-review summarizer from a working notebook to a live, queryable application. Which sequence is correct?
Select an answer to reveal the explanation.
Short Explanation
You can't register a car before it's built, and you can't serve a model before it's registered. The order is build, log, register, then serve — each step hands a finished, addressable artifact to the next one.
Full Explanation
The correct deployment sequence is: develop and validate the chain in a notebook; log it with MLflow using an appropriate flavor, a model signature, and captured dependencies; register that logged model to Unity Catalog under its three-level name, which creates a governed, versioned entry; and then create or update a Model Serving endpoint to serve a specific registered version (often via an alias). Each step produces the artifact the next step needs — you cannot register something that has not been logged, and you cannot serve something that has not been registered to a concrete, addressable model version. Creating the endpoint before the chain exists is backwards — an endpoint has to reference a specific model version, which does not exist yet. Registering an empty placeholder and building the chain around its output inverts development sequencing pointlessly and produces nothing deployable. Deploying straight from a notebook to an endpoint, skipping MLflow logging and Unity Catalog registration, breaks versioning, lineage, and governance and is not how Model Serving is designed to consume a model. For the exam, memorize the pipeline: notebook development to MLflow logging to Unity Catalog registration to Model Serving endpoint — in that order.