Home / GenAI Engineer practice test / Design Applications

Free · 8 questions with explanations

Design Applications: Databricks Generative AI Engineer Associate Practice Questions

Exam-style questions on Design Applications. Pick your answer, then open the explanation to see why it's right — and why the other options are wrong.

Take a full timed test free → All GenAI Engineer topics
1 Design Applications

A generative AI engineer is building a multi-turn customer support bot using LangChain on Databricks. The bot must: (1) ground all answers strictly in internal company documentation stored in a Databricks Vector Search index, (2) maintain context across multiple conversation turns so users can ask follow-up questions like 'Tell me more about the second option you mentioned', and (3) return responses as concise plain text. Which combination of LangChain chain components is REQUIRED to fulfill all three requirements?

  1. APromptTemplate + LLM + StrOutputParser. This three-component chain provides grounded answers from any input and supports multi-turn conversation natively because LangChain LLMs automatically store previous responses in their internal state.
  2. BChatPromptTemplate (with MessagesPlaceholder for history) + VectorStoreRetriever + ChatModel + StrOutputParser. The retriever grounds answers in company documentation, the chat prompt template with messages placeholder maintains conversation history across turns, and the output parser returns clean plain text.
  3. CVectorStoreRetriever + MapReduceDocumentsChain. Map-reduce chains are the standard LangChain architecture for multi-turn conversational retrieval because they parallelize document processing and merge history automatically.
  4. DLLM + ConversationBufferMemory only. Memory substitutes for retrieval because prior conversation turns accumulate enough context to answer follow-up questions without querying external documentation.
  5. EPromptTemplate + Retriever + LLM. A retriever without chat history is sufficient because company documentation is complete enough to answer any follow-up question from scratch using only the current user message.
Show answer & explanation

Correct answer: B

WHY B is correct: All three requirements map to specific LangChain components. (1) Grounding in documentation requires a VectorStoreRetriever — it queries the Databricks Vector Search index with the current user question and returns relevant document chunks as context. (2) Multi-turn awareness requires injecting prior conversation turns into the prompt — this is achieved with ChatPromptTemplate that includes a MessagesPlaceholder slot for chat history (populated by a memory component or passed explicitly). (3) Plain text output requires StrOutputParser. The ChatModel (rather than a base LLM) is appropriate for conversational use cases because it accepts structured message types (system/human/AI). WHY NOT A: A basic PromptTemplate + LLM + StrOutputParser chain has no retriever — it cannot ground answers in company documentation at all. LangChain LLMs do NOT automatically store state; memory must be explicitly configured. This option fails requirements 1 and 2. WHY NOT C: MapReduceDocumentsChain is designed for processing a large set of documents by mapping over chunks and reducing to a final summary. It is not a conversational chain and does not manage multi-turn history. It would be used for document summarization, not real-time multi-turn QA. WHY NOT D: Memory accumulates conversation history but does NOT provide access to the documentation vector store. If the user asks about a policy not yet discussed in the conversation, the memory-only chain cannot answer correctly. Retrieval is required for grounded answers — memory alone is insufficient. WHY NOT E: A PromptTemplate + Retriever + LLM without history management fails requirement 2. A follow-up question like 'Tell me more about the second option you mentioned' requires context from the previous AI response to be meaningful. Without history, the model treats each turn as a fresh, independent question.

2 Design Applications

A business intelligence team at a manufacturing company wants to enable 200 non-technical business users to query their Databricks Delta Lake tables (production metrics, inventory levels, sales by region) using plain English. A user should be able to type 'What were the top 5 underperforming product lines by revenue last quarter?' and receive an accurate, data-grounded answer — without writing SQL, without filing a ticket to the data team, and without custom agent development. Unity Catalog governance must be automatically enforced. Which Databricks Agent Bricks use case is MOST appropriate for this scenario?

  1. AKnowledge Assistant — upload the Delta Lake table schemas as PDF documentation and build a Knowledge Assistant chatbot that answers questions by searching those schema documents. Schema documents contain enough metadata about the data to answer business questions.
  2. BInformation Extraction — configure Information Extraction to scan all Delta Lake tables continuously and extract structured business KPIs into a summary table, then expose that table to users.
  3. CSupervisor Agent — deploy a supervisor that routes each user question to one of three domain-specific sub-agents: a production metrics agent, an inventory agent, and a sales agent. Each sub-agent writes custom SQL for its domain.
  4. DAI/BI Genie — turn Delta Lake tables registered in Unity Catalog into an expert AI chatbot that generates and executes SQL in response to natural language questions, with full Unity Catalog access controls applied automatically.
  5. ECustom LLM (Agent Bricks) — fine-tune a custom LLM on the company's historical SQL queries and Delta table schemas. Once trained, the model will generate syntactically correct SQL for any natural language question without any further tooling.
Show answer & explanation

Correct answer: D

WHY D is correct: AI/BI Genie is the Databricks Agent Brick specifically designed to 'turn your tables into an expert AI chatbot.' It takes Delta Lake tables registered in Unity Catalog as its data source, interprets natural language questions, generates SQL, executes it against the live data, and returns grounded answers — precisely the use case described. Unity Catalog access controls are applied automatically because Genie operates within the Unity Catalog governance framework, ensuring each user only sees data they are authorized to access. This requires zero custom agent development and is designed for non-technical users. WHY NOT A: Knowledge Assistant is designed for document-based Q&A (PDF, text files, unstructured content). Uploading schema documents does not give the chatbot access to the actual data in the Delta tables — it can only answer schema-level questions ('What columns does the sales table have?'), not data-level questions ('What were the top 5 underperforming product lines?'). Knowledge Assistant cannot execute SQL or query live tables. WHY NOT B: Information Extraction is designed to transform unstructured documents (invoices, emails, contracts) into structured fields — not to query existing structured Delta tables. Pre-extracting KPIs into a summary table requires knowing in advance every question users might ask, which is impossible and defeats the purpose of a natural language interface. WHY NOT C: Building a Supervisor Agent with domain-specific sub-agents that write custom SQL requires significant engineering effort per sub-agent, custom SQL logic maintenance, and periodic updates as schemas evolve. This contradicts the 'without custom agent development' requirement. Genie provides this capability out of the box. WHY NOT E: Fine-tuning a Custom LLM bakes knowledge of the table schemas into the model weights at training time. This approach cannot access live data (fine-tuned weights do not execute SQL), requires periodic retraining as schemas change, and produces stale answers. It is inappropriate for real-time tabular data querying.

3 Design Applications

A retail company's product manager describes a new AI feature: 'When a customer views their order history page, show them 3 products we think they'll love, along with a short explanation of why each product is a good fit for them personally.' A generative AI engineer must translate this business description into a formal input/output specification for the AI pipeline. Which specification BEST captures the requirement?

  1. AInput: a static product catalog CSV file sorted by popularity; Output: a ranked list of the top 3 best-selling products globally, formatted as a numbered list with product names only.
  2. BInput: (1) the user's recent purchase history as a list of product names/IDs, and (2) a product catalog or vector search index of available products; Output: a list of exactly 3 recommended product objects, each containing product_name (string) and reasoning (1-2 sentence personalized explanation of why this product matches the user's history).
  3. CInput: the complete text of every product review written by the customer since account creation; Output: a single paragraph summarizing the customer's general tastes with no specific product recommendations.
  4. DInput: the customer's demographic profile (age group, zip code, gender); Output: 3 products most commonly purchased by other customers in the same demographic segment, with no personalized explanation since demographics are self-explanatory.
  5. EInput: the raw embedding vector of the most recently purchased product only; Output: cosine similarity scores (floats) for all 50,000 catalog items, sorted descending — the top 3 are the recommendations. No text explanation is needed because the similarity score communicates relevance implicitly.
Show answer & explanation

Correct answer: B

WHY B is correct: A good AI pipeline specification directly maps the business goal to concrete, machine-processable inputs and structured outputs. The business goal has two components: (1) personalization → the pipeline needs the user's purchase history as input context, not global bestsellers or demographics; (2) a short explanation for each recommendation → the output must include natural language reasoning per recommendation, not just product IDs. Option B specifies: input = purchase history + product catalog (the information needed to make a personalized decision), output = 3 structured objects with product_name and reasoning (matching the 'short explanation' requirement exactly). WHY NOT A: Using a global bestseller list ignores the 'personalized' requirement. Showing the same top-3 products to every customer regardless of their history is not personalization. Additionally, outputting only product names (no explanation) fails the 'why each product is a good fit for them personally' requirement. WHY NOT C: A summary paragraph about the customer's tastes fails the recommendation requirement — the business goal is to show 3 specific products, not a prose profile. While taste profiling might be a useful intermediate step in the pipeline, it is not the final output the product manager described. WHY NOT D: Demographic-based recommendations (age, zip code, gender) are not the same as personal purchase history-based personalization. Demographic targeting does not leverage the customer's actual behavior. Also, the output lacks the required personalized explanation. WHY NOT E: Returning raw cosine similarity scores to a customer-facing feature is not a user-facing output — it is an intermediate similarity computation result. The business requirement calls for a named product and a human-readable explanation, not float vectors. Additionally, using only the single most recent purchase loses the broader purchase history context needed for quality personalization.

4 Design Applications

A financial research firm has 5,000 unstructured equity analyst reports stored as PDFs in a Unity Catalog Volume. Analysts frequently ask questions like 'What risks did analysts identify for semiconductor companies in Q2 2024?' and 'Summarize the investment thesis for TSMC across reports from the last 6 months.' The firm wants a pre-built solution that can search across all reports, cite specific source documents in its answers, and requires minimal engineering effort to deploy. Which Agent Bricks use case is MOST appropriate?

  1. AInformation Extraction — configure it to extract all risk factors, investment theses, and company names from every report upfront into a Delta table, then query that table for answers. Pre-extraction guarantees no information is missed at query time.
  2. BAI/BI Genie — register the PDF Volume as a Unity Catalog table and configure Genie to generate SQL queries that scan the binary PDF content for relevant text sections.
  3. CKnowledge Assistant — build a chatbot that turns the PDF analyst reports into a searchable knowledge base. Knowledge Assistant is designed to 'answer questions and cite sources' from unstructured documents, making it purpose-built for this exact use case.
  4. DSupervisor Agent — deploy a supervisor that creates a new specialized sub-agent for each analyst report, routing each question to the relevant report's agent. Supervisors provide higher accuracy than single-retrieval knowledge assistants for large document corpora.
  5. ECustom LLM (Agent Bricks) — fine-tune a custom LLM on all 5,000 analyst reports so the model can answer questions from its parameterized knowledge. Fine-tuning eliminates the need for retrieval and guarantees the model has internalized all report content.
Show answer & explanation

Correct answer: C

WHY C is correct: Knowledge Assistant is the Databricks Agent Brick explicitly designed to 'turn your documents into a high-quality chatbot that can answer questions and cite its sources.' The use case — natural language Q&A over unstructured PDF documents with source citations — is precisely what Knowledge Assistant is built for. It handles document ingestion, chunking, embedding, vector indexing, retrieval, and answer generation with citations in a pre-configured pipeline that requires minimal engineering effort. Source citation is a first-class feature, directly addressing the analyst need to trace answers back to specific reports. WHY NOT A: Information Extraction is designed for structured field extraction (e.g., 'extract vendor name, date, amount from each invoice'). Pre-extracting all possible information from 5,000 reports to cover every possible future question is infeasible — you cannot anticipate every analytical question an analyst will ask. Additionally, free-form analytical questions like 'Summarize the investment thesis' require retrieval and generation, not just database lookups of pre-extracted fields. WHY NOT B: AI/BI Genie is designed for structured tabular data (Delta tables). PDF files are binary unstructured documents — registering a PDF Volume as a Unity Catalog table does not make the text content queryable via SQL. SQL queries operate on structured rows and columns, not on binary PDF byte streams. WHY NOT D: Creating a separate sub-agent per report is not a scalable architecture for 5,000 documents. It would require 5,000 individually configured agents and a routing mechanism to determine which report(s) are relevant to each question. Knowledge Assistant's retrieval mechanism (vector similarity search across all documents) is precisely designed to avoid this anti-pattern. WHY NOT E: Fine-tuning an LLM does not reliably 'memorize' factual content from training documents. LLMs fine-tuned on large document corpora tend to hallucinate specific facts (prices, dates, company names) from those documents. Fine-tuning is also expensive, requires regular retraining as new reports arrive, and does not provide source citation capability. RAG-based approaches (used by Knowledge Assistant) are preferred over fine-tuning for document Q&A tasks.

5 Design Applications

A generative AI engineer is building a ReAct (Reason + Act) agent to answer: 'What is today's closing price of NVDA stock and by what percentage does it differ from its 52-week high?' The agent has access to three tools: get_current_price(ticker: str) -> float, get_52_week_high(ticker: str) -> float, and calculate_percentage_diff(value: float, reference: float) -> float. What is the CORRECT tool execution order, and what reasoning justifies the sequencing?

  1. Acalculate_percentage_diff → get_current_price → get_52_week_high. Start with the calculation tool to determine what input data will be needed; it returns placeholder values that the agent populates in subsequent calls.
  2. Bget_current_price('NVDA') → get_52_week_high('NVDA') → calculate_percentage_diff(current_price, week_high). Both data points must be retrieved before the calculation can execute because calculate_percentage_diff requires concrete float inputs — it cannot accept unresolved references.
  3. Cget_52_week_high('NVDA') only. The current price is always embedded in the 52-week high API response as a sub-field, making the get_current_price call redundant and wasteful.
  4. DAll three tools should be invoked simultaneously in one parallel batch. ReAct agents always parallelize all available tool calls in a single LLM reasoning step to minimize end-to-end latency.
  5. Eget_current_price('NVDA') → calculate_percentage_diff → get_52_week_high('NVDA'). The percentage difference tool must be called immediately after the price retrieval while the value is cached in the agent's short-term context window, before that context is displaced by the 52-week high call.
Show answer & explanation

Correct answer: B

WHY B is correct: The compute graph has an explicit dependency structure. calculate_percentage_diff(value, reference) requires two float inputs — the current price and the 52-week high — that must both be known before the function can be invoked. get_current_price and get_52_week_high are independent data-fetching tools with no dependency on each other, so they can be called in either order (or in parallel), but both must complete before the calculation. The ReAct framework iterates: Reason (what data do I need?) → Act (call a tool) → Observe (record result) → Reason again. In practice: step 1 retrieves the current price, step 2 retrieves the 52-week high, step 3 calls the calculation with both known values. WHY NOT A: calculate_percentage_diff requires actual float arguments — it cannot accept 'placeholders' or unresolved references in a real function call. Calling it first without the two required inputs would raise a TypeError or return a meaningless result. Tools execute synchronously with concrete arguments in the ReAct loop; they do not pre-declare what data will be needed. WHY NOT C: Stock price APIs and 52-week high APIs are separate data sources. The 52-week high endpoint does not embed the current intraday price. Assuming sub-field availability without knowing the actual API contract is an incorrect assumption that would cause the agent to fail silently with a missing current price. WHY NOT D: While get_current_price and get_52_week_high could theoretically be parallelized (they have no dependency on each other), calculate_percentage_diff absolutely cannot be included in the same parallel batch — it depends on the outputs of both other tools. Calling all three simultaneously means the calculation fires with unresolved inputs. Standard ReAct agents execute tool calls sequentially unless explicitly designed for parallel tool invocation. WHY NOT E: Agent context windows persist all tool results within the same conversation turn — there is no 'cache displacement' mechanism that would overwrite a previously observed float value when a subsequent tool is called. This option misunderstands how ReAct agents manage observation state and produces an incorrect execution order where the calculation is called with only one of its required inputs.

6 Design Applications

A procurement department receives 800 vendor invoices per month in various formats (PDF, email body text, scanned images). Each invoice must be parsed to extract: vendor_name, invoice_date, line_items (list of {description, quantity, unit_price}), total_amount, and payment_due_date. The extracted data must be written to a Unity Catalog Delta table for downstream accounts payable processing. The team has no ML engineering resources and needs the lowest-engineering-effort solution. Which Agent Bricks use case is MOST appropriate?

  1. AKnowledge Assistant — deploy a Knowledge Assistant chatbot indexed on all vendor invoices. Accounts payable staff can then ask 'What is the total amount on invoice #INV-2024-0445?' and copy the answers into the Delta table manually.
  2. BInformation Extraction — use this Agent Brick to transform unstructured invoice documents into structured field outputs. Information Extraction is designed specifically to 'transform documents and unstructured text into structured insights via information extraction, classification, and more,' with results writable to a Delta table for downstream processing.
  3. CAI/BI Genie — register the invoice PDFs as a Unity Catalog volume and have Genie generate INSERT SQL statements that populate the accounts payable Delta table from natural language prompts by the accounts payable manager.
  4. DSupervisor Agent — build a multi-agent coordinator where each vendor has a dedicated sub-agent trained on that vendor's invoice format. The supervisor routes each incoming invoice to the correct vendor-specific extraction agent.
  5. ECustom LLM (Agent Bricks) — fine-tune a language model on 2 years of historical invoice data, teaching it each vendor's invoice layout. Once fine-tuned, the model extracts fields from new invoices without any retrieval or tool calling.
Show answer & explanation

Correct answer: B

WHY B is correct: Information Extraction is the Databricks Agent Brick designed specifically to 'transform documents and unstructured text into structured insights via information extraction, classification, and more.' The invoice parsing use case — extracting named fields from unstructured documents and writing them to a structured table — is the canonical Information Extraction scenario. The Agent Brick handles document ingestion, field specification, LLM-based extraction, and output structuring in a pre-built pipeline that requires minimal engineering effort. Results can be written directly to a Delta Lake table in Unity Catalog for downstream processing. WHY NOT A: Knowledge Assistant is designed for interactive Q&A with source citations, not for batch automated extraction. Having staff manually ask questions and copy answers into a Delta table adds human labor back into the process — the opposite of automation. Additionally, Knowledge Assistant does not write structured output to Delta tables as part of its workflow; it produces natural language answers. WHY NOT C: AI/BI Genie answers questions about data already in structured Delta tables — it does not parse binary document files or generate bulk INSERT statements from PDFs. The invoice data must first be extracted from unstructured documents before it can be queried or inserted, which is outside Genie's scope. WHY NOT D: Building a per-vendor sub-agent requires significant engineering effort: one agent per vendor, routing logic based on vendor identification, and maintenance as new vendors are onboarded. This directly contradicts the 'lowest engineering effort' requirement. Information Extraction handles vendor format variation through general extraction capability, not vendor-specific models. WHY NOT E: Fine-tuning an LLM on historical invoices embeds vendor-specific layouts into model weights. This approach cannot generalize to new vendors without retraining, requires significant ML infrastructure and expertise, cannot write outputs directly to Delta tables without additional pipeline code, and is incompatible with the 'no ML engineering resources' constraint.

7 Design Applications

A large enterprise is building an AI assistant for their sales team. The assistant needs to answer three categories of questions: (1) data questions like 'How many deals closed in EMEA last quarter?' by querying Delta Lake sales tables, (2) knowledge questions like 'What is our official pricing policy for enterprise tier contracts?' by searching internal policy documents, and (3) action requests like 'Summarize the top 3 competitive risks from the latest market research report.' A single user message may require one, two, or all three capabilities. The enterprise wants a unified conversational interface with minimal custom code. Which Agent Bricks deployment pattern is MOST appropriate?

  1. ADeploy three separate Knowledge Assistant bricks — one per question category — and provide the sales team with three different chatbot URLs. Users can choose which assistant to use based on their question type.
  2. BDeploy a single AI/BI Genie connected to all data sources simultaneously. Genie can natively handle unstructured document search, SQL generation, and document summarization from a single multi-modal interface.
  3. CDeploy a Supervisor Agent that orchestrates multiple specialized agents: an AI/BI Genie for data questions, a Knowledge Assistant for policy document search, and additional agents for research summarization. The Supervisor routes each user request (or sub-task within a request) to the appropriate specialist agent and consolidates results into a unified response.
  4. DDeploy a single Information Extraction brick that pre-processes all sales data, policy documents, and research reports into a master structured Delta table. All user questions are then answered by querying this single table via SQL.
  5. EDeploy a single Knowledge Assistant indexed on PDF exports of the Delta Lake sales table data, policy documents, and research reports. Indexing all content as documents allows the Knowledge Assistant to handle all three question categories through vector similarity search.
Show answer & explanation

Correct answer: C

WHY C is correct: The Supervisor Agent (Multiagent Supervisor) is the Databricks Agent Brick designed to 'bring Genie spaces and agents together' under a unified coordinator. When a use case spans multiple distinct capabilities — structured data querying (Genie), document search (Knowledge Assistant), and custom agents — a Supervisor coordinates the specialists and presents a single conversational interface to the user. The Supervisor analyzes each user message, determines which agent(s) can fulfill it, routes sub-tasks appropriately, and merges the results into a coherent response. This is the purpose of the Multiagent Supervisor pattern. WHY NOT A: Providing three separate chatbot URLs to the sales team creates a poor user experience — salespeople must decide which tool to use before asking their question, and multi-part questions that require capabilities from two or three assistants cannot be handled at all without manually copying answers between tools. A unified interface is explicitly required. WHY NOT B: AI/BI Genie is designed specifically for structured tabular data (SQL generation). It does not search unstructured documents or summarize PDF market research reports. Claiming Genie handles all three modalities from a single interface misrepresents Genie's designed scope. WHY NOT D: Information Extraction pre-processes documents into structured tables. This works for extracting specific fields (prices, names, dates) but cannot answer open-ended data questions with unknown aggregation logic, cannot answer free-form policy questions requiring semantic understanding, and cannot summarize competitive analysis narratives. Pre-extracting all possible information from live dynamic sales tables and varied documents into one master table is both technically infeasible and semantically reductive. WHY NOT E: Exporting live Delta Lake sales data to PDFs and indexing those PDFs in a Knowledge Assistant is a severe anti-pattern. The sales data becomes stale immediately, PDF exports of tabular data create enormous documents, and vector similarity search over tabular data is far less precise than SQL execution. Knowledge Assistant is not designed to reason over numerical tabular data — AI/BI Genie uses SQL for that purpose.

8 Design Applications

A retail bank receives 50,000 customer complaint emails per day and needs to automatically assign each complaint to one of five case queues: account_access, fraud, fees_and_charges, loan_services, or general_inquiry. The system must require minimal human review and integrate with an existing SQL-based routing system. Which NLP task type and model approach BEST matches this requirement?

  1. AText generation — prompt a large generative LLM (e.g., DBRX) to write a new summary of each complaint, then parse the summary for routing keywords. Text generation is the only task type that can handle open-ended inputs.
  2. BText classification — use a model that assigns one of the five predefined category labels to each complaint text. Classification models can be instruction-prompted (zero-shot or few-shot) or fine-tuned on labeled complaint data, and they return structured label predictions that integrate directly with SQL routing logic.
  3. CNamed entity recognition (NER) — extract named entities such as account numbers, branch names, and dates from each complaint. The extracted entities will deterministically identify the correct department.
  4. DExtractive question answering — submit each complaint as a context passage and ask the model 'Which of the five departments should handle this?'. The model will extract the department name as a span from the complaint text itself.
  5. EText summarization — reduce each complaint to a single sentence, then apply a rule-based keyword matcher on the summary to select the appropriate queue. Summarization models outperform classifiers for routing because they normalize noisy input text before matching.
Show answer & explanation

Correct answer: B

WHY B is correct: Text classification is the purpose-built NLP task for assigning predefined categorical labels to text inputs. It is the correct task type for routing decisions with a fixed set of categories. Classification models can be zero-shot prompted using the category names as labels, few-shot prompted with examples, or fine-tuned on historical complaint data for higher accuracy. Their outputs — discrete labels and optionally confidence scores — map directly to SQL CASE logic or WHERE category = 'fraud' filters. WHY NOT A: Text generation produces open-ended free text — it is not designed for classification. Using a generative LLM to generate a summary and then parsing it for keywords is inefficient, fragile (generated summaries may not contain expected routing keywords), and introduces unnecessary latency. Text generation is appropriate for tasks like drafting replies, not for label assignment. WHY NOT C: NER extracts mentions of entities (people, organizations, dates, amounts) from text. It does not classify the overall topic or intent of a complaint. Account numbers or branch names in a complaint do not reliably identify which of the five departments should handle it — a fraud complaint and a fees complaint may both contain account numbers. WHY NOT D: Extractive QA extracts a span from the provided context that answers a question. For this to work, the complaint text itself would need to contain the department name — which is rarely the case. This is not the appropriate task type for routing. WHY NOT E: Summarization + keyword matching is a two-step pipeline that adds latency and fragility without improving accuracy over direct classification. Summarization models are not trained to normalize text for downstream keyword matching. Text classification handles noisy input directly without a summarization step.

Take the full GenAI Engineer practice test →

Keep going

Other GenAI Engineer topics


Assembling and Deploying Applications 8 practice questions → Application Development 8 practice questions → Evaluation and Monitoring 8 practice questions → Data Preparation 8 practice questions → Governance 7 practice questions →