SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
Databricks GenAI · Domain 4

Assembling and Deploying Applications practice questions

Assembling and Deploying Applications is worth 22% of the Databricks GenAI exam — the 2nd-heaviest of the 6 domains. Assembling and deploying: pyfunc chains, RAG application elements, registering to Unity Catalog, Mosaic AI Vector Search, Model Serving and Foundation Model APIs, ai_query() batch inference, memory stores, CI/CD, prompt lifecycle, MCP servers and user interfaces. Official weighting 22%. 6 fully worked examples are further down this page, answers included.

Exam weight
22%
the 2nd-heaviest of the 6 domains
Questions
132
across 4 topics
Free, no account
5/day
a free account allows 30 a day
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 6 domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Assembling and Deploying Applications questions, fully explained

Questions from the Databricks GenAI bank mapped to domain 4, with the answer key and the reasoning behind every option. None of them repeat the examples on the main Databricks GenAI practice page.

Question 1Assembling and Deploying Applications

A Generative AI Engineer is logging a pyfunc support chain with mlflow.pyfunc.log_model and wants the same call to create a new model version in Unity Catalog. The model must live in the catalog ml, under the schema support, with the model name support_rag. Which argument should the engineer pass to the logging call?

Choose one.

  • a
    registered_model_name="ml/support/support_rag"

    Unity Catalog names use dots between catalog, schema and model, not slashes.

  • b
    registered_model_name="models:/ml.support.support_rag"

    models:/ is a URI scheme for loading a model, not part of the name used when registering one.

  • c
    registered_model_name="support_rag@ml.support"

    The @ suffix is how an alias is referenced when loading; it cannot carry the catalog and schema.

  • d
    registered_model_name="ml.support.support_rag" Correct

    Unity Catalog models are addressed by the full three-level name catalog.schema.model, which this value supplies.

The concept

Unity Catalog models are registered under a three-level name: catalog.schema.model.

Why that’s the answer

Passing registered_model_name to log_model registers the logged model as a new version, and for Unity Catalog the name must be the full catalog.schema.model form. The slash form, the models:/ loading URI and the @alias syntax are all real MLflow notations, but each belongs to a different job.

How to reason it out
  1. Recognise that registration needs a name, not a URI.
  2. Unity Catalog names follow catalog.schema.model with dots.
  3. Keep models:/ and @alias for loading, not registering.

Exam tip: Register with catalog.schema.model; load with models:/catalog.schema.model@alias.

Databricks GenAI Engineer: Coding pyfunc Chains and Registering Them to Unity Catalog — the lesson that teaches this.

Question 2Assembling and Deploying Applications

A Generative AI Engineer logged a pyfunc RAG chain by passing a PythonModel instance to mlflow.pyfunc.log_model with no other optional arguments. Registering the run's model to Unity Catalog now fails, and the error says the model version is missing required metadata. The engineer wants the smallest change that makes registration succeed and also gives Model Serving a sample request. What should the engineer do?

Choose one.

  • a
    Re-log the chain with pip_requirements so MLflow records an exact environment

    Pinned requirements are good practice, but the missing piece Unity Catalog checks for is the model signature.

  • b
    Grant CREATE MODEL VERSION on the registered model before trying to register it

    A privilege problem shows up as a permission error, not as missing model metadata, and grants do not add a signature.

  • c
    Re-log the chain with an input_example so MLflow infers and stores a signature Correct

    Unity Catalog requires a signature on every new model version. An input_example lets MLflow infer the signature and also stores a sample request for serving.

  • d
    Set a champion alias on the existing version so Unity Catalog can resolve it

    An alias can only be set on a version that already exists; it does nothing for a registration that fails.

The concept

New model versions in Unity Catalog must carry a model signature.

Why that’s the answer

Unity Catalog refuses a model version that has no signature. Logging with an input_example makes MLflow infer the signature from it (MLflow 2.5+) and saves the example, which Model Serving can show as a sample request. Writing the signature by hand also works but does not give the sample request. Requirements, grants and aliases are all real steps in the lifecycle, but none of them supplies a signature.

How to reason it out
  1. Match the error to Unity Catalog's registration rule: a signature is required.
  2. Pick the change that creates a signature with the least work.
  3. Prefer input_example when you also want a stored sample request.

Exam tip: No signature, no Unity Catalog model version; an input_example is the easiest way to get one.

Databricks GenAI Engineer: Coding pyfunc Chains and Registering Them to Unity Catalog — the lesson that teaches this.

Question 3Assembling and Deploying Applications

A Generative AI Engineer's team used to promote models in the workspace registry by moving a version to the Production stage, and the serving and batch jobs loaded whatever was in that stage. The team has moved the RAG chain to Unity Catalog as ml.support.support_rag. They want to mark version 4 as the one in use without changing the loading code on each promotion. What should the engineer do?

Choose one.

  • a
    Move version 4 to the Production stage and load models:/ml.support.support_rag/Production

    Unity Catalog models do not support stages, so the stage transition is not available for this model.

  • b
    Set the champion alias on version 4 and load models:/ml.support.support_rag@champion Correct

    Aliases are mutable pointers to a version, and the alias URI lets consumers keep one stable reference while promotions move the alias.

  • c
    Tag version 4 with stage=production and load models:/ml.support.support_rag@production

    Tags are metadata only; the @ form resolves aliases, so a tag of that name does not create a loadable reference.

  • d
    Register version 4 again as ml.support.support_rag_prod and load that model by version

    A copy per release works, but every promotion changes the version the jobs load, which the team wants to avoid.

The concept

Unity Catalog replaces registry stages with aliases such as champion.

Why that’s the answer

Stages are not supported for Unity Catalog models. Aliases are named, movable references to a version, and models:/catalog.schema.model@alias loads whatever version the alias points at, so promotion is a single alias move with no code change. A tag looks similar but cannot be used to load a model, and copying the model per release means changing the version each job loads.

How to reason it out
  1. Note that Unity Catalog has no stages.
  2. Find the feature that gives a movable, named pointer to a version.
  3. Load by the alias URI so promotions need no code change.

Exam tip: In Unity Catalog, promote by moving an alias, and load with @alias.

Databricks GenAI Engineer: Coding pyfunc Chains and Registering Them to Unity Catalog — the lesson that teaches this.

Question 4Assembling and Deploying Applications

A Generative AI Engineer has USE CATALOG on the catalog ml and USE SCHEMA on the schema ml.support. Registering a new chain as ml.support.faq_chain fails with a permission error, although the engineer can read tables in that schema. A workspace admin will grant one more privilege on the schema. Which privilege lets the engineer create the registered model?

Choose one.

  • a
    CREATE MODEL on the schema ml.support Correct

    Creating a registered model needs CREATE MODEL (or CREATE FUNCTION) on the schema, on top of USE CATALOG and USE SCHEMA.

  • b
    EXECUTE on the schema ml.support

    EXECUTE is what lets someone load and run models; it does not allow creating a new registered model.

  • c
    MODIFY on the schema ml.support

    MODIFY governs changing data in tables, not creating registered models in the schema.

  • d
    CREATE TABLE on the schema ml.support

    CREATE TABLE lets the engineer create tables; registered models need their own create privilege.

The concept

Registering a new Unity Catalog model needs CREATE MODEL on the target schema.

Why that’s the answer

Unity Catalog checks USE CATALOG and USE SCHEMA to reach the schema, then CREATE MODEL (or CREATE FUNCTION) on the schema to create the registered model. EXECUTE is the privilege for loading a model, and MODIFY and CREATE TABLE apply to tables.

How to reason it out
  1. Confirm the engineer can already reach the schema.
  2. Identify the privilege that creates a new securable of type model.
  3. Separate create privileges from use and load privileges.

Exam tip: Create a model: USE CATALOG + USE SCHEMA + CREATE MODEL; load a model: EXECUTE.

Databricks GenAI Engineer: Coding pyfunc Chains and Registering Them to Unity Catalog — the lesson that teaches this.

Question 5Assembling and Deploying Applications

A Generative AI Engineer wrote a pyfunc chain whose predict method creates a Vector Search client and loads a 400 MB tokenizer from disk before answering each question. On the serving endpoint, every request takes several seconds longer than the model call itself. The engineer must cut this overhead without changing what the chain returns. Where should the client and tokenizer be created?

Choose one.

  • a
    In load_context, which MLflow runs once when the model is loaded Correct

    load_context is called as soon as the PythonModel is built on load, so the objects are created once per replica and reused by every predict call.

  • b
    In __init__, so they are built once before the model is logged

    Objects created in __init__ are pickled with the model at logging time, which bloats the artifact and breaks for clients that cannot be serialised.

  • c
    In predict, behind a check that skips them for short questions

    Short questions would still pay the cost for every other request, so most traffic keeps the overhead.

  • d
    In input_example, so the serving endpoint builds them at startup

    An input example is sample data used for signatures and validation; it does not run setup code on the endpoint.

The concept

Expensive setup belongs in load_context, not in predict.

Why that’s the answer

MLflow calls load_context once when the model is loaded, and predict on every request. Moving client creation and tokenizer loading into load_context removes the per-request cost without changing outputs. Building them in __init__ looks similar but runs at logging time, so they get serialised into the model artifact, which fails or bloats for clients and large files.

How to reason it out
  1. Find the work that does not depend on the request.
  2. Move it to the hook that runs once per load.
  3. Avoid __init__ for non-serialisable or large objects.

Exam tip: Per-request work in predict; once-per-load setup in load_context.

Databricks GenAI Engineer: Coding pyfunc Chains and Registering Them to Unity Catalog — the lesson that teaches this.

Question 6Assembling and Deploying Applications

A Generative AI Engineer's pyfunc chain expands company acronyms in the user question before retrieval, using a large glossary.json file that predict opens from a /Workspace/Users/ path. The chain works in the notebook, but the serving endpoint raises FileNotFoundError on the first request. The glossary must travel with the model version, and it must be parsed once per serving replica rather than on every request. What should the engineer change?

Choose one.

  • a
    Pass code_paths=[path] to log_model and keep opening the original /Workspace/Users/ path in predict

    code_paths copies files and prepends them to sys.path for imports, but the code still opens the workspace path, which the endpoint cannot see.

  • b
    Pass artifacts={"glossary": path} to log_model and read context.artifacts["glossary"] in load_context Correct

    Logged artifacts are copied into the model, and context.artifacts gives their local path wherever the model is loaded, including the serving container.

  • c
    Pass artifacts={"glossary": path} to log_model and read context.artifacts["glossary"] inside predict

    The file is packaged correctly, but predict runs on every request, so the large glossary would be re-read and re-parsed each time instead of once per replica.

  • d
    Pass extra_pip_requirements=[path] to log_model so the endpoint installs the glossary at startup

    Pip requirements install Python packages; a JSON file is not a package and would make the environment build fail.

The concept

Files a pyfunc model needs are packaged with the artifacts argument and read through context.artifacts.

Why that’s the answer

Serving containers cannot read workspace paths from the notebook. The artifacts dictionary copies each file into the logged model, and at load time context.artifacts maps the name to an absolute local path. Two facts decide it: the file must be packaged as an artifact, and load_context runs once when the model is loaded while predict runs per request. Reading the artifact in predict packages the file but breaks the parse-once requirement. code_paths is the other near-twin: it copies files for imports, but the code still opens the old workspace path.

How to reason it out
  1. Spot that the failure is a path that exists only in the workspace.
  2. Package the file with the model so it is versioned with it (artifacts).
  3. Place the parsing where it runs once per loaded model: load_context, not predict.

Exam tip: Data files go in artifacts; read them once in load_context, not on every predict call.

Databricks GenAI Engineer: Coding pyfunc Chains and Registering Them to Unity Catalog — the lesson that teaches this.

What Databricks GenAI domain 4 tests, topic by topic

The official exam guide breaks Assembling and Deploying Applications into 4 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published Databricks GenAI practice questions per topic in Assembling and Deploying Applications
TopicWhat it coversQuestions
Coding chains with pyfunc and registering to Unity CatalogOfficial exam guide (March 18, 2026), Section 4 objectives: 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.33
Mosaic AI Vector SearchOfficial exam guide (March 18, 2026), Section 4 objectives: Create and query a Vector Search index; Explain the key concepts and components of Mosaic AI Vector Search; Configure vector search for a particular solution based on number of embeddings, update frequency, latency, and cost requirements.33
Model serving, access control, batch inference and memoryOfficial exam guide (March 18, 2026), Section 4 objectives: Control access to resources from model serving endpoints; Identify how to serve an LLM application that leverages Foundation Model APIs; Identify batch inference workloads and apply ai_query() appropriately; Configure a persistent datastore to store and retrieve intermediate memory or structured information.33
CI/CD, prompt lifecycle, MCP servers and user interfacesOfficial exam guide (March 18, 2026), Section 4 objectives: Apply CI/CD best practices such as updating a Vector Search index, promoting prompts across environments, and testing individual components of an agent; Integrate managed, external, and custom MCP servers based on a given application requirements; Apply prompt version control and manage prompt lifecycle; Develop an appropriate interactive user facing interface for an agent usage scenario (Apps, Slack, Teams, etc.).33
Total132

Revise Assembling and Deploying Applications before you drill it

Other Databricks GenAI domains

Assembling and Deploying Applications: your questions

Assembling and Deploying Applications is domain 4 of the Databricks GenAI exam guide and carries 22% of the scored content — the 2nd-heaviest of the 6 domains. On a 45-question paper that works out to roughly 10 questions, though Databricks does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official Databricks GenAI exam guide.