Free Databricks Generative AI Engineer Associate practice test

The three correct components are (A), (B), and (D). (A) A structured retrieval step grounds the pipeline in real source material and formats it for downstream processing. (B) A map step processes each paper individually, extracting claims reliably without overwhelming the context window with all 20 papers at once. (D) A reduce/synthesis step consolidates the per-paper extractions, identifies contradictions across studies, and generates the structured review — the core reasoning step. (C) Passing all 20 abstracts in a single zero-shot call risks exceeding context limits, dilutes attention, and is less reliable than the map-reduce approach for contradiction detection. (E) A topic classification step is a useful organizational tool but is not required for the synthesis and contradiction-identification goals stated in the requirement. (F) A separate confidence scoring step is a plausible enhancement but the question asks for the MOST appropriate combination; confidence scoring is best handled as part of the reduce step (D) rather than as an additional stage, and selecting it over the three core architectural components would misrepresent the essential pipeline structure.

(C) is the strongest argument for preferring few-shot prompting (Approach X). When the ICD-10 code set changes annually, a fine-tuned model (Approach Y) would need to be retrained and redeployed to handle new codes, while a few-shot prompt can simply include new examples with updated codes immediately. (A) HIPAA compliance applies to both approaches since both involve the model processing PHI; the compliance concern is about where inference runs, not whether the model is fine-tuned. (B) Stable distribution and abundant labeled data describe the ideal conditions for fine-tuning (Approach Y), not for preferring few-shot prompting. (D) A fine-tuned model generally has lower inference latency and cost than a general-purpose model augmented with a long few-shot prompt; throughput would favor Approach Y, not X.

Abstractive summarization (D) is the best fit because the goal is to condense lengthy clinical notes into a coherent, fluent paragraph that captures key themes — a hallmark of abstractive summarization. (B) Text classification assigns a label to input text; it does not produce a narrative paragraph. (A) Named entity extraction would identify individual entities like drug names or procedure codes but would not produce a readable paragraph summary. (C) Instruction-following chat could technically handle this task but is not the canonical task type for batch document summarization, and framing it as a chat interaction introduces unnecessary session-management complexity.

A Delta Sync index with triggered sync scheduled nightly aligns precisely with the nightly batch update pattern—it will automatically re-sync after each nightly Delta table load without requiring manual intervention, while also being efficient for a batch workload that doesn't need real-time streaming updates. A snapshot index that is manually triggered (option A) requires human intervention and doesn't satisfy the 'no manual intervention' requirement. A snapshot index on a fixed 24-hour schedule (option B) may miss the timing of the nightly load and is less flexible. A Delta Sync index with continuous sync (option C) would also work but is unnecessary and more expensive for a nightly batch pattern—triggered sync is the better fit.

Repeated boilerplate disclaimers, once embedded, produce nearly identical vectors. Indexing them wastes storage, inflates index size, and—critically—they will frequently be returned as top-k results for queries that happen to use similar legal or financial language, pushing genuinely relevant content out of the retrieved set. Filtering or deduplicating these chunks before embedding prevents this problem at its root. Option C is incorrect—the retrieval model has no built-in mechanism to deprioritize repetitive content; it retrieves based on embedding similarity only. Option A is incorrect—increasing overlap makes chunks larger but does not remove the disclaimer; the disclaimer chunk would still exist. Option B is incorrect—a higher-dimensional model would encode the repeated text with high-dimensional vectors that are still nearly identical to each other, providing no benefit.

The three relevant factors are: (A) Memory/storage trade-offs—256-dimensional vectors require significantly less RAM for the vector index and less disk storage, which is directly relevant under memory constraints. (B) The retrieval quality gap—a 7-point recall difference must be assessed in the context of downstream answer quality; if the gap translates to meaningfully worse answers, Model A may be worth the memory cost. (C) Inference latency—lower-dimensional embeddings are faster to compute and search, affecting both batch indexing pipeline throughput and real-time query latency. Option D is incorrect—tokenizer parameter count is not a meaningful proxy for embedding quality; the tokenizer and the embedding model are evaluated separately. Option E, while practically relevant in some contexts, is a one-time operational cost and not a fundamental technical trade-off for model selection under the given constraints. Option F is clearly irrelevant.

A Delta Sync index with triggered sync is ideal for tables updated on a predictable schedule. The engineer can trigger the sync after the nightly batch job completes, keeping the index current without the overhead of continuous sync infrastructure. Continuous sync (A, D) is unnecessary for a nightly-update pattern and adds operational complexity and cost. A Direct Vector Access index (C) requires the pipeline itself to manage upserts/deletes via API calls, which is more complex than simply triggering a managed sync.

Model B is the only model that satisfies all hard constraints: its p50 latency (600 ms) is below the 800 ms SLA, and its cost ($0.0018) is below the $0.002 limit. Its correctness score (3.8) is lower than Models A and C but remains within an acceptable range. Option A is incorrect: Model A violates the latency SLA (1,100 ms > 800 ms). Caching can help but does not guarantee SLA compliance for novel queries. Option C is incorrect: Model C costs $0.0019/query, which is under $0.002, so actually it does meet the cost constraint—but its latency (720 ms) also meets the SLA. However, Model B has a lower cost ($0.0018 vs $0.0019) and lower latency (600 ms vs 720 ms) than Model C, while Model C's correctness advantage (4.1 vs 3.8) is marginal. Model B remains the better balanced choice. Option D is incorrect: treating hard SLA and cost constraints as soft guidelines is an inappropriate engineering decision for a production deployment.

mlflow.pyfunc.ChatModel requires the predict(context, messages, params) method to be implemented. This method receives a list of ChatMessage objects and returns a ChatResponse, enabling the OpenAI-compatible chat interface for Databricks Model Serving. predict_stream (D) is optional for streaming support. load_context (B) is optional — used for one-time initialization — but not required. generate (A) is not a method on ChatModel. fit (E) belongs to sklearn-style models, not ChatModel.

Setting a max_iterations limit (option C) is a standard, reliable hard stop that prevents infinite loops by capping the total number of reasoning/tool-call steps the agent executor will perform. Adding explicit prompt-based stopping criteria (option E) leverages the model's instruction-following to detect and self-terminate repetitive behavior before hitting hard limits, providing a softer and more graceful exit. Hardcoding logic into the system prompt (option A) destroys the flexibility that makes agents valuable and does not scale. Increasing the context window (option B) allows more tool results to accumulate but does not prevent the loop — it may even make it worse by deferring the point at which the loop is noticed. An output guardrail detecting repeated calls (option D) could work but it sits outside the agent executor loop and would require complex state tracking; it is not a standard Databricks-recommended pattern for this issue, making it less reliable than the two correct options.

For Databricks-managed embedding generation on a Delta Sync index: (A) CDF must be enabled on the source table so the sync process can detect incremental changes; (B) an embedding model endpoint must be specified so Databricks knows which model to use for generating embeddings; (C) a text column must be designated as the source for embedding. Pre-computing embeddings (D) is what the Direct Vector Access index requires — managed embedding generation means Databricks does this automatically. A Direct Vector Access index (E) is the opposite of what is needed; managed embedding works with Delta Sync indexes. The Vector Search endpoint (F) must exist, but this is a prerequisite step, not a condition of the managed embedding feature itself — and it is not among the three core conditions specific to this feature.

ConversationBufferWindowMemory with k=5 maintains a sliding window of the last k conversation turns. At turn 20, only turns 16–20 are retained in the buffer — earlier turns are discarded. It does not summarize (A) — that is ConversationSummaryBufferMemory. It does not raise an error (D). It does not retain all turns internally while filtering at inference time (B) — the older turns are actually dropped from the buffer object.

Option D is correct: inference table writes are asynchronous and batched, so there is an inherent delay (often several minutes) between when requests are served and when data appears in the Delta table. Engineers should wait before concluding the table is empty. Option C is wrong: inference tables work for all workload types including CPU. Option B is wrong: there is no manual flush API required; data is written automatically in the background. Option A is wrong: inference table logging is automatic at the serving infrastructure level and does not require any changes to the model's predict() code.

Option A is correct: the runs:/<run_id>/<artifact_path> URI scheme is the standard MLflow format for referencing an artifact logged within a specific run, and it works with mlflow.pyfunc.load_model(). Option B is wrong: models:/ URIs reference registered model versions, not raw run artifacts, and latest is not a valid stage/version designator in Unity Catalog. Option C is wrong: the raw DBFS path can technically work in some configurations but is not the idiomatic or recommended MLflow URI scheme and is fragile across workspaces. Option D is wrong: there is no mlflow:/ URI scheme in the MLflow Python client.

Option C is correct: scale_to_zero_enabled: true is the explicit configuration flag that allows a served entity to scale down to zero replicas when idle, eliminating compute costs during periods of no traffic. Option A is wrong: min_provisioned_throughput applies to external/foundation model endpoints with provisioned throughput, not to custom model serving scale-to-zero behavior. Option B is wrong: setting workload size and type controls resource shape but does not by itself enable scale-to-zero. Option D is wrong: auto_capture_config controls inference table logging, not compute scaling.

Options C and D are correct: updating traffic_config to 100% for Version 3 shifts all live traffic to the new version within the same endpoint without downtime, which is the standard promotion step. Assigning the champion (or production) alias to Version 3 in Unity Catalog ensures any downstream code or pipelines that resolve the model by alias automatically use the newly promoted version, completing the lifecycle update. Option A is wrong: deleting Version 2 before traffic is fully migrated is risky and can cause errors if done out of order; best practice is to update traffic first, then remove the old served entity. Option E is wrong: mlflow.transition_model_version_stage() is the legacy Workspace Model Registry API and does not work with Unity Catalog models, which use aliases instead of stages. Option B is wrong: creating a new endpoint and updating DNS is an unnecessarily complex and error-prone approach when the current endpoint already supports multi-version traffic splitting natively.

Option B is correct because a safety classifier (like Llama Guard) acting as a guardrail layer is a well-established pattern for detecting policy-violating inputs and outputs before they are surfaced to users. Option D is correct because a carefully designed system prompt establishes behavioral boundaries and out-of-scope refusal instructions, which, combined with output parsing, provides a practical content governance layer. Option C is wrong because a low similarity threshold would filter out relevant on-topic queries, not harmful ones; similarity score alone is not a reliable proxy for content safety. Option E is wrong because temperature=0 only makes the model deterministic; a deterministic model can still produce harmful content if the underlying model weights and prompts lead to it. Option A is wrong because IP restriction is a network access control, not a content guardrail; it does not evaluate the substance of prompts submitted by authorized internal users.

Option B is correct because USAGE on the schema allows both groups to discover objects within it (satisfying discoverability for analysts), while EXECUTE on the Vector Search index grants query access exclusively to ml_engineers. Option A is wrong because BROWSE is not a standard Unity Catalog privilege for vector indexes, and SELECT applies to tables/views rather than indexes. Option C is wrong because READ PRIVATE FILES is a privilege for external storage locations, not for Vector Search index query access. Option D is wrong because revoking USAGE at the catalog level from data_analysts would prevent them from discovering any objects in the catalog, which violates the discoverability requirement.

groundedness is the LLM-as-judge metric specifically designed to assess whether the generated answer is supported by the retrieved context, directly targeting hallucination or fabrication. answer_correctness measures whether the answer matches a ground-truth reference, which requires labeled data and doesn't focus on retrieval grounding. chunk_relevance evaluates whether the retrieved chunks are relevant to the question, not whether the answer stays within those chunks. answer_similarity is a semantic similarity score against a reference answer, not a grounding check.

Inference tables automatically log every request and response for a Model Serving endpoint into a Delta table, and Lakehouse Monitoring can then analyze those tables over time to detect statistical drift in inputs, outputs, or quality metrics. Delta Live Tables and MLflow Model Registry are for data pipeline orchestration and model versioning, not endpoint drift monitoring. Feature Store and Model Serving logs is a partial answer—Feature Store tracks feature drift but isn't the native pairing for LLM endpoint monitoring. Unity Catalog lineage and MLflow Tracking handle data/model lineage and experiment tracking, not production drift detection.