Skip to content

3.2.7

Question 1 - Bedrock Knowledge Base Vector Store Configuration

A global FinTech enterprise is building a generative AI application for internal financial analysts using Amazon Bedrock Knowledge Bases. The application must answer questions by performing semantic search over unstructured financial reports while simultaneously filtering results based on company year-end reporting periods (metadata filters). These retrieval operations must occur with minimal operational overhead and the infrastructure must support hybrid search in the future without requiring re-architecting the system.

Which configuration should the ML engineer choose for the Bedrock Knowledge Base vector store? (Select ONE)

  • A) Configure the Knowledge Base to store vector embeddings directly in Amazon S3 as .npy files, enabling serverless access and minimal operational overhead.
  • B) Configure the Knowledge Base with an Amazon OpenSearch Serverless vector collection, defining the vector field, text field, and metadata fields in the mapping before ingestion.
  • C) Configure the Knowledge Base with an Amazon Aurora PostgreSQL cluster, storing embeddings in a vector column to keep embeddings alongside existing financial records.
  • D) Configure the Knowledge Base with Amazon Neptune to leverage graph-based relationships between financial entities during retrieval.
  • E) Configure the Knowledge Base to store embeddings in Amazon DynamoDB using a composite key for fast, low-latency lookups.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Amazon OpenSearch Serverless is a native vector store option for Amazon Bedrock Knowledge Bases that provides managed vector search with minimal operational overhead and supports hybrid search, along with metadata filtering via filterable fields in the index mapping.

Distractor Analysis

  • A is Incorrect: Amazon Bedrock Knowledge Bases does not support Amazon S3 as a vector store. S3 is an object storage option for source documents only; it cannot perform vector similarity searches.
  • C is Incorrect: While Amazon Aurora PostgreSQL supports the pgvector extension, using a relational database cluster for vector storage introduces more operational complexity (provisioning, scaling, maintenance) compared to OpenSearch Serverless, and it does not natively support hybrid search in a single query without additional configuration.
  • D is Incorrect: Neptune is a graph database that excels at relationship traversal, not as a primary vector index for semantic search within Bedrock Knowledge Bases. Graph stores are not a supported Knowledge Base vector store option.
  • E is Incorrect: DynamoDB is not a vector store. It does not natively support vector similarity search (k-NN), and hybrid search with lexical matching is not a native DynamoDB capability.

Key Takeaway: When Bedrock Knowledge Bases requires metadata filtering and future hybrid search, choose Amazon OpenSearch Serverless or Managed Cluster as the vector store. The field mapping must be defined before ingestion because it cannot be changed later without full reindexing.

Question 2 - Bedrock Knowledge Base Ingestion and Resync Strategy

An enterprise legal team has configured an Amazon Bedrock Knowledge Base using an S3 bucket data source containing over 500,000 legal documents. The ingestion job initially takes 6 hours to process all documents. The team receives new case documents daily, and they need to ensure the knowledge base is updated with only the new and modified documents. The requirement states that ingestion must be cost-effective and minimize manual intervention.

Which approach should the team implement for ongoing ingestion? (Select ONE)

  • A) Schedule a nightly AWS Glue job that rebuilds the entire OpenSearch Serverless collection from scratch by deleting and re-uploading all vector embeddings.
  • B) Configure an S3 Event Notification to trigger an AWS Step Functions workflow that calls the Bedrock Knowledge Base StartIngestionJob API whenever new documents are uploaded.
  • C) Manually invoke the ingestion job every morning through the AWS Management Console after uploading documents to S3.
  • D) Use a scheduled SageMaker Processing job that re-indexes all documents on a weekly basis to ensure consistency.
  • E) Implement a custom Lambda function that parses new documents, generates embeddings using Amazon Bedrock Titan, and writes them to OpenSearch.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Amazon Bedrock Knowledge Bases ingestion jobs support incremental sync when invoked against an existing data source. Automating the StartIngestionJob call through Step Functions after an S3 event provides a serverless, event-driven approach that only processes changed documents, minimizing cost and manual intervention.

Distractor Analysis

  • A is Incorrect: Rebuilding the entire vector collection from scratch on a nightly basis is extremely wasteful and costly, since it re-processes 500,000+ documents unnecessarily. Bedrock Knowledge Bases supports incremental ingestion natively.
  • C is Incorrect: Manually invoking the ingestion job every morning is labor-intensive, error-prone, and does not align with the "minimize manual intervention" requirement.
  • D is Incorrect: Using SageMaker Processing for re-indexing bypasses the managed Bedrock Knowledge Bases ingestion pipeline entirely and requires custom Spark/python code, adding unnecessary operational overhead.
  • E is Incorrect: Writing a custom Lambda that parses files and generates embeddings duplicates what Bedrock Knowledge Bases does automatically, resulting in additional ops complexity and bespoke code maintenance.

Key Takeaway: Bedrock Knowledge Bases provides automatic incremental ingestion when StartIngestionJob is re-invoked on the same data source — only new or updated documents are processed. Automate the invocation with serverless event-driven patterns rather than rebuilding indexes manually.

Question 3 - Retrieval Optimization with Hybrid Search and Reranking

A healthcare provider is building a patient support chatbot using Amazon Bedrock Knowledge Bases with Amazon OpenSearch Serverless. The chatbot frequently receives queries containing medical codes (e.g., "ICD-10 code E11.9") and must return both exact code documentation and semantically relevant patient education material. The procurement team wants the solution to deliver highest retrieval accuracy while maintaining minimal operational overhead.

Which retrieval configuration accomplishes this? (Select ONE)

  • A) Use pure semantic search (k-NN) with a high result count (top_k of 25) and rely on Bedrock's default ranking.
  • B) Use hybrid search enabled in Bedrock Knowledge Bases with both vector (k-NN) and lexical (BM25) components, and configure a reranking model in the retrieval pipeline.
  • C) Use a custom Lambda function that applies TF-IDF to all documents after retrieval from OpenSearch to reorder results.
  • D) Use node-level metadata filters (e.g., only "patient education" category) to avoid pulling medical code documentation from the index.
  • E) Store medical codes in a separate DynamoDB table and query that table first, merging results with OpenSearch retrieval.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Hybrid search combines dense vector similarity (semantic meaning) with sparse lexical search (BM25 for exact keyword matching like medical codes) and reranking improves result ordering. Amazon Bedrock Knowledge Bases supports hybrid search and integration with rerank models. This maximizes retrieval accuracy for mixed query types while minimizing custom code.

Distractor Analysis

  • A is Incorrect: Pure semantic search with high top_k only increases the number of retrieved candidates. It does not ensure exact keyword/documentation matches for medical codes because dense embeddings can fail on precise alphanumeric identifiers.
  • C is Incorrect: Custom Lambda with TF-IDF requires building and maintaining a custom lexical search layer and reranking logic, which directly violates minimal operational overhead.
  • D is Incorrect: Metadata filters shrink the candidate set by category but do not improve synonym/code precision. It excludes relevant documentation rather than solving the hybrid matching problem.
  • E is Incorrect: Adding a separate DynamoDB table and merging results introduces a second retrieval system and custom merging logic — significantly more operational complexity than using built-in hybrid search.

Key Takeaway: When exact keyword matching and semantic similarity are both needed, enable hybrid search on OpenSearch (or OpenSearch Serverless) within Bedrock Knowledge Bases. Add a rerank model in the retrieval pipeline to boost top-1 accuracy without additional custom infrastructure.

Question 4 - Embedding Dimension Mismatch Resolution

An ML engineering team is building a chatbot on Amazon Bedrock Knowledge Bases for internal company documentation. The team initially used Amazon Titan Text Embeddings v1 (dimension 1536) and created an OpenSearch Serverless vector collection with those dimensions. The team recently decided to switch to Amazon Titan Text Embeddings v2 (dimension 1024) for better performance. The new embedding model outputs 1024-dimensional vectors at ingestion time. They immediately start an ingestion job. The job fails with a dimension mismatch error.

What must the team do to resolve this? (Select ONE)

  • A) Update the existing OpenSearch Serverless collection mapping to accept the new vector dimension field using the UpdateVectorIndex API.
  • B) Delete the existing OpenSearch collection and create a new collection with dimensions matching the new embedding model (1024), then update the Bedrock Knowledge Base embedding model and re-ingest documents.
  • C) Configure a SageMaker Processing job to pad vectors to 1536 dimensions with zeros before writing to OpenSearch.
  • D) Keep the original OpenSearch collection and reduce the new embedding model's dimension by applying PCA in a Lambda before writing to OpenSearch.
  • E) Disable vector validation in the Bedrock Knowledge Base ingest configuration to bypass dimension checking.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Vector dimension is immutable once an OpenSearch Serverless collection (or any vector index with k-NN plugin) is created. Changing the embedding model requires creating a new vector collection with the correct dimension (1024), updating the Bedrock Knowledge Base to point to the new collection and embedding model, and re-ingesting documents from scratch.

Distractor Analysis

  • A is Incorrect: You cannot demote/alter the dimension of an existing k-NN vector field in OpenSearch. Vector properties such as dimension and engine/algorithm are fixed at index creation time and cannot be changed via an update or remapping API.
  • C is Incorrect: Padding or extending vectors with zeros to match the old dimension would corrupt the semantic meaning captured in the embedding space, and OpenSearch's k-NN plugin expects vectors that align with the original embedding model.
  • D is Incorrect: Running PCA or any post-hoc dimensionality reduction on embeddings through Lambda is not a valid Bedrock Knowledge Bases pattern. It adds significant operational complexity and alters vector semantics.
  • E is Incorrect: There is no feature to bypass embedding dimension validation. The vector collection's index will reject vector writes with mismatched dimensions.

Key Takeaway: Vector index dimensions are immutable. Whenever you change the embedding model in Bedrock Knowledge Bases, you must create a new vector collection with matching dimension size and re-ingest all documents. Plan embedding model versions carefully to avoid expensive reindexing.

Question 5 - Bedrock Knowledge Base IAM Permissions and Encryption

A finance company is setting up an Amazon Bedrock Knowledge Base that ingests documents from a sensitive S3 bucket (containing M&A data) and stores embeddings in an Amazon OpenSearch Serverless collection. The security team mandates:

  1. The vector index at-rest must be encrypted using a customer-managed KMS key (CMK).
  2. The Bedrock Knowledge Base execution role must have the least privilege to read source documents from S3 and write embeddings to OpenSearch.

Which two actions are required? (Select TWO)

  • A) Attach a resource-based policy to the S3 bucket allowing s3:GetObject only to the Bedrock Knowledge Base service principal (bedrock.amazonaws.com).
  • B) Attach a resource-based policy to the OpenSearch Serverless collection allowing aoss:APIAccessAll to all IAM principals in the same AWS account.
  • C) Define an encryption policy in the OpenSearch Serverless security configuration that references the KMS CMK ARN, and specify this policy when creating the vector collection.
  • D) Grant the Bedrock Knowledge Base execution role the AmazonS3FullAccess managed policy to ensure simpler S3 access management.
  • E) Create an IAM role for the Knowledge Base with OpenSearch Serverless permissions (aoss:APIAccessAll) restricted to the specific collection ARN.
Click to reveal Answer & Explanation

Correct Answer: C and E

Correct Options Analysis

  • C is Correct: OpenSearch Serverless encryption policies must be defined before creating the collection. Referencing a customer KMS CMK ARN ensures the vector index at rest is encrypted with a KMS key controlled by the security team.
  • E is Correct: To allow Bedrock Knowledge Bases to write embeddings to OpenSearch Serverless, the Knowledge Base IAM execution role must have the necessary aoss: API actions (e.g., aoss:APIAccessAll), scoped to the specific collection ARN to enforce least privilege.

Distractor Analysis

  • A is Incorrect: S3 bucket resource-based policies for Amazon Bedrock Knowledge Bases are required for direct access via service principal in certain isolated configurations, but the question asks for least privilege on the execution role. Additionally, the bucket policy alone does not cover OpenSearch permissions.
  • B is Incorrect: Granting aoss:APIAccessAll to all principals in the account violates least privilege. This would allow any IAM user or role in the account to access the vector store, which is not acceptable for sensitive data.
  • D is Incorrect: AmazonS3FullAccess gives access to all S3 buckets and objects in the account, not just the source bucket, directly violating the least privilege principle.

Key Takeaway: For Bedrock Knowledge Bases with OpenSearch Serverless, encryption policies (KMS CMK) and IAM/data access policies must be properly defined and scoped to specific resources before collection creation, and the execution role must follow least privilege (specific ARN scoping).

Question 6 - Bedrock Knowledge Base Source Document Sync Scheduling

An e‑commerce company has a product catalog stored as JSON files in an S3 bucket. These files are updated hourly as new products are added or prices change. The company wants to deploy an Amazon Bedrock Knowledge Base for a shopping assistant chatbot. The chatbot must provide accurate product information with lowest latency for product data freshness. The team must automate the ingestion process with minimal operational overhead.

Which strategy should be used for ingestion? (Select ONE)

  • A) Configure a CloudWatch Events rule that triggers StartIngestionJob on the Bedrock Knowledge Base every 60 minutes using the Knowledge Base's data source ID.
  • B) Use a SageMaker Model Monitoring schedule that checks for S3 changes every hour and manually re-ingests using a custom PyTorch job.
  • C) Set up an Amazon Kinesis Data Stream from S3 events, process with AWS Glue, and write to OpenSearch using a custom connector.
  • D) Configure an S3 Event Notification that sends notifications to Amazon SQS and have the Bedrock Knowledge Base poll the queue via an SQS data source.
  • E) Use a Step Functions workflow triggered by S3 PutObject events that invokes StartIngestionJob API on-demand for each new file.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Options Analysis

  • A is Correct: The Bedrock Knowledge Base ingestion job API supports scheduling via CloudWatch Events/EventBridge. Running StartIngestionJob every 60 minutes ensures the product catalog is updated frequently. Since Bedrock performs incremental sync (processing only new/changed files), this provides low data latency with minimal operational overhead.

Distractor Analysis

  • B is Incorrect: SageMaker Model Monitoring and custom PyTorch ingestion is a heavy, custom ML pipeline that bypasses the managed ingestion job of Bedrock Knowledge Bases, adding unnecessary operational overhead.
  • C is Incorrect: Kinesis + Glue + custom connector adds a streaming pipeline layer, which is overkill for S3 data that can be read directly by Bedrock Knowledge Bases. This violates minimal operational overhead.
  • D is Incorrect: Knowledge Bases does not support an SQS data source directly. Supported data source connectors include S3, Confluence, SharePoint, Salesforce, and web crawler, not a polled SQS queue.
  • E is Incorrect: While Step Functions can trigger StartIngestionJob on-demand, doing so on every S3 Put event could lead to a huge number of ingestion jobs and throttling. A scheduled, throttled invocation (e.g., hourly) is more efficient and lower overhead.

Key Takeaway: For time-sensitive freshness in Bedrock Knowledge Bases, schedule StartIngestionJob with EventBridge/CloudWatch Events (e.g., hourly). Bedrock handles incremental sync and throttling for you.

Question 7 - Retrieval Filtering and Results Count Configuration

An internal IT helpdesk has deployed a Bedrock Knowledge Base to answer employee queries. Due to the presence of access-control metadata on each document, the security team requires that employees can only retrieve documents from their own department (e.g., department: "HR", department: "Engineering"). The knowledge base contains 1 million documents, and 80% belong to Engineering. The ML engineer must configure retrieval so that:

  • Filtering is applied before semantic search (pre-filtering).
  • The number of candidates returned to the FM is 5.
  • The solution minimizes Bedrock API token usage.

Which retrieval configuration meets these requirements? (Select ONE)

  • A) Set top_k=5 on the Knowledge Base retrieve API and use a metadata filter (department equals the user's department). Apply filtering by post-processing results in a Lambda function.
  • B) Use a SageMaker Clarify explanation call to enforce pre-filtering on metadata before Bedrock returns results.
  • C) Configure the Knowledge Base's retrieval to use metadata filtering (query-time filters on department) with top_k=5. The filter is automatically applied before vector similarity search.
  • D) Set top_k=100 and, after retrieval, filter the 100 results down to the department-specific items using an application-level filter, then pass the top 5 to the FM.
  • E) Store each department's documents in a separate Knowledge Base (one per department) and query only the relevant knowledge base with top_k=5.
Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

  • C is Correct: Bedrock Knowledge Bases supports query-time metadata filtering on the retrieval API. Filters are applied on the metadata fields before scoring, narrowing the candidate set. Setting top_k=5 returns only five results to the FM, minimizing token consumption.

Distractor Analysis

  • A is Incorrect: Post-processing in Lambda after Bedrock retrieval requires fetching a larger candidate set to ensure department diversity, wasting tokens and adding custom code. Metadata filters in the API are native and more efficient.
  • B is Incorrect: SageMaker Clarify is used for bias detection and explainability, not for query-time retrieval filtering in Bedrock Knowledge Bases.
  • D is Incorrect: Fetching top_k=100 and then filtering application-side means tokens are already spent on irrelevant documents. Pre-filtering with metadata filters ensures the retrieval only searches within the department subset.
  • E is Incorrect: Maintaining separate Knowledge Bases per department multiplies infrastructure (100+ knowledge bases in a large enterprise), which is operationally heavy and does not scale. Native metadata filtering is the correct approach.

Key Takeaway: Bedrock Knowledge Bases provides query-time metadata pre-filtering that restricts the vector search to specific values before similarity is evaluated. Use it to enforce access control or segment retrieval while keeping top_k small to reduce token usage.

Question 8 - Knowledge Base Chunking Strategy Optimization

A customer support center ingests product manuals (PDF) into Amazon Bedrock Knowledge Bases. Most responses require retrieving step-by-step installation instructions. However, the current retrieval pipeline returns fragmented, incomplete instructions because the default chunking splits the documents every 300 tokens with no overlap. The team wants to improve the quality of retrieved chunks without rebuilding the entire knowledge base from scratch and with minimal operational overhead.

What action should the ML engineer take? (Select ONE)

  • A) Write a custom Lambda function that overrides the chunking logic in the Bedrock ingestion pipeline by pre-chunking PDFs and storing them in a new S3 bucket before ingestion.
  • B) Update the Bedrock Knowledge Base data source chunking configuration to use semantic chunking or increase the fixed chunk size and overlap, then trigger a re-sync of the data source.
  • C) Delete the existing OpenSearch collection, create a new one with larger vector dimensions, and re-ingest all documents with the new chunk size.
  • D) Reduce the maximum query size and increase top_k in the Knowledge Base retrieve API call to compensate for smaller chunks.
  • E) Use the Bedrock Knowledge Base UpdateDataSource API to change the chunking strategy, but no re-sync is needed since the existing embeddings remain valid.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Bedrock Knowledge Bases supports changing the chunking configuration (e.g., fixed chunk size, overlap, or semantic chunking) through the data source settings. A re-sync (StartIngestionJob) reprocesses only the documents affected by the change, replacing the existing chunks. This is a managed operation, no custom code required.

Distractor Analysis

  • A is Incorrect: Pre-chunking with Lambda and re-uploading to S3 bypasses the Bedrock chunking pipeline and requires custom code. It duplicates ingestion functionality and is operationally heavier than using the built-in setting.
  • C is Incorrect: Deleting the OpenSearch collection and rebuilding from scratch is only needed when changing embedding models or vector dimensions, not for chunking parameter changes. It is unnecessary and expensive.
  • D is Incorrect: Reducing query size or increasing top_k does not fix the underlying chunk fragmentation problem. If chunks are too small, you will still retrieve incomplete instructions.
  • E is Incorrect: After changing chunking parameters, a re-sync ingestion job is required to reprocess documents. Existing embeddings are based on the old chunking strategy and will not automatically update.

Key Takeaway: Chunking strategy changes in Bedrock Knowledge Bases only require a data source update and re-sync, not a full collection rebuild. But remember to trigger the ingestion job; the index does not update automatically.

Question 9 - Bedrock Knowledge Bases Agent Tool Integration

A logistics company has deployed an Amazon Bedrock Agent (AgentCore) for shipment tracking. The agent currently uses a Knowledge Base for FAQs, but it also needs to query a live shipment status API (RESTful endpoint) to answer "Where is my package?" questions. The API requires OAuth 2.0 authentication and returns JSON data. The team must add this capability with graph-based tool chaining and least operational overhead.

Which approach is correct? (Select ONE)

  • A) Create an AWS Lambda function that calls the shipment API and expose it to the Bedrock Agent as a custom tool using an API Gateway with OpenAPI schema and Lambda integration.
  • B) Ingest shipment status data directly into the Bedrock Knowledge Base by crawling the API using the S3 data source connector with OAuth authentication.
  • C) Import the shipment API as a tool into the Bedrock Agent using the Bedrock AgentCore's native API tool integration that supports OpenAPI schemas and OAuth 2.0 authentication.
  • D) Create a new OpenSearch Serverless vector collection to store API responses and use a semantic search query to get the current shipment status.
  • E) Configure a SageMaker endpoint with a model that uses the API and then call it from the Bedrock Agent.
Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

  • C is Correct: Amazon Bedrock AgentCore supports API tool integration natively. You can provide an OpenAPI 3.0 schema and authentication details (including OAuth 2.0), and the agent will directly call the external API as a tool. This is the minimal overhead approach and is a built-in feature.

Distractor Analysis

  • A is Incorrect: While Lambda + API Gateway can expose a tool, building an OpenAPI wrapper and Lambda integration adds more moving parts than using AgentCore's native API tool ingestion. The native integration handles schema import and auth out of the box.
  • B is Incorrect: Crawling a live API into a knowledge base is architecturally wrong. The Knowledge Base is for static documents, not dynamic transactional data. There is no S3 connector that can crawl an HTTPS API.
  • D is Incorrect: Storing API responses in OpenSearch loses real-time status and relies on stale embeddings. Shipment status is transactional and changes frequently; it should be queried live, not retrieved from a vector store.
  • E is Incorrect: Creating a SageMaker endpoint to wrap the API call adds a model inference layer that is unnecessary. The agent can directly call the tool without an intermediary model.

Key Takeaway: Use Bedrock AgentCore's native tool integrations to expose REST APIs to an agent with minimal code (OpenAPI schema + auth mapping). Do not treat dynamic API responses as static knowledge base documents.

Question 10 - Agentic Memory Configuration for Multi-Session Privacy

A hospital is deploying an Amazon Bedrock Agent for telehealth triage. The agent must maintain:

  1. Conversation history within a single session (short-term memory).
  2. Persist patient preferences across sessions (e.g., preferred pharmacy) (long-term memory).
  3. Ensure that one patient cannot see another patient's memory or conversation history (strict session and namespace isolation).
  4. Memory retention must be compliant with HIPAA and minimize operational overhead.

Which two configurations satisfy the requirements? (Select TWO)

  • A) Enable Bedrock AgentCore Memory and configure a long-term memory store scoped to each patient by using unique actor IDs (e.g., /patients/{patientId}/) in the memory namespace.
  • B) Enable session isolation in Bedrock AgentCore runtime so each sessionId has an isolated execution environment, preventing cross-session access to short-term memory.
  • C) Store all patient conversation histories in a single DynamoDB table keyed by patient ID, with Lambda functions for memory read/write and manual namespace isolation.
  • D) Use SageMaker Feature Store to persist patient preferences and share them across sessions by using a feature group with patient ID as the record identifier.
  • E) Disable long-term memory and instead store the entire conversation in a single S3 bucket with SSE-KMS encryption for retrieval from the agent.
Click to reveal Answer & Explanation

Correct Answer: A and B

Correct Options Analysis

  • A is Correct: Bedrock AgentCore Memory supports long-term memory with namespaces scoped to an actor or user ID. Using separate namespaces per patient (e.g., /patients/{patientId}/) ensures preferences persist across sessions while isolating memory per patient.
  • B is Correct: AgentCore runtime automatically isolates execution environments per session ID, ensuring short-term conversation state is not accessible across sessions. This is the native way to guarantee session-level isolation.

Distractor Analysis

  • C is Incorrect: Building custom memory management in DynamoDB with Lambda functions is operationally heavy, requires manually implementing session isolation logic, and is not a native agentic feature. It violates minimal operational overhead.
  • D is Incorrect: SageMaker Feature Store is designed for ML feature pipelines and training/inference data, not for agentic conversational memory or cross-session user preferences. It does not provide the runtime memory primitives needed for agent state.
  • E is Incorrect: Storing entire conversation history in S3 as flat files is not a scalable or real-time agent memory solution. It does not support efficient retrieval by session or user, and does not integrate with AgentCore's memory management.

Key Takeaway: For agentic memory, enable native AgentCore Memory: use sessionId for short-term conversation state and actor-scoped namespaces for persistent long-term memory. Achieving the same with DynamoDB/S3 custom code adds unnecessary overhead and security complexity.