Skill 1.1.1: Extract data from data sources

Question 1 - RAG Chunking Strategy Selection

A financial services company is building a RAG-based document assistant using Amazon Bedrock Knowledge Bases to answer compliance questions from a repository of 200-page regulatory PDF documents. The documents contain hierarchical structures with chapters, sections, subsections, and dense tables.

The ML engineer must ensure that retrieval returns complete, contextually coherent sections without cutting important definitions mid-way, while preserving the ability to filter results by chapter and section during vector search. The solution should minimize custom code and operational overhead.

Which chunking strategy should the engineer configure in Amazon Bedrock Knowledge Bases? (Select ONE)

A) Fixed-size chunking with 300 tokens and 10% overlap
B) Hierarchical chunking that preserves parent-child relationships between document sections
C) No chunking (treat each PDF as a single document unit)
D) Semantic chunking with a Titan Embeddings model
E) Recursive character splitting with a custom AWS Lambda parser

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: Hierarchical chunking in Bedrock Knowledge Bases preserves structural relationships (chapter → section → subsection) by maintaining parent and child chunks. This enables retrieval that returns complete sections without fragmentation, and structural metadata is automatically preserved for filtering during vector search.

Distractor Analysis

A is Incorrect: Fixed-size chunking with 300 tokens will cut sections arbitrarily, especially in dense regulatory text where definitions and requirements span more than 300 tokens. This results in lost context and poor retrieval quality.
C is Incorrect: Treating 200-page PDFs as single chunks creates enormous vectors that dilute semantic relevance. Retrieval would return entire documents rather than specific sections, negatively impacting both query precision and context window usage.
D is Incorrect: While semantic chunking breaks text on meaning rather than length, it does not inherently preserve hierarchical document structure (chapter/section metadata) as effectively as hierarchical chunking when filtering by document part is a stated requirement. Bedrock's hierarchical chunking is purpose-built for this structure.
E is Incorrect: Building a custom Lambda-based chunking pipeline introduces unnecessary operational complexity when native Bedrock Knowledge Bases chunking configurations satisfy the requirement with zero code.

Key Takeaway: Choose hierarchical chunking when documents have clear structural organization (chapters, sections) and users need to filter or attribute responses to specific document parts; fixed-size works best for uniform, loosely structured text.

Question 2 - Metadata Extraction for RAG Filtering

An e-commerce company is building a product support chatbot using Amazon Bedrock Knowledge Bases with Amazon OpenSearch Serverless as the vector store. The knowledge base contains product manuals, troubleshooting guides, and warranty documents for multiple product lines.

The application must filter retrievals by product category, model number, document type, and last-updated date. The ML engineering team must implement a strategy that ensures accurate metadata is stored with each chunk in the vector index while minimizing manual effort.

Which approach should the team use for metadata extraction and storage? (Select ONE)

A) Configure an AWS Lambda function triggered by S3 events to classify documents using Amazon Comprehend and custom regular expressions, then manually enrich each chunk with metadata before indexing.
B) Use Bedrock Knowledge Bases metadata enrichment, configuring metadata fields for product category, model number, document type, and date so the ingestion pipeline automatically associates them with chunks.
C) Store all metadata in a separate Amazon DynamoDB table and perform a secondary lookup after vector similarity search results are returned.
D) Embed metadata directly into the chunk text by prepending product information to each text block before ingestion, relying on semantic search to handle filtering.
E) Use OpenSearch Serverless field mapping to infer metadata from document content patterns.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: Amazon Bedrock Knowledge Bases supports metadata enrichment during data source ingestion. Configured metadata fields are automatically extracted and attached to each chunk in the vector index, enabling efficient pre-filtering during retrieval without custom code.

Distractor Analysis

A is Incorrect: Building a custom Lambda-based classification and enrichment pipeline introduces significant operational overhead and custom code, violating the requirement to minimize manual effort. Bedrock Knowledge Bases provides native metadata support.
C is Incorrect: Performing a secondary DynamoDB lookup after vector similarity search adds network latency and complexity to every query. Storing metadata natively in the vector index enables single-pass filtered retrieval.
D is Incorrect: Prepending metadata to chunk text relies on semantic matching rather than structured filters, is imprecise, and increases embedding model token count per chunk. Vector search cannot provide deterministic filter guarantees based on metadata text.
E is Incorrect: OpenSearch Serverless field mapping does not dynamically "infer" metadata from arbitrary content. Metadata fields must be explicitly defined during ingestion—there is no automated extraction based on content analysis.

Key Takeaway: Metadata enrichment should be configured at ingestion time in Bedrock Knowledge Bases so filters execute as part of the vector search—not as post-query lookups or semantic guessing.

Question 3 - Embedding Model Selection for Domain Language

A healthcare technology company is developing a clinical trial document search system using Amazon Bedrock. The document corpus contains dense medical terminology, compound drug names, and diagnostic codes. The retrieval system uses Amazon OpenSearch Serverless as the vector store.

The ML engineer must select an embedding model that maximizes retrieval quality for queries that use specialized medical vocabulary ("acute myocardial infarction" vs. lay terms like "heart attack").

Which embedding model configuration should the engineer choose? (Select ONE)

A) Use Amazon Titan Text Embeddings v2 with default settings, relying on its general-purpose semantic understanding to map lay terms to medical vocabulary.
B) Use Amazon Titan Multimodal Embeddings with image inputs enabled to enhance text comprehension through visual context.
C) Use a domain-specific embedding model available through Amazon Bedrock that has been trained or fine-tuned on medical/biomedical text corpora, ensuring domain terminology is represented in the vector space.
D) Use Amazon Titan Text Embeddings v2 with dimensionality reduced to 256 to improve the density of medical term representations.
E) Use Amazon Bedrock Guardrails to rewrite user queries into medical terminology before embedding, compensating for model vocabulary gaps.

Click to reveal Answer & Explanation

Correct Answer: C

Correct Option Analysis

C is Correct: Domain-specific embedding models trained on medical or biomedical corpora (available through Amazon Bedrock Marketplace or custom fine-tuned embedding models) produce vector representations that properly distinguish domain terminology from lay terminology, improving retrieval quality for specialized vocabulary.

Distractor Analysis

A is Incorrect: Titan Text Embeddings v2 is a general-purpose model optimized for balanced semantic understanding. It may not reliably map specialized medical terms to their lay equivalents without domain adaptation, leading to retrieval gaps.
B is Incorrect: Titan Multimodal Embeddings is designed for correlated text-image tasks. Adding image capabilities provides no benefit for pure text retrieval and introduces unnecessary token and latency overhead.
D is Incorrect: Reducing embedding dimensionality—while reducing storage use—compresses vector space and generally reduces retrieval precision. Dimensionality reduction worsens domain-specific term disambiguation rather than improving it.
E is Incorrect: Amazon Bedrock Guardrails performs filtering, redaction, and content validation—not query rewriting or domain adaptation. Attempting to use it for synonym expansion or terminology translation is architecturally invalid.

Key Takeaway: Embedding model selection must match the corpus and query domain; for specialized vocabularies (medical, legal, technical), choose or fine-tune a domain-aware embedding model rather than relying on general-purpose defaults.

Question 4 - Chunk Size Optimization for Retrieval Precision

A legal document management company is building a RAG application to retrieve clauses from lease agreements stored in Amazon S3. The agreements range from 20 to 80 pages and contain numbered clauses, sub-clauses, and cross-references. The company is using Amazon Bedrock Knowledge Bases with Amazon OpenSearch Serverless.

Users report that retrieved passages often contain the target clause surrounded by several unrelated clauses, consuming context window budget and confusing the LLM. The ML engineer needs to improve retrieval precision.

Which action should the engineer take to directly address this retrieval imprecision? (Select ONE)

A) Increase the maximum number of results returned from the vector search.
B) Reduce the chunk size and/or enable semantic chunking to split at clause boundaries rather than arbitrary token cutoffs.
C) Increase the chunk size to ensure the entire target clause is retrieved without truncation.
D) Switch from OpenSearch Serverless to Amazon Aurora PostgreSQL with pgvector for better relevance ranking.
E) Disable embedding generation and use keyword search in OpenSearch instead.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: Retrieval imprecision caused by relevant text buried in unrelated content indicates oversized or poorly split chunks. Reducing chunk size and/or enabling semantic chunking (split on natural language boundaries or clause markers) creates vectors with stronger semantic focus, improving retrieval precision.

Distractor Analysis

A is Incorrect: Increasing the number of returned results does not improve relevance—it simply retrieves more vectors, likely adding more irrelevant chunks and worsening context noise. Retrieval precision is a chunking quality issue, not a result-count issue.
C is Incorrect: Increasing chunk size directly worsens the described problem by pulling in even more unrelated surrounding clauses. Large chunks dilute semantic signal in the embedding vector.
D is Incorrect: The vector store engine (OpenSearch Serverless vs. Aurora PostgreSQL with pgvector) governs storage and query execution, not chunk content granularity. Changing the database would not fix imprecise chunk boundaries.
E is Incorrect: Replacing semantic search with keyword search eliminates the semantic retrieval capability and still relies on correct chunk boundaries for precise results. It does not address the root cause.

Key Takeaway: Retrieval precision in RAG is primarily governed by chunking strategy at ingestion time—if chunks are too large, similarity scores become diluted, regardless of vector store or query tuning.

Question 5 - Document Preprocessing for Scanned PDFs

A government agency is building a RAG system for historical policy documents stored in Amazon S3 as scanned image-only PDFs (100,000+ pages). The solution must make these documents text-searchable for both keyword queries and vector retrieval. The solution must minimize manual effort and scale cost-effectively.

Which TWO AWS services or features should the ML engineer incorporate into the ingestion pipeline? (Select TWO)

A) Use Amazon Textract to extract text from the scanned PDFs, including layout metadata, before chunking and embedding.
B) Use Amazon Rekognition for text detection, as it is optimized for character recognition in document images.
C) Use Amazon Bedrock Knowledge Bases with the native S3 data source connector to automatically perform OCR on image-only PDFs during ingestion.
D) Use AWS Glue with a Python shell job and PyPDF to extract text from scanned pages, writing text files back to S3 for downstream processing.
E) Use Amazon Comprehend to extract entities from the scanned documents and replace the OCR step entirely.

Click to reveal Answer & Explanation

Correct Answer: A and C

Correct Option Analysis

A is Correct: Amazon Textract is purpose-built for OCR, extracting text and structural elements (headings, tables, forms) from scanned documents, making it the ideal service for converting image-only PDFs to searchable text with layout metadata for downstream chunking.
C is Correct: Amazon Bedrock Knowledge Bases' S3 data source connector can process image-based PDFs during ingestion (when the underlying document processing service is enabled), automatically handling OCR and passing extracted text to the chunking/embedding stages without custom code.

Distractor Analysis

B is Incorrect: Amazon Rekognition is optimized for real-world scene text in images (e.g., street signs, product labels), not dense, high-volume document OCR. For document OCR, Amazon Textract is the correct and higher-accuracy service.
D is Incorrect: A custom PyPDF (or pdf2image) approach on AWS Glue Python shell jobs requires manual orchestration of OCR (e.g., Tesseract), does not automatically preserve layout hierarchy, and adds significant operational overhead when Textract or Bedrock's native ingestion can provide the same capability with less code.
E is Incorrect: Amazon Comprehend is an NLP service for entity detection, sentiment analysis, and topic modeling, not an OCR engine. It cannot replace text extraction from image-only PDFs.

Key Takeaway: For scanned/image-only document corpora, OCR is a prerequisite step—Amazon Textract is the AWS-native document OCR service; Bedrock Knowledge Bases can automate OCR during ingestion, reducing pipeline complexity.

Question 6 - Metadata Extraction for Citation Policy

A healthcare analytics company is implementing a RAG system for medical research documents to support evidence synthesis. The application must cite document sources precisely, including document title, publication date, author names, and page number for each retrieved chunk shown to end users.

The engineering team must ensure that metadata is reliably associated with chunks at ingestion time using Amazon Bedrock Knowledge Bases. However, some documents contain incomplete or missing metadata fields (e.g., missing author names on legacy documents).

What should the engineer do to handle missing metadata gracefully? (Select ONE)

A) Reject documents with missing metadata during ingestion so only complete records enter the vector index.
B) Configure metadata fields as optional (nullable) in the ingestion schema, allowing retrieval to proceed with whatever metadata exists and returning "Not Available" in citation displays.
C) Use Amazon Comprehend to automatically generate missing metadata (e.g., infer author names) and populate all fields, ensuring no gaps.
D) Manually review and fill in missing metadata for every incomplete document before ingestion.
E) Store metadata only in the document filename and rely on chunk text to carry citation information.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: Making metadata fields optional or nullable ensures ingestion continues even when documents lack certain metadata values. The retrieval application can display "Not Available" or fall back to available metadata (e.g., document title) for citation purposes, enabling graceful degradation.

Distractor Analysis

A is Incorrect: Rejecting documents with missing metadata creates gaps in the knowledge base and undermines recall. For a large research corpus where legacy documents often have incomplete metadata, strict validation will prevent potentially valuable chunks from ever being retrievable.
C is Incorrect: Amazon Comprehend can detect named entities such as person names, but it cannot reliably determine which extracted entity is the author versus a referenced researcher, study participant, or historical figure. Auto-populating metadata with inferred values risks fabricating citations.
D is Incorrect: Manual review of 100,000+ documents is operationally infeasible, slow, and costly. Automation should be the default, with manual review as a refinement pass for high-priority gaps only.
E is Incorrect: Relying on filenames or body text for citations lacks structure and does not support pre-filtering in vector search. The vector store query engine cannot reliably parse metadata out of free text.

Key Takeaway: In RAG metadata design, prefer nullable fields to enforce optional metadata, allowing the pipeline to tolerate incomplete source documents without failing ingestion or dropping content.

Question 7 - Embedding Model Configuration for Multilingual Corpus

A global logistics company is building a RAG assistant to help employees find answers across operating procedures written in English, German, Japanese, and Portuguese. The solution uses Amazon Bedrock with Amazon OpenSearch Serverless as the vector store, and queries may be submitted in any of these languages.

The ML engineer must ensure that semantic search works across languages—including cross-lingual query-document matching—without maintaining separate vector indexes for each language.

Which embedding model configuration should the engineer use? (Select ONE)

A) Use separate embedding models for each language: Titan Text Embeddings v2 (English), and language-specific models from other providers, routing queries to the appropriate model based on detected language.
B) Use a multilingual embedding model (available through Amazon Bedrock) that maps text from all supported languages into a shared semantic vector space, enabling cross-lingual retrieval from a single index.
C) Use Amazon Titan Text Embeddings v2 and preprocess all documents by machine-translating them to English using Amazon Translate before ingestion.
D) Index documents in their original languages using separate OpenSearch Serverless collections per language, then perform cross-collection queries.
E) Use a rule-based system that translates user queries to English at runtime and performs English-only retrieval.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: A multilingual embedding model is explicitly trained on multilingual corpora with alignment objectives, allowing text from different languages to be represented in a shared vector space. This enables cross-lingual retrieval from a single index without translation preprocessing or language-specific model routing.

Distractor Analysis

A is Incorrect: Using separate embedding models per language creates separate vector spaces. Cross-lingual queries could not match across spaces without a custom alignment layer, and routing introduces language detection dependency.
C is Incorrect: Machine translation (Amazon Translate) introduces information loss, cost, and latency. It also cannot preserve domain-specific idioms. Multilingual embedding models natively align cross-language semantics without translation artifacts.
D is Incorrect: Storing separate vector collections per language prevents cross-lingual search across collections without manual federation/merge logic, violating both "single index" and operational simplicity.
E is Incorrect: Runtime translation of queries to English relies on translation accuracy and does nothing for documents in other languages; it does not solve cross-lingual document matching.

Key Takeaway: For multilingual RAG applications, choose an embedding model with native multilingual support to keep all language variants in a single semantic space and vector index.

Question 8 - Chunking & Overlap Tradeoff for Context Retention

A customer support team is building a RAG-based Assistant using Amazon Bedrock Knowledge Bases. Their troubleshooting documents contain multi-step procedures where a single step references conditions stated two paragraphs earlier. Initial testing shows that retrieval often returns only the instruction sentence without the preceding condition, leading to incorrect LLM answers.

The ML engineer needs a chunking configuration that retains necessary context across adjacent text segments without significantly increasing the total number of vectors stored.

Which configuration should the engineer select? (Select ONE)

A) Fixed-size chunks of 2,000 tokens with no overlap.
B) Fixed-size chunks of 400 tokens with 20% overlap (80 tokens).
C) No chunking (entire document as one chunk).
D) Fixed-size chunks of 300 tokens with no overlap, paired with an LLM reranker to reconstruct context.
E) Dynamically generated chunks using a custom NLP model to identify conditional sentences.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: Fixed-size chunks with overlap are the canonical solution for context bleed across chunk boundaries. Overlap ensures that the condition from the previous chunk is included in the adjacent chunk's text, allowing the embedding model to capture the full instruction + condition relationship without creating oversized chunks.

Distractor Analysis

A is Incorrect: 2,000-token chunks with no overlap may contain the full procedure but also dilute semantic focus with large amounts of unrelated content, leading to retrieval of broad passages and degraded similarity match quality.
C is Incorrect: Treating entire multi-page troubleshooting documents as single chunks creates enormous vectors with weak semantic resolution, making it nearly impossible for a narrow query to retrieve the specific instruction it needs.
D is Incorrect: 300-token chunks without overlap will definitely separate conditional statements from their dependent instructions across boundaries, and relying on an LLM reranker does not recreate missing context from adjacent chunks that were never retrieved.
E is Incorrect: Building a custom NLP chunking model introduces massive operational overhead (training data, model validation, deployment, maintenance) and is not warranted when standard overlap chunking solves boundary context loss.

Key Takeaway: Use chunk overlap in fixed-size chunking to prevent critical dependencies from being split across chunk boundaries—typically 10–20% of chunk size.

Question 9 - S3 Data Source & Incremental Ingestion for RAG

A financial institution is using Amazon Bedrock Knowledge Bases with an Amazon S3 data source to power a RAG system for investment research reports. New reports are uploaded daily, and a few reports are modified weekly with corrected figures.

To keep retrieval results current and avoid stale information, the team wants to automatically re-sync the knowledge base when S3 objects change. They also want to minimize compute cost on days with no changes.

Which solution should the engineer implement? (Select ONE)

A) Schedule an AWS Glue job to run hourly, scanning the S3 bucket for changes and invoking the Bedrock StartIngestionJob API only when new or modified objects are detected.
B) Configure an S3 Event Notification (PUT, POST, and DELETE) to invoke an AWS Lambda function that triggers StartIngestionJob on Amazon Bedrock Knowledge Bases.
C) Run StartIngestionJob on a nightly cron schedule through Amazon EventBridge Scheduler, regardless of whether new objects were added.
D) Use S3 Object Lambda to intercept read requests and dynamically trigger ingestion, ensuring changes propagate immediately.
E) Enable versioning on the S3 bucket and manually trigger StartIngestionJob through the AWS Management Console after each upload.

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

B is Correct: S3 Event Notifications can natively invoke Lambda functions on object creation or modification events. Lambda then calls the Bedrock Knowledge Bases StartIngestionJob API to incremental sync. The event-driven nature means ingestion only runs when files actually change, minimizing unnecessary compute cost.

Distractor Analysis

A is Incorrect: An hourly Glue job scanning the bucket adds unnecessary compute cost and latency (up to 1 hour to detect changes) when S3 Event Notifications provide immediate, event-driven triggering without the need for a separate Glue scanning job.
C is Incorrect: Nightly syncs mean updates take up to 24 hours to propagate and ingestions run even when no changes have occurred, wasting compute and ingestion jobs on unchanged documents.
D is Incorrect: S3 Object Lambda modifies data on retrieval (read-path), not data ingestion or index updates. It cannot trigger Bedrock Knowledge Bases StartIngestionJob—object lambdas operate on data access, not lifecycle events.
E is Incorrect: Manual triggering through the console is operationally unworkable for daily uploads by multiple users. Human action cannot be relied upon for timely updates and does not scale.

Key Takeaway: For incremental synchronization of Bedrock Knowledge Bases with S3, use S3 Event Notifications → Lambda → StartIngestionJob to enable event-driven and cost-effective data freshness.

Question 10 - Text Preprocessing & Data Quality for RAG

A legal tech startup is building a RAG application over court case documents stored in Amazon S3. The documents contain inconsistent formatting: frequent scanner artifacts ("###", "~~"), footer text on every page with law firm contact information, and duplicate boilerplate disclaimers repeated across all documents.

The ML engineer must prepare the documents to improve chunk quality and retrieval relevance before ingestion into Amazon Bedrock Knowledge Bases (chunking + embedding). The solution must be automated and cost-effective.

Which TWO preprocessing steps should the engineer perform? (Select TWO)

A) Use AWS Glue DataBrew to apply regex-based cleaning recipes that strip scanner artifacts (###, ~~), remove duplicated boilerplate paragraphs, and drop recurring footer lines from all documents.
B) Directly ingest raw PDFs into Bedrock Knowledge Bases without any cleaning, as the embedding model will ignore noise automatically.
C) Use Amazon Comprehend to detect and remove boilerplate disclaimers by entity recognition, assuming all repeated text is noise.
D) Use AWS Lambda to run a lightweight Python preprocessing script that normalizes whitespace, removes control characters, and drops known footer patterns before uploading cleaned text files back to S3.
E) Use Amazon Macie to clean and redact all text artifacts from the corpus before ingestion.

Click to reveal Answer & Explanation

Correct Answer: A and D

Correct Option Analysis

A is Correct: AWS Glue DataBrew provides a visual, low-code transformation interface with built-in recipe steps for regex cleaning, pattern elimination, and de-duplication—allowing the team to standardize text formatting and remove known noise artifacts before ingestion.
D is Correct: AWS Lambda running a Python preprocessing script is a valid, cost-effective, event-driven method for targeted cleanup (normalizing whitespace, removing footer patterns, stripping control characters) that scales automatically and requires no server management.

Distractor Analysis

B is Incorrect: Embedding models capture semantic meaning but do not "ignore" noise or scanner artifacts. Noise in chunks dilutes vector quality and reduces retrieval precision. Raw ingestion of dirty text degrades RAG performance.
C is Incorrect: Amazon Comprehend cannot distinguish "boilerplate disclaimer text" from substantive legal content via entity recognition. Entity detection identifies PII, names, dates, and similar tokens—it is not designed for boilerplate or structural noise removal.
E is Incorrect: Amazon Macie is a data security service for discovering and reporting sensitive data (e.g., PII) across S3—not a text-cleaning tool. It cannot clean or redact text artifacts.

Key Takeaway: RAG ingestion pipelines benefit from automated, targeted text preprocessing before chunking/embedding; use DataBrew for visual cleaning or Lambda for code-based transformations to remove scanner artifacts, footer text, and duplicated boilerplate.