1.2.7
| Question | Answer & Explanation |
|---|---|
| ### Question 1 - Semantic Chunking for Technical Manuals An AI team is building a RAG application to answer employee questions using a corpus of long, highly technical engineering manuals. The team is using Amazon Bedrock Knowledge Bases with an Amazon OpenSearch Serverless vector store. They need to ensure that chunking maintains the semantic boundaries of the text, such as keeping section headers with their corresponding paragraphs, rather than arbitrarily cutting text mid-sentence. The solution must minimize operational overhead and avoid writing custom parsing logic. Which ONE chunking strategy should the team configure in Bedrock Knowledge Bases to meet these requirements? - A) Fixed-size chunking with a small chunk size and a 10% overlap. - B) Semantic chunking to split text based on natural language meaning and topic shifts. - C) Hierarchical chunking with parent-child relationships using default chunk sizes. - D) No chunking, letting the embedding model truncate the manuals. |
Correct Answer: B Correct Option Analysis: - B is Correct: Semantic chunking evaluates the text to identify natural topic shifts and semantic boundaries. It groups related sentences and paragraphs together, ensuring that a section header remains with its corresponding text block, which is ideal for maintaining context in technical manuals without writing custom parsing logic. Distractor Analysis: - A is Incorrect: Fixed-size chunking arbitrarily splits text based on a predefined token count, which will still cut mid-sentence or separate headers from their paragraphs regardless of the small chunk size or overlap. - C is Incorrect: While hierarchical chunking provides parent-child relationships for broader context retrieval, it does not inherently prevent arbitrary mid-sentence splitting at the child level unless paired with semantic boundaries. - D is Incorrect: "No chunking" treats the entire manual as a single chunk, which will likely exceed the embedding model's maximum input token limit and severely dilute the semantic accuracy of the vector representation. > Exam Tip / AWS Best Practice: When document structure and semantic boundaries are more important than strict token limits, use semantic chunking in Amazon Bedrock Knowledge Bases to preserve contextual meaning. |
| ### Question 2 - Metadata Extraction for Financial Transcripts A financial services company is ingesting quarterly earnings call transcripts into a RAG pipeline using Amazon Bedrock Knowledge Bases. Analysts must be able to filter retrieval by the specific fiscal year, quarter, and the company ticker symbol. The engineering team wants to extract and apply this metadata automatically during ingestion without provisioning any custom compute infrastructure (like AWS Lambda) or writing custom parsing scripts. Which ONE approach meets these requirements with the LEAST operational overhead? - A) Create an AWS Lambda function triggered by S3 events to extract metadata from the file name and inject it into the OpenSearch index. - B) Use AWS Glue DataBrew to parse the transcripts, extract the metadata, and store the enriched documents in S3 for Bedrock ingestion. - C) Configure Amazon Bedrock Knowledge Bases to use a Foundation Model (e.g., Claude) for automatic metadata generation during the ingestion process. - D) Store the transcripts in an Amazon DynamoDB table and use a custom data connector in Bedrock to extract the metadata. |
Correct Answer: C Correct Option Analysis: - C is Correct: Amazon Bedrock Knowledge Bases natively supports metadata extraction using Foundation Models. By configuring a knowledge base to use an LLM to generate metadata (like extracting the ticker and quarter from the document content), the team can automatically generate and associate filterable metadata without any custom infrastructure. Distractor Analysis: - A is Incorrect: Using an AWS Lambda function introduces custom compute infrastructure and requires writing parsing logic, violating the "least operational overhead" and "no custom compute" constraints. - B is Incorrect: AWS Glue DataBrew requires setting up visual recipes and running compute jobs, which is more overhead than using the native Bedrock Knowledge Bases metadata extraction feature. - D is Incorrect: DynamoDB is not a native data source for Bedrock Knowledge Bases document ingestion in this context, and creating a custom connector introduces significant unnecessary development overhead. > Exam Tip / AWS Best Practice: To generate metadata with minimal overhead, use Amazon Bedrock Knowledge Bases' native capability to leverage Foundation Models for metadata extraction during ingestion. |
| ### Question 3 - Hierarchical Chunking for Legal Contracts A legal firm is preparing extensive, multi-page contracts for a RAG application using Amazon Bedrock Knowledge Bases. When using fixed-size chunking, the retrieval frequently returns specific clauses out of context, making it difficult for the LLM to understand the broader contractual obligations. The team needs a chunking strategy that links smaller, highly specific chunks to larger parent chunks, ensuring the LLM receives the broader context of the specific clause during generation. The solution must use native Bedrock features. Which ONE chunking strategy should the team implement? - A) Fixed-size chunking with a large overlap percentage. - B) Semantic chunking with a high maximum token limit. - C) Hierarchical chunking (parent-child chunking). - D) No chunking, embedding the entire contract as a single vector. |
Correct Answer: C Correct Option Analysis: - C is Correct: Hierarchical chunking creates parent and child chunks. Child chunks are used for precise vector similarity retrieval, while the parent chunk is returned to the LLM to provide the broader surrounding context, perfectly solving the issue of retrieving clauses out of context. Distractor Analysis: - A is Incorrect: While overlap helps at the boundaries of chunks, it does not establish a parent-child relationship and will not provide the full contextual page or section if a small chunk is matched. - B is Incorrect: Semantic chunking groups by meaning but does not inherently link small retrieval chunks to larger context blocks for the generation phase. - D is Incorrect: Embedding the entire contract dilutes the vector representation and makes it nearly impossible to retrieve specific clauses accurately. > Exam Tip / AWS Best Practice: Use hierarchical chunking when you need high retrieval precision on specific text segments but require the model to have access to the broader surrounding document context during generation. |
| ### Question 4 - Sidecar Metadata Files A healthcare startup is building a RAG application to ingest medical journal articles stored in Amazon S3. They want to use fixed-size chunking but need to ensure that metadata containing the article's publication date and medical specialty is included with every chunk so that the OpenSearch vector store can filter results by date and specialty. The team wants to achieve this using native Amazon Bedrock Knowledge Bases features without writing any custom code. Which ONE method allows the team to associate the required metadata with the generated chunks? - A) Configure an S3 Event Notification to trigger an AWS Lambda function that adds the metadata to each chunk before it is embedded. - B) Store a sidecar metadata JSON file alongside each PDF document in the S3 bucket, and configure the Bedrock Knowledge Base to parse the metadata files during ingestion. - C) Manually update the vector store documents in OpenSearch Serverless using the OpenSearch API after the Bedrock ingestion job completes. - D) Use Amazon Macie to scan the S3 bucket and automatically append the detected metadata tags to the chunks during the embedding process. |
Correct Answer: B Correct Option Analysis: - B is Correct: Amazon Bedrock Knowledge Bases supports the use of sidecar metadata files. By placing a .json.metadata file next to the source document in S3, Bedrock will automatically parse this file and attach the key-value pairs as metadata to all chunks generated from that source document.Distractor Analysis: - A is Incorrect: Triggering a Lambda function to pre-process chunks requires custom code and bypasses the native Bedrock ingestion pipeline, violating the "no custom code" constraint. - C is Incorrect: Manually updating documents in OpenSearch post-ingestion is operationally heavy, prone to error, and defeats the purpose of using a managed Bedrock Knowledge Base. - D is Incorrect: Amazon Macie is a data security service used to discover and protect sensitive data (PII); it does not generate or append publication metadata to vector chunks. > Exam Tip / AWS Best Practice: To attach custom metadata to chunks in Bedrock Knowledge Bases without code, use a sidecar .metadata.json file in the same S3 prefix as the source document. |
| ### Question 5 - Chunking Strategy for Short FAQ Documents An e-commerce company has a product FAQ database where each record is a short, concise question-and-answer pair (e.g., "What is the return policy?" -> "Items can be returned within 30 days."). The team is setting up an Amazon Bedrock Knowledge Base to ingest these FAQs. Each FAQ pair is stored as an individual text file in an Amazon S3 bucket. They want to minimize vector index size and optimize retrieval precision without unnecessarily splitting the short Q&A pairs. Which ONE chunking strategy is the MOST appropriate for this dataset? - A) Fixed-size chunking with a very small token size (e.g., 50 tokens) to ensure fast retrieval. - B) Semantic chunking to group multiple unrelated Q&A pairs into a single chunk. - C) No chunking, treating each Q&A pair file as a single chunk before generating embeddings. - D) Hierarchical chunking to establish parent-child relationships between the question and the answer. |
Correct Answer: C Correct Option Analysis: - C is Correct: When source files are already concise and represent a single logical unit (like a short Q&A pair), "No chunking" is the best strategy. Bedrock will treat the entire file as one chunk, preserving the complete question and answer together for accurate embedding and retrieval. Distractor Analysis: - A is Incorrect: Even with a small token size, fixed-size chunking might split the short Q&A pair if it exceeds the limit, separating the question from the answer and ruining retrieval accuracy. - B is Incorrect: Semantic chunking is unnecessary overhead for a file that is already a single logical unit; it could also combine multiple files if they were batched, diluting the semantic signal. - D is Incorrect: Hierarchical chunking is overkill for a short Q&A pair, as there is no need for a parent-child relationship when the whole text fits easily within a standard embedding context window. > Exam Tip / AWS Best Practice: Use "No chunking" (or document-level chunking) when the source files are already small, self-contained logical units that fit comfortably within the embedding model's token limit. |
| ### Question 6 - Updating Chunks in Bedrock Knowledge Bases A global news agency uses an Amazon Bedrock Knowledge Base to ingest daily news articles into an OpenSearch vector store. An article was published with a major factual error, and the editorial team updated the article file in the Amazon S3 source bucket. The ML team needs to ensure that the RAG application immediately stops returning the outdated, erroneous information and instead retrieves the corrected text. They must do this with the least operational overhead. What is the ONE MOST operationally efficient way to update the vector store with the corrected document? - A) Delete the entire OpenSearch index, modify the S3 object, and run a full ingestion job from the Bedrock Knowledge Base. - B) Modify the S3 object, then run an Amazon Bedrock Knowledge Base ingestion job configured to sync only the updated S3 objects. - C) Programmatically query the OpenSearch index, find the chunks associated with the article, delete them via the OpenSearch API, and manually insert the new chunks. - D) Use AWS Glue to stream the updated S3 object directly into the OpenSearch index, bypassing the Bedrock ingestion job. |
Correct Answer: B Correct Option Analysis: - B is Correct: Bedrock Knowledge Bases ingestion jobs are designed to sync data from the source (S3). Running a new ingestion job will detect the modified S3 object, delete the old chunks from the vector store, generate new chunks and embeddings, and update the index, all natively and automatically. Distractor Analysis: - A is Incorrect: Deleting the entire OpenSearch index and running a full ingestion job is extremely inefficient and causes downtime for the RAG application, violating the least operational overhead constraint. - C is Incorrect: Manually querying and deleting chunks via the OpenSearch API requires deep knowledge of the index schema, custom scripting, and significant operational effort. - D is Incorrect: Using AWS Glue to write directly to OpenSearch bypasses Bedrock's managed embedding generation and chunking pipeline, introducing complex custom infrastructure. > Exam Tip / AWS Best Practice: To update documents in a Bedrock Knowledge Base, simply update the source file in S3 and re-run the ingestion job; Bedrock automatically handles deletions of old chunks and ingestion of new ones. |
| ### Question 7 - Chunking Conversational Transcripts An enterprise is building a RAG application to search through historical customer support chat transcripts using Amazon Bedrock Knowledge Bases. They need a chunking strategy that preserves the conversational flow and ensures that a user's question is chunked together with the agent's response, rather than splitting the question and answer into separate chunks. The team wants to use a native Bedrock chunking strategy that respects natural language boundaries. Which ONE chunking strategy in Amazon Bedrock Knowledge Bases best aligns with preserving natural conversational boundaries? - A) Semantic chunking, which groups text based on semantic meaning and natural topic shifts. - B) Fixed-size chunking with a 100% overlap to capture the surrounding context. - C) Hierarchical chunking configured with a very small child chunk size. - D) No chunking, passing the entire transcript as a single embedding. |
Correct Answer: A Correct Option Analysis: - A is Correct: Semantic chunking uses embeddings to detect natural topic shifts. In a transcript, a user question and the agent's answer represent a single semantic topic or exchange. Semantic chunking will keep them together rather than arbitrarily splitting them at a token limit. Distractor Analysis: - B is Incorrect: 100% overlap with fixed-size chunking is highly inefficient, duplicates storage, and still does not guarantee that a question and answer won't be split at a token boundary. - C is Incorrect: Hierarchical chunking with a small child chunk size will likely split the question and answer into separate child chunks, retrieving only the question without the answer (or vice versa) at the initial vector search stage. - D is Incorrect: Passing an entire long transcript as a single chunk will exceed token limits and completely dilute the vector embedding, making it impossible to retrieve specific Q&A exchanges. > Exam Tip / AWS Best Practice: For conversational data or text with natural topic shifts, semantic chunking prevents splitting related exchanges (like a question and its answer) by grouping text based on meaning. |
| ### Question 8 - Multimodal RAG Document Preparation A retail company is ingesting product catalogs that contain both text descriptions and product images into a RAG pipeline using Amazon Bedrock Knowledge Bases. They want the multimodal embeddings to capture the visual features of the product images as well as the text. They are using an embedding model like Amazon Titan Multimodal Embeddings. The team needs to ensure that the images are correctly processed alongside the text during the document preparation phase without writing custom extraction code. Which ONE document preparation approach correctly supports this multimodal RAG ingestion natively? - A) Store the catalogs as PDF files in Amazon S3, and ensure the Bedrock Knowledge Base is configured to process the PDFs natively with a multimodal embedding model. - B) Use AWS Glue to convert all images into Base64 encoded strings, append them to the text descriptions, and ingest the combined text file into Bedrock. - C) Convert all images to text descriptions using Amazon Textract, discard the original images, and ingest only the extracted text into the Bedrock Knowledge Base. - D) Store text and images in separate S3 buckets, ingest the text into Bedrock Knowledge Bases, and use a separate Lambda function to embed the images. |
Correct Answer: A Correct Option Analysis: - A is Correct: Amazon Bedrock Knowledge Bases supports the native ingestion of documents like PDFs that contain both text and images. When configured with a multimodal embedding model (like Titan Multimodal Embeddings), it can extract and process both modalities to create a unified vector representation. Distractor Analysis: - B is Incorrect: Converting images to Base64 strings and appending them to text is not a supported ingestion format for Bedrock Knowledge Bases, and the embedding model cannot parse raw Base64 text as visual features. - C is Incorrect: Converting images to text using Textract discards the visual features entirely, defeating the purpose of a multimodal RAG pipeline. - D is Incorrect: Splitting the pipeline into separate Bedrock and Lambda components breaks the unified retrieval process and introduces custom infrastructure overhead. > Exam Tip / AWS Best Practice: For multimodal RAG, store documents (like PDFs) containing text and images in S3, and let Amazon Bedrock Knowledge Bases handle the native parsing alongside a multimodal embedding model. |
| ### Question 9 - Pre-Processing PII for RAG Compliance A financial institution is preparing loan agreement documents for a RAG application using Amazon Bedrock Knowledge Bases. Compliance regulations mandate that personally identifiable information (PII), such as Social Security numbers and account numbers, must be redacted from the text before the documents are chunked and embedded into the vector store. The solution must use managed AWS services and ensure zero PII retention in the vector index. Which ONE pre-processing pipeline meets the compliance requirement with the least operational overhead? - A) Ingest the documents into Amazon Bedrock Knowledge Bases, and use Bedrock Guardrails to filter out PII during the retrieval and generation phase. - B) Use Amazon Comprehend to detect and redact PII from the raw documents, save the redacted text to Amazon S3, and then configure the Bedrock Knowledge Base to ingest the redacted files. - C) Chunk the raw documents using AWS Lambda, use a regular expression to mask PII, and send the masked chunks to OpenSearch Serverless. - D) Use Amazon Macie to identify PII in the S3 bucket, automatically redact the files using Macie data protection, and ingest the output. |
Correct Answer: B Correct Option Analysis: - B is Correct: Amazon Comprehend provides a native PII detection and redaction feature. By running the documents through Comprehend to redact PII and saving the output to S3 before Bedrock ingestion, the team guarantees that no PII enters the chunking or embedding process, meeting the zero PII retention requirement using fully managed services. Distractor Analysis: - A is Incorrect: Bedrock Guardrails filter PII during the generation phase. If raw PII is ingested into the vector store, it is already retained, violating the zero retention compliance rule. - C is Incorrect: Using AWS Lambda and regular expressions requires writing and maintaining custom code, which is higher operational overhead than using Amazon Comprehend's managed PII redaction. - D is Incorrect: Amazon Macie is a data discovery service that identifies and alerts on sensitive data, but it does not natively redact or modify the files to remove the PII. > Exam Tip / AWS Best Practice: To ensure zero PII retention in a RAG vector store, use Amazon Comprehend to detect and redact PII from source files before they are passed to the Amazon Bedrock Knowledge Base ingestion pipeline. |
| ### Question 10 - Fixed-Size Chunking Overlap Configuration A software company is using fixed-size chunking to ingest long-form technical blogs into Amazon Bedrock Knowledge Bases. The retrieval results often miss crucial context because a sentence is split exactly at the chunk boundary, separating a code snippet from its preceding explanation. The engineering team wants to adjust the chunking parameters to ensure overlapping text between consecutive chunks without changing the chunking strategy entirely. Which ONE configuration change should the team make to the fixed-size chunking strategy to resolve this issue? - A) Decrease the chunk size to improve the specificity of the embeddings. - B) Increase the overlap percentage to ensure boundaries share a portion of the text. - C) Switch to hierarchical chunking to link parent and child chunks. - D) Append a standard summary disclaimer to the end of each chunk to provide missing context. |
Correct Answer: B Correct Option Analysis: - B is Correct: In fixed-size chunking, increasing the overlap percentage ensures that a specified number of tokens from the end of one chunk are repeated at the beginning of the next. This directly solves the problem of a sentence or code snippet being split at the boundary by guaranteeing surrounding context is present in adjacent chunks. Distractor Analysis: - A is Incorrect: Decreasing the chunk size makes chunks smaller but does not prevent boundaries from splitting sentences; it might actually increase the frequency of split context. - C is Incorrect: The scenario states the team wants to adjust parameters without changing the chunking strategy entirely. Switching to hierarchical chunking violates this constraint. - D is Incorrect: Appending a standard disclaimer does not retrieve the missing context from the source document; it just adds boilerplate text, which does not solve the semantic split. > Exam Tip / AWS Best Practice: When using fixed-size chunking, configure an overlap percentage (e.g., 10-20%) to mitigate context loss at chunk boundaries and keep related sentences intact across adjacent chunks. |