Skill 3.2.7: Create and manage Amazon Bedrock knowledge bases with vector database configurations, document indexing, and retrieval optimization
| Question | Answer & Explanation |
|---|---|
| ### Question 1 - Bedrock Knowledge Bases Vector Store Selection for Hybrid Search A retail enterprise is building a generative AI assistant using Amazon Bedrock Knowledge Bases. The assistant must search through product manuals and exact alphanumeric part numbers in a single query. The architecture requires a vector store that supports hybrid search over a filterable text field, and the team must minimize operational maintenance overhead. Which vector store configuration should the ML engineer choose? Options: A) Amazon Neptune B) Amazon S3 C) Amazon OpenSearch Serverless D) Amazon RDS for PostgreSQL |
Correct Answer: C Correct Options Analysis: - C is Correct: Amazon OpenSearch Serverless is a fully managed vector store option for Bedrock Knowledge Bases that natively supports hybrid search (combining dense vector search with sparse lexical search like BM25) over a filterable text field. It also requires minimal operational overhead compared to a managed cluster. Distractor Analysis: - A is Incorrect: Amazon Neptune is a graph database vector store option, optimized for retrieval that follows relationships between entities, not for hybrid text and vector search. - B is Incorrect: Amazon S3 is object storage. While highly cost-effective for large vector sets queried less often, it does not natively support hybrid search with filterable text fields in the same manner as a search service. - D is Incorrect: While Amazon Aurora PostgreSQL with pgvector is supported by Bedrock and keeps embeddings beside relational records, it does not inherently provide the same optimized out-of-the-box hybrid search (lexical + semantic) capabilities as OpenSearch. Exam Tip / AWS Best Practice: Choose OpenSearch Serverless for Bedrock Knowledge Bases when hybrid search (exact keyword + semantic similarity) and low operational overhead are required. |
| ### Question 2 - Configuring Index Dimensions and Field Mappings An AI team is configuring an Amazon Bedrock Knowledge Base using an Amazon Titan embedding model. The team plans to ingest 1,000 PDF documents, but wants to ensure that metadata attributes like "department" and "doc_type" can be used to filter retrieval later. The solution must avoid the need to completely reindex the documents later due to misconfiguration. Which TWO actions must the engineer take before starting the ingestion job? (Select TWO) Options: A) Configure the vector index dimensions to match the output dimensions of the selected Amazon Titan embedding model. B) Define the field mapping in the vector store to explicitly declare which fields hold the vector, the text chunk, and the metadata. C) Enable high-resolution concurrency metrics on the vector store to handle ingestion spikes. D) Deploy an AWS Lambda function to pre-filter the metadata before the embeddings are generated. E) Configure a target tracking scaling policy on the OpenSearch cluster. |
Correct Answer: A and B Correct Options Analysis: - A is Correct: The index dimensions in the vector store must exactly match the output dimensions of the chosen embedding model. This cannot be changed after ingestion without reindexing. - B is Correct: Field mappings must be declared before ingestion so the vector store knows exactly how to store and query the vector, text chunk, and metadata. Modifying this afterward requires a full reindex. Distractor Analysis: - C is Incorrect: High-resolution concurrency metrics are used for Application Auto Scaling of SageMaker endpoints, not for vector store ingestion processes. - D is Incorrect: Bedrock Knowledge Bases natively handles metadata parsing and filtering; a custom Lambda function introduces unnecessary operational overhead. - E is Incorrect: Scaling policies handle compute capacity, not schema or dimension configuration for vector indexes. Exam Tip / AWS Best Practice: Index dimensions and field mappings are immutable post-ingestion properties. Always verify embedding dimensions and declare field mappings before running the Bedrock ingestion job. |
| ### Question 3 - Optimizing Retrieval with Filters and Reranking An enterprise HR assistant uses Amazon Bedrock Knowledge Bases to answer employee policy questions. Currently, the retrieval pipeline returns semantically similar text chunks from across the entire organization, leading to inaccurate answers for region-specific policies. The architecture requires that only documents from the user's specific region are considered, and the most relevant chunks are prioritized at the top of the response. Which combination of retrieval configurations satisfies these requirements? (Select TWO) Options: A) Increase the top-k result count to ensure all regions are captured. B) Apply a metadata filter to restrict the candidate set to the user's specific region before similarity is measured. C) Disable hybrid search to rely solely on dense vector similarity. D) Enable a reranking model (such as Amazon Rerank model) to reorder the retrieved chunks based on relevance. E) Implement an S3 event notification to trigger re-ingestion of regional documents. |
Correct Answer: B and D Correct Options Analysis: - B is Correct: Metadata filtering narrows the candidate set to a specific subset (e.g., region) before similarity is measured, ensuring only relevant documents are retrieved. - D is Correct: A reranking model re-evaluates the retrieved chunks and reorders them to place the most contextually relevant information at the top, improving answer accuracy. Distractor Analysis: - A is Incorrect: Increasing top-k captures more chunks but does not filter out irrelevant regions, which could confuse the LLM. - C is Incorrect: Disabling hybrid search reduces precision for exact keyword matches and does nothing to solve the region-filtering requirement. - E is Incorrect: S3 event notifications handle ingestion triggers, not query-time retrieval optimization or filtering. Exam Tip / AWS Best Practice: Turn retrieval into a pipeline by combining metadata filtering (to narrow the scope) with reranking (to optimize relevance order) rather than relying on a single vector similarity search. |
| ### Question 4 - Incremental Document Indexing in Bedrock A financial services company has an active Amazon Bedrock Knowledge Base containing 50,000 indexed policy documents stored in Amazon S3. The compliance team updates 15 existing PDF documents and adds 5 new ones to the S3 bucket. The ML engineer triggers a new ingestion job in the Bedrock Knowledge Base. The solution must be highly efficient and minimize processing costs. What will happen during this new ingestion job? Options: A) The ingestion job will delete the existing vector index and re-process all 50,020 documents from scratch. B) The ingestion job will only process the 20 changed and newly added documents since the last sync. C) The ingestion job will fail because the S3 bucket is already mapped to the Knowledge Base. D) The ingestion job will process all documents but skip generating new embeddings for the 50,000 unchanged files. |
Correct Answer: B Correct Options Analysis: - B is Correct: Amazon Bedrock Knowledge Bases ingestion jobs support incremental syncs. When triggered, the job identifies what has changed in the data source since the last ingestion and processes only those new or modified documents, saving time and compute costs. Distractor Analysis: - A is Incorrect: Bedrock does not drop and rebuild the entire index on every sync; it intelligently updates only the delta. - C is Incorrect: An S3 bucket can be synced multiple times; triggering a new job is the standard procedure for updating the knowledge base. - D is Incorrect: The ingestion job does not scan or process unchanged documents at all; it identifies and processes only the changes. Exam Tip / AWS Best Practice: Bedrock Knowledge Bases ingestion jobs process only changed or newly added documents, making incremental updates highly efficient. |
| ### Question 5 - Low-Cost Vector Store for Infrequent Queries A media archival company is storing billions of text embeddings for historical video transcripts. These transcripts are queried very infrequently (less than 10 times a month) by internal researchers. The architecture requires the absolute most cost-effective vector store solution available within Amazon Bedrock Knowledge Bases, accepting a trade-off in query latency. Which vector store option should the team select? Options: A) Amazon OpenSearch Serverless with provisioned capacity B) Amazon Aurora PostgreSQL with pgvector C) Amazon Neptune D) Object storage for vectors (e.g., S3) |
Correct Answer: D Correct Options Analysis: - D is Correct: Object storage for vectors is the low-cost option for large vector sets that are queried less often. It trades off high query latency and lower feature sets for significant cost savings on massive datasets. Distractor Analysis: - A is Incorrect: OpenSearch Serverless is designed for robust search capabilities and higher throughput, making it too expensive for infrequent queries on billions of vectors. - B is Incorrect: Aurora PostgreSQL is a relational database vector store, optimized for keeping embeddings beside records, but it is not the lowest cost option for massive, infrequently queried vector sets. - C is Incorrect: Amazon Neptune is a graph database, optimized for relationship-based retrieval, not for low-cost bulk vector storage. Exam Tip / AWS Best Practice: For massive vector sets queried infrequently where cost is the primary constraint, object storage is the preferred vector store choice. |
| ### Question 6 - Retrieving Relational and Embedding Data Together An e-commerce platform uses Amazon Bedrock Knowledge Bases to power a product recommendation chatbot. The engineering team needs a vector store where the vector embeddings sit directly beside the existing product inventory records (price, stock status, SKU) to ensure fast, transactionally consistent reads between the relational data and the vector search results. Which vector store configuration best meets this requirement? Options: A) Amazon Neptune B) Amazon OpenSearch Serverless C) Amazon Aurora PostgreSQL with pgvector D) Amazon S3 with metadata filtering |
Correct Answer: C Correct Options Analysis: - C is Correct: Amazon Aurora PostgreSQL with pgvector is a relational database option that keeps the embeddings beside the records they describe. This enables transactional consistency and allows queries to combine vector similarity searches with standard SQL relational queries on inventory data. Distractor Analysis: - A is Incorrect: Neptune is a graph database, optimized for entity relationships, not for relational inventory data alongside vectors. - B is Incorrect: OpenSearch Serverless is a search service, not a relational database; keeping it in sync with transactional inventory data requires additional pipelines. - D is Incorrect: S3 object storage cannot provide transactionally consistent reads alongside a relational inventory system. Exam Tip / AWS Best Practice: Choose a relational vector store like Amazon Aurora PostgreSQL when embeddings must reside directly alongside existing relational records for transactional consistency. |
| ### Question 7 - Graph-Based Retrieval Optimization A pharmaceutical research company is mapping relationships between drugs, active ingredients, side effects, and clinical trials. They are using Amazon Bedrock Knowledge Bases and need a vector store that supports retrieval that follows relationships between entities, allowing the agent to traverse how a specific ingredient interacts with various trials. Which vector store should the ML engineer provision? Options: A) Amazon OpenSearch Service B) Amazon Neptune C) Amazon RDS for MySQL D) Amazon S3 |
Correct Answer: B Correct Options Analysis: - B is Correct: Amazon Neptune is a graph database that supports vector search and is specifically designed for retrieval that follows relationships between entities, such as traversing connections between ingredients, drugs, and trials. Distractor Analysis: - A is Incorrect: OpenSearch is excellent for text and hybrid search but is not optimized for complex graph traversals across highly interconnected entities. - C is Incorrect: RDS for MySQL is a relational database, not a graph store, and does not natively optimize for multi-hop relationship traversals. - D is Incorrect: S3 is object storage and does not support graph traversals natively. Exam Tip / AWS Best Practice: Use Amazon Neptune as a Bedrock Knowledge Base vector store when the retrieval logic requires traversing complex, multi-hop relationships between entities. |
| ### Question 8 - Adjusting Retrieval Result Count A support agent powered by Amazon Bedrock Knowledge Bases is providing answers based on technical documentation. Engineers have noticed that the agent often misses critical context because it only retrieves the top 3 most similar text chunks. They want to increase the pool of candidate text chunks provided to the foundation model to 5, without changing the chunking strategy. Which configuration must be modified to achieve this? Options: A) Increase the max_tokens parameter on the foundation model.B) Update the top_k value in the Bedrock Knowledge Base retrieval configuration.C) Increase the instance count of the OpenSearch Serverless collection. D) Modify the vector index dimensions to support a larger search space. |
Correct Answer: B Correct Options Analysis: - B is Correct: The top_k value (or number of results) in the Bedrock Knowledge Base retrieval configuration dictates how many text chunks are returned from the vector store and passed to the foundation model for generating an answer. Updating this from 3 to 5 solves the issue.Distractor Analysis: - A is Incorrect: max_tokens controls the length of the generated output, not the number of context chunks retrieved from the vector store.- C is Incorrect: Increasing the instance count of OpenSearch scales the compute capacity of the vector store, but does not change how many results are returned in the API call. - D is Incorrect: Vector index dimensions relate to the embedding model's output, not the number of results returned. Exam Tip / AWS Best Practice: The top_k parameter in the retrieval configuration controls the volume of context chunks fed into the LLM's context window. |
| ### Question 9 - Pre-requisites for Metadata Filtering An enterprise is configuring an Amazon Bedrock Knowledge Base to ingest Word documents. The team wants to ensure that the retrieval pipeline can filter documents based on the author's name and the publication year. The documents are stored in Amazon S3, and the metadata is stored in a separate JSON manifest file alongside the documents. What must the ML engineer do to enable this filtering behavior during retrieval? Options: A) Configure a custom AWS Lambda function to intercept queries and drop results not matching the metadata. B) Map the metadata fields in the Bedrock Knowledge Base data source configuration so they are ingested alongside the text chunks. C) Rely on the foundation model's intrinsic ability to read the JSON files in S3 and ignore non-matching results. D) Configure a VPC endpoint between the Bedrock service and the S3 bucket to secure the metadata. |
Correct Answer: B Correct Options Analysis: - B is Correct: To use metadata for filtering during retrieval, the metadata must be explicitly mapped and ingested alongside the text chunks into the vector store. Bedrock Knowledge Bases allows you to define metadata fields during data source configuration. Distractor Analysis: - A is Incorrect: Using a Lambda function to post-filter results introduces high latency and operational overhead, and defeats the purpose of native vector store filtering. - C is Incorrect: Foundation models do not inherently read external JSON manifest files in S3 to filter context; retrieval filtering must happen at the vector store level before the LLM is invoked. - D is Incorrect: A VPC endpoint secures network traffic but has no bearing on metadata parsing or filtering logic. Exam Tip / AWS Best Practice: Metadata turns retrieval into a pipeline; you must explicitly map metadata fields during ingestion to enable pre-filtering at query time. |
| ### Question 10 - Modifying Immutable Vector Store Properties A development team has an active Amazon Bedrock Knowledge Base storing 100,000 support tickets in an OpenSearch Serverless collection. The team decides to upgrade to a larger, more advanced embedding model to improve semantic accuracy. The new embedding model generates 1536 dimensions instead of the 768 dimensions produced by the previous model. What must the team do to implement this change with the least operational overhead? Options: A) Update the existing OpenSearch Serverless collection configuration to increase the dimension count to 1536, then trigger an ingestion job. B) Re-create the OpenSearch Serverless collection with 1536 dimensions and re-ingest all 100,000 support tickets from scratch. C) Apply a reranking model to the existing 768-dimension vectors to simulate 1536-dimension accuracy. D) Configure a target tracking scaling policy on OpenSearch Serverless to handle the larger embedding payloads. |
Correct Answer: B Correct Options Analysis: - B is Correct: Index dimensions in a vector store are immutable once set. Changing the embedding model to one with different dimensions requires re-creating the vector index/collection with the new dimension count and fully reindexing all documents. Distractor Analysis: - A is Incorrect: OpenSearch Serverless collections do not allow dynamically modifying the index dimension count after creation. - C is Incorrect: Reranking models reorder retrieved results; they cannot alter the underlying embedding dimensions or replace the accuracy of a better embedding model. - D is Incorrect: Scaling policies adjust compute capacity, not the structural schema or dimension size of the vector index. Exam Tip / AWS Best Practice: Vector index dimensions are immutable and must match the embedding model. Changing the embedding model dimension size requires re-creating the index and reindexing all data. |