Generative AI Engineer Associate · Domain 4: Assembling and Deploying Applications · 22% of the exam
Task 4.1: Code a chain using a pyfunc model with pre- and post-processing; Code a simple chain according to requirements; Choose the basic elements needed to create a RAG application: model flavor, embedding model, retriever, dependencies, input examples, model signature; Register the model to Unity Catalog using MLflow
PythonModel with load_context and predict, model signatures and input examples, logging dependencies and resources, and registering models in Unity Catalog with versions and aliases.
Study it
pyfunc chains, signatures, input examples and Unity Catalog registration
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the Databricks documentation page that proves it.
Question 1 · choose 1
A custom pyfunc chain on Model Serving loads a reranking model and a tokenizer from its artifacts inside predict(), and every request takes several seconds longer than the model call itself. What should the engineer change?
AMove the loading code into the input example so that it runs once, when the model is logged
BEnable scale to zero so idle replicas release the loaded artifacts
CLoad the reranker and tokenizer in load_context() and keep predict() for per-request work
DRaise the endpoint workload size so artifact loading has more memory
Show the answer and why
AMove the loading code into the input example so that it runs once, when the model is logged
Incorrect
An input example documents and validates the expected input; it does not run code when the endpoint serves requests.
BEnable scale to zero so idle replicas release the loaded artifacts
Incorrect
Scale to zero adds cold starts and does nothing about loading artifacts on every request.
CLoad the reranker and tokenizer in load_context() and keep predict() for per-request work
Correct
load_context runs once to load what the model needs, which minimizes artifact loading during predict and speeds up inference.
DRaise the endpoint workload size so artifact loading has more memory
Incorrect
More memory per worker does not stop predict from reloading the same artifacts each call.
A custom pyfunc model needs two functions: load_context for anything loaded once, and predict for the logic run on every request, including pre- and post-processing.
A pyfunc RAG chain was logged on Databricks Runtime ML without pip_requirements and registered to Unity Catalog. Its serving endpoint fails twice: first the container image cannot be built, and after a manual fix the model fails to load with ModuleNotFoundError for an internal preprocessing_utils package. Which TWO changes to log_model() fix both failures? (Choose TWO.)
AAdd mlflow==<version> to pip_requirements
BPass the preprocessing_utils folder in code_path
CAdd mlflow-skinny explicitly to extra_pip_requirements
DSet ENABLE_FEATURE_TRACING as an endpoint variable
ESwitch the endpoint to a GPU_SMALL workload
Show the answer and why
AAdd mlflow==<version> to pip_requirements
Correct
Runtime ML ships mlflow-skinny, which ends up in conda.yaml when no requirements are given; Model Serving needs the full mlflow package to build the image.
BPass the preprocessing_utils folder in code_path
Correct
code_path logs code references that are loaded into the path, so shared modules are importable when the model loads.
CAdd mlflow-skinny explicitly to extra_pip_requirements
Incorrect
mlflow-skinny is the cause of the build failure; listing it again keeps the problem.
DSet ENABLE_FEATURE_TRACING as an endpoint variable
Incorrect
That variable logs feature lookup DataFrames to inference tables; it has nothing to do with packaging.
ESwitch the endpoint to a GPU_SMALL workload
Incorrect
Compute type does not change which packages or code files are in the model environment.
Always pin mlflow in pip_requirements when logging a pyfunc model on Runtime ML, and use code_path for internal modules.
Registering a new version of a chain to Unity Catalog with mlflow.pyfunc.log_model(..., registered_model_name="prod.genai.support_chain") fails because the version has no model signature. What is the simplest fix?
AAdd a description to the registered model before logging the new version
BPass an input_example to log_model so MLflow infers the signature
CAssign a Champion alias to the version first
DSave the chain with mlflow.pyfunc.save_model to a volume first
Show the answer and why
AAdd a description to the registered model before logging the new version
Incorrect
A description documents the model; it does not supply the signature that Unity Catalog requires on each version.
BPass an input_example to log_model so MLflow infers the signature
Correct
Model versions in Unity Catalog must have a signature, and with an input example MLflow infers it automatically.
CAssign a Champion alias to the version first
Incorrect
Aliases point to existing versions; they do not supply the missing signature.
DSave the chain with mlflow.pyfunc.save_model to a volume first
Incorrect
Saving the model to a path changes where it is stored, not whether it carries a signature.
New ML model versions in Unity Catalog must have a signature. Autologging, infer_signature or an input_example passed to log_model provide one.
This would create or select an experiment, not a registry.
Databricks recommends Models in Unity Catalog for governing and deploying models; where the workspace default is not Unity Catalog, configure the MLflow client's registry URI first.
Version 4 of the registered model staging.genai.support_chain passed validation. Re-logging it in the prod catalog would be costly, and prod workloads load prod.genai.support_chain. How does Databricks suggest promoting that exact version?
ATransition version 4 to the Production stage of the staging model
BCopy version 4 into prod.genai.support_chain with copy_model_version()
CRename the staging model so that its name begins with prod instead
DAdd a registry webhook that re-registers version 4 in the prod catalog
Show the answer and why
ATransition version 4 to the Production stage of the staging model
Incorrect
Stages are not supported for models in Unity Catalog; the catalog expresses the environment instead.
BCopy version 4 into prod.genai.support_chain with copy_model_version()
Correct
Copying a model version across registered models promotes it between environments without retraining or logging it again.
CRename the staging model so that its name begins with prod instead
Incorrect
Renaming changes only the model name within its schema; it does not move the model to another catalog.
DAdd a registry webhook that re-registers version 4 in the prod catalog
Incorrect
Webhooks are not supported for models in Unity Catalog.
Databricks recommends producing production models with automated workflows in the production environment. Where retraining there is too costly, copy the validated version into the production model, validate it, then mark it for deployment.
A nightly batch job must always score with whichever version of the chain the Champion alias points to, so that reassigning the alias needs no job change. Which model URI should the job load?
Amodels:/main.genai.chain/Production
Bmodels:/Champion/main.genai.chain
Cruns:/main.genai.chain/Champion
Dmodels:/main.genai.chain@Champion
Show the answer and why
Amodels:/main.genai.chain/Production
Incorrect
Stages such as Production are not supported for models in Unity Catalog; an alias is referenced with @.
Bmodels:/Champion/main.genai.chain
Incorrect
The registered model name comes first in the URI.
Cruns:/main.genai.chain/Champion
Incorrect
A runs:/ URI points at a run's artifacts, not at a registered version.
Dmodels:/main.genai.chain@Champion
Correct
The @ form loads the version the alias currently references, so the job picks up a reassigned alias on its next run.
Loading a model by alias decouples batch and serving workloads from deployments: when the alias moves to a new version, the workload uses it automatically on its next execution.
MLflow captured most of a chain's dependencies automatically, but one extra package is missing at serving time. Which log_model parameter adds it without replacing the captured list?
Aextra_pip_requirements
Bpip_requirements
Cinput_example
Dregistered_model_name
Show the answer and why
Aextra_pip_requirements
Correct
extra_pip_requirements includes additional requirements beyond what is captured automatically.
Bpip_requirements
Incorrect
This sets the full list explicitly rather than adding to the captured one.
Cinput_example
Incorrect
An input example documents inputs and helps infer a signature.
Dregistered_model_name
Incorrect
This names the model in the registry.
Package dependencies can be given with pip_requirements, conda_env or extra_pip_requirements; code dependencies use code_path.