8 of the 15 questions in this set, with the correct answer marked and every option explained.
1. A business team wants an internal tool that takes a long incident report and produces a short paragraph capturing the outcome of the incident, to be inserted into a weekly leadership digest. When translating this business goal into an AI pipeline design, what is the correct way to describe the desired model task?
✓A summarization task: input is a long incident report, output is a short, faithful condensed paragraph
The business requirement is explicitly about condensing a long document into a shorter one that preserves the key outcome -- that is a summarization task, and framing input/output this way is exactly what translating a business goal into a pipeline design means.
✗A text classification task, sorting each report into a fixed category label
Classification assigns a label from a fixed set; it doesn't produce the condensed narrative paragraph the leadership digest actually needs.
✗An image generation task, producing an illustrative graphic for each report
The requirement is about condensing text, not generating images -- image generation doesn't match the stated business goal at all.
✗A translation task, converting the report into another spoken language
Nothing in the requirement mentions language translation; the ask is purely about shortening the same-language content into a summary.
2. A team wants to build an internal agent that can answer employee questions by pulling information from an HR knowledge base, without any need for that agent to coordinate other specialized sub-agents or extract structured fields from documents. Which Agent Bricks building block best fits this specific, single-purpose need?
✓Knowledge Assistant
Knowledge Assistant is the Agent Bricks building block for answering questions grounded in a knowledge base -- a single-purpose Q&A need, matching the scenario exactly, without requiring multi-agent coordination or structured extraction.
✗Multiagent Supervisor
Multiagent Supervisor is for coordinating multiple specialized sub-agents; the scenario explicitly says no such coordination is needed here.
✗Information Extraction
Information Extraction is for pulling structured fields out of documents; the scenario is about answering open questions from a knowledge base, not extracting structured data.
✗A plain SQL query against a relational table with no language model involved
A plain SQL query can't interpret open-ended natural-language employee questions or generate a conversational answer grounded in unstructured HR documents.
3. A team is preparing a set of long, densely written legal contracts for a RAG application. Early testing shows that when a chunk is too large, the embedding blurs together several unrelated clauses, hurting retrieval precision; when a chunk is too small, individual clauses get cut off mid-sentence and lose meaning. Which action best reflects applying a chunking strategy appropriate to this document structure?
✓Chunk along natural clause or section boundaries rather than a fixed character count, sizing chunks to keep each clause intact
Chunking along the document's actual structure (clauses, sections) directly addresses both symptoms described: it avoids blending unrelated clauses into one chunk (too-large problem) and avoids cutting a clause mid-sentence (too-small problem), unlike a blind fixed-size split.
✗Use the largest possible chunk size the vector database allows, regardless of document content
Maximizing chunk size without regard to content is exactly the 'too large, blurs clauses together' failure mode already observed -- it would make the described problem worse, not better.
✗Split every document into single-word chunks for maximum granularity
Single-word chunks would destroy nearly all contextual meaning -- far more severe than the 'clauses cut off mid-sentence' problem already being observed at a larger too-small setting.
✗Skip chunking entirely and embed each full contract as one single vector
Embedding an entire long contract as a single vector would blend all of its clauses together even more severely than the too-large chunk problem already observed, badly hurting retrieval precision.
4. A RAG application's vector search reliably retrieves a set of candidate chunks that are all topically related to the user's query, but the single most relevant chunk often isn't ranked first, so the LLM sometimes builds its answer around a less relevant passage. Which technique addresses this specific ordering problem after initial retrieval?
✓Re-ranking the retrieved candidates before passing the top results to the LLM
Re-ranking takes the initial set of topically relevant candidates and reorders them using a more precise relevance signal, directly addressing the 'right candidates retrieved but not ranked correctly' problem described.
✗Increasing the chunk size used during the original document ingestion
Chunk size affects what content ends up in each chunk, not the order in which already-retrieved candidates are ranked -- it doesn't fix a mis-ordering problem.
✗Disabling the vector search index and returning documents in random order
Random ordering would make relevance ranking worse, not better, and abandons retrieval accuracy entirely rather than improving how results are ordered.
✗Reducing the number of chunks returned by retrieval to exactly one
Retrieving only one chunk removes any ranking problem by eliminating choice entirely, but at the cost of losing other potentially useful context -- it doesn't fix the retrieval and ranking pipeline, it just avoids the question.
5. A developer wants to build a Generative AI application on Databricks that chains together a retriever, a prompt template, and an LLM call into a single reusable pipeline, using widely adopted Python abstractions rather than hand-wiring each step. Which category of tool should the developer select for this?
✓LangChain or a similar orchestration framework
LangChain (and similar orchestration frameworks) is purpose-built for chaining retrievers, prompt templates, and LLM calls into a single reusable pipeline using established abstractions, exactly matching the requirement.
✗A plain CSV parsing library with no chaining capability
A CSV parser reads tabular files; it has no concept of chaining a retriever, prompt, and LLM call together into a pipeline.
✗A basic image resizing utility
An image resizing utility processes image files; it's unrelated to composing an LLM chain.
✗A static site generator with no Python model-chaining support
A static site generator builds web pages from templates; it provides no facility for chaining retrieval and LLM calls together.
6. A team is choosing an embedding model for a RAG application where the source documents are short product blurbs (well under 300 tokens each) and queries are short too. The team has explicitly said that minimizing cost and latency matters more than squeezing out the last bit of retrieval quality. Which embedding model context-length choice best fits this priority?
✓A smaller embedding model with a shorter context length (e.g., around 512 tokens) and a smaller model size/embedding dimension
Since documents and queries are short and cost/latency are the stated priority over maximizing quality, a smaller model with a shorter context length and smaller embedding dimension directly minimizes compute cost and latency while still comfortably covering the short input lengths.
✗The largest available embedding model with the longest context length regardless of document length
A large model with a long context length and larger embedding dimension increases cost and latency without adding value here, since the documents are already well under the smaller model's capacity -- directly contradicting the stated cost/latency priority.
✗No embedding model at all; rely purely on keyword search
Dropping embeddings entirely abandons semantic retrieval altogether, which is a much bigger tradeoff than the scenario is asking about -- the team wants a cost-conscious embedding choice, not to remove semantic search.
✗A model chosen at random from a model hub, without regard to context length or size
Choosing at random ignores the explicit selection criteria in the scenario -- document/query length and the cost-latency priority -- and could easily land on an oversized, more expensive model.
7. A customer-facing GenAI application occasionally produces responses that include competitor product names in a way the business doesn't want, and the team wants to prevent this class of output before it ever reaches the user, without retraining the underlying model. Which approach directly addresses this?
✓Implement LLM guardrails that filter or block responses containing disallowed content, such as competitor names
Guardrails are applied to model output (and input) to catch and block disallowed content -- like specific competitor names -- before it reaches the user, without requiring any retraining of the underlying model.
✗Increase the model's temperature setting to produce more varied responses
Higher temperature increases output variability; it doesn't filter or prevent any specific category of disallowed content from appearing.
✗Retrain the entire foundation model from scratch to remove knowledge of competitors
Full retraining is a massive undertaking and is explicitly what the requirement says to avoid ('without retraining the underlying model') -- guardrails solve this far more directly.
✗Disable all response logging to hide the issue from monitoring dashboards
Hiding the issue from monitoring doesn't prevent the disallowed content from reaching the user at all -- it just removes visibility into the problem while leaving it unresolved.
8. A team needs to evaluate which foundation model to use for an application that must take a one-paragraph customer memo and produce a single-sentence summary that fits into a compact UI field. Under which NLP task category should candidate models be evaluated for this application?
✓Summarization
Condensing a longer memo down to a single-sentence gist that preserves intent is precisely a summarization task, so candidate models should be evaluated on their summarization capability for this application.
✗Named entity recognition
Named entity recognition identifies specific entities (like names or dates) within text; it doesn't produce a condensed, single-sentence summary of the memo's overall intent.
✗Text classification into a fixed set of categories
Classification assigns a label from a predefined set; it doesn't generate the free-form condensed sentence the UI field needs.
✗Speech-to-text transcription
Speech-to-text converts spoken audio into written text; the input here is already a written memo, so this task category doesn't apply.
7 more questions in the app
Practise the full 15-question set with a timer, scoring and progress tracking.