Generative AI Engineer Associate · 30% of the exam

Application development: free practice questions

5 sample questions from our 75-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Databricks exam.

1. A Generative AI engineer is building a RAG application on Databricks and must choose between a Delta Sync index and a Direct Vector Access index in Mosaic AI Vector Search. The source data is updated every hour via a Delta Live Tables pipeline, and the team wants embeddings to stay current with minimal manual intervention. Which index type should the engineer choose, and why?

  • A. Direct Vector Access index, because it allows the application to push embedding vectors directly via API, giving the team full control over synchronization timing.
  • B. Delta Sync index with continuous sync mode, because it automatically monitors the source Delta table and refreshes embeddings whenever new data is committed, requiring no manual triggers.✓ Correct
  • C. Delta Sync index with triggered sync mode, because the team can schedule hourly refreshes aligned with the DLT pipeline, and triggered mode is the only mode compatible with DLT sources.
  • D. Direct Vector Access index, because it is the only index type that supports querying by both vector similarity and metadata filters simultaneously.
Explanation

A Delta Sync index with continuous sync mode is correct because it automatically tracks changes to the upstream Delta table and updates the vector index without manual intervention, which aligns with the team's goal of keeping embeddings current. Option A is wrong because Direct Vector Access requires the application to explicitly upsert vectors via API, which adds manual work and is not automatic. Option C is wrong because both Delta Sync modes (continuous and triggered) are compatible with Delta tables written by DLT; triggered mode requires explicit refresh calls rather than being automatic. Option D is wrong because both Delta Sync and Direct Vector Access indexes support metadata filtering alongside vector similarity search.

2. A Generative AI engineer is constructing a prompt template for a RAG application. The template includes a system prompt, retrieved context passages, and the user question. During evaluation, they notice that when multiple long context passages are included, the model's answer quality degrades — it tends to rely on the first passage and ignores middle ones. Which prompt engineering technique directly addresses this phenomenon?

  • A. Increasing the model's max_tokens parameter to allow longer responses
  • B. Reordering retrieved passages so the most relevant chunk appears last, just before the user question (recency bias exploitation)✓ Correct
  • C. Reducing the number of retrieved passages from top-5 to top-1 to eliminate noise
  • D. Switching from a chat prompt template to a completion prompt template
Explanation

The described phenomenon is 'lost in the middle' — LLMs tend to better utilize context at the beginning and end of the prompt. Placing the most relevant passage immediately before the user question (recency position) exploits the model's recency bias and improves answer quality. Increasing max_tokens (A) affects output length, not how the model attends to input context. Reducing to top-1 (C) sacrifices recall and may exclude necessary information. Switching prompt format types (D) does not address positional attention bias.

3. An AI engineer is using MLflow to log a LangChain RAG chain so it can be deployed on Databricks Model Serving. They use mlflow.langchain.log_model() and later notice the deployed endpoint returns unexpected errors when the retriever tries to connect to the Vector Search index. Which TWO steps are most important to ensure the retriever dependency is correctly captured and available at serving time?

  • A. Pass the retriever object directly inside the chain and set loader_fn and persist_dir to handle retriever serialization✓ Correct
  • B. Log the chain with mlflow.pyfunc.log_model() instead, since langchain flavor does not support retrievers
  • C. Ensure the serving endpoint's cluster has the appropriate Databricks personal access token (PAT) or service principal credentials configured as environment variables✓ Correct
  • D. Manually flatten all retrieved documents into the prompt before logging the model to avoid runtime retrieval
  • E. Pin all required library versions in the pip_requirements or conda_env parameter of log_model()
Explanation

When logging a LangChain chain that includes a Vector Search retriever, you must handle retriever serialization via loader_fn and persist_dir so MLflow can reconstruct the retriever at inference time (option A). Additionally, the serving endpoint must have valid Databricks credentials (PAT or service principal) available as environment variables so the retriever can authenticate to the Vector Search endpoint at runtime (option C). Switching to mlflow.pyfunc.log_model() is not required; the langchain flavor fully supports retrievers when configured correctly. Flattening retrieved documents defeats the purpose of RAG. Pinning library versions is good practice but does not resolve the retriever connectivity or serialization issue specifically.

4. A developer is logging a LangChain RAG chain on Databricks using `mlflow.langchain.log_model()`. The chain includes a custom `BaseRetriever` subclass that fetches documents from an external API. After loading the model in a fresh Python environment, the chain raises an `AttributeError` indicating the custom retriever class cannot be found. What is the MOST LIKELY cause and correct resolution?

  • A. The custom retriever class was not serialized by `mlflow.langchain.log_model()` because LangChain retrievers must be replaced with `DatabricksVectorSearch` before logging.
  • B. The Python file or package containing the custom retriever class was not included as a dependency when logging the model; it should be passed via the `code_paths` parameter.✓ Correct
  • C. MLflow LangChain flavor does not support custom `BaseRetriever` subclasses; the chain must be converted to an MLflow `ChatModel` before it can be logged.
  • D. The model was logged without specifying `serialization_format='cloudpickle'`, which is required for chains that include custom Python classes.
Explanation

When a LangChain chain includes a custom Python class (such as a `BaseRetriever` subclass), the class definition must be available in the serving environment. The `code_paths` parameter in `mlflow.langchain.log_model()` (and `mlflow.pyfunc.log_model()`) allows you to bundle the source files containing those definitions so they are available at inference time. Option A is incorrect: MLflow LangChain logging does support custom retrievers; you are not required to use `DatabricksVectorSearch`. Option C is incorrect: MLflow's LangChain flavor supports custom `BaseRetriever` subclasses. Option D is incorrect: while CloudPickle is used internally, explicitly setting a serialization format is not the standard fix for missing class definitions; `code_paths` is the correct approach.

5. A developer is building a LangChain agent on Databricks using `ChatDatabricks` and Unity Catalog tools. During testing, the agent enters an infinite loop — it repeatedly calls the same tool with the same arguments without incorporating the tool's output into its reasoning. What is the most likely root cause?

  • A. The `ChatDatabricks` class does not support tool calling and is ignoring tool results
  • B. The tool's output is not being passed back to the agent as a `ToolMessage` in the conversation history✓ Correct
  • C. The agent's temperature is set too high, causing it to ignore deterministic tool outputs
  • D. Unity Catalog functions cannot be used as LangChain tools without a custom adapter class
Explanation

In LangChain's tool-calling agent loop, after a tool is invoked, its result must be appended to the conversation as a `ToolMessage` (or equivalent) so the model can observe the result and decide the next action. If tool outputs are not returned to the model, the model has no signal to move forward and will re-invoke the same tool repeatedly. `ChatDatabricks` does support tool calling (A is false). Temperature (C) affects sampling randomness, not whether tool results are processed. UC functions can be used directly as LangChain tools via the Databricks SDK integration (D is false).

70 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free