Every AIF-C01 study resource tells you the same two sentences: RAG grounds a model in your data at inference time, and Amazon Bedrock Knowledge Bases is the managed way to do it on AWS. Both are true, and our applications of foundation models guide explains the five-step RAG loop and when to pick RAG over fine-tuning. But the exam has moved past “what is RAG”. Domain 3 (Applications of Foundation Models, 28% of the scored questions) asks you to identify the role of vector databases, to name the AWS services that can store embeddings, and to reason about design considerations such as cost, latency, and accuracy for an application that uses a foundation model. Those questions reward candidates who know what a knowledge base actually does between “upload documents” and “get a cited answer”.
This guide opens the box. It follows a document through ingestion (data source, parser, chunker, embeddings model, vector store), then follows a question back out (retrieval configuration, filters, search type, reranking, generation). Along the way it covers the pieces that have appeared in Bedrock since most study notes were written: GraphRAG on Neptune Analytics, S3 Vectors as a low-cost store, structured-data knowledge bases that generate SQL, multimodal retrieval over images, audio and video, and the new Bedrock Managed Knowledge Base that AWS now recommends by default. Everything is checked against the current Amazon Bedrock documentation. You will not need to build any of it to pass AIF-C01, but you will need to recognise each component when a scenario describes it in plain English.
Where This Sits in the AIF-C01 Blueprint
The exam guide’s Task Statement 3.1 (“Describe design considerations for applications that use foundation models”) is where almost every knowledge-base question lives. The relevant skill bullets are:
- Identify selection criteria to choose pre-trained models (cost, modality, latency, multilingual support, model size, complexity, customisation, input/output length).
- Understand the effect of inference parameters on model responses.
- Define Retrieval Augmented Generation (RAG) and describe its business applications, with Amazon Bedrock Knowledge Bases named explicitly.
- Identify AWS services that help store embeddings within vector databases: Amazon OpenSearch Service, Amazon Aurora, Amazon Neptune, Amazon DocumentDB (with MongoDB compatibility), Amazon RDS for PostgreSQL.
- Explain the cost trade-offs of foundation model customisation approaches (pre-training, fine-tuning, in-context learning, RAG).
Two things follow. First, the exam’s list of “vector database services” is a general AWS list, not the list of stores a knowledge base can plug into. Both lists matter and they overlap imperfectly, so the table later in this guide shows them side by side. Second, the exam tests design reasoning: why chunk size matters, why metadata filtering improves relevance, why you might choose a cheaper vector store for an infrequently queried archive. Memorising API names is less useful than understanding each knob’s effect.
The Two Flavours: Customer-Managed and Bedrock Managed Knowledge Bases
Amazon Bedrock now offers two kinds of knowledge base, and the documentation recommends the newer one for most workloads:
| Feature | Bedrock Managed Knowledge Base | Customer-Managed Knowledge Base |
|---|---|---|
| Vector/text data store | Auto-scaling store of embeddings, text, metadata and raw files, fully managed by Bedrock | You choose, provision, scale and pay for the vector store |
| Embeddings model | Built-in managed model at no extra cost; optionally bring any Bedrock embeddings model (float32, 1,024 dimensions) | You choose any supported Bedrock embeddings model |
| Reranking | Built-in managed semantic reranker at no extra cost; optional Bedrock reranker models | Optional Bedrock reranker models |
| Search | Agentic retrieval plus semantic hybrid retrieval, optimised across file types | You choose the search type |
| Native connectors | S3, SharePoint, Confluence, Web Crawler, Google Drive, OneDrive, Custom | S3 and Custom (new Confluence, SharePoint, Salesforce and Web Crawler connectors stop being creatable on customer-managed knowledge bases from 30 September 2026; existing ones keep working) |
| Parsing | Built-in multimodal parser | Default (text), foundation model, or Bedrock Data Automation parser |
| Chunking | Built-in default or fixed-size | Built-in default or fixed-size, plus semantic, hierarchical, none and custom Lambda |
| Infrastructure | None to manage | You maintain the vector database and keep direct access to it |
| Best for | End-to-end managed RAG, agentic retrieval, AgentCore Gateway and Amazon Quick integration | Custom vector-database configurations and direct control over the index |
The exam framing is familiar from every other AWS service pair: when the scenario stresses least operational overhead, fastest time to value, or no infrastructure to manage, the managed flavour is the answer. When it stresses control over the vector database, reuse of an existing OpenSearch or Aurora cluster, or a specific chunking strategy, the customer-managed flavour is. Most of the mechanics in this guide are exposed in the customer-managed knowledge base, which is also where the detailed design decisions live, so that is the path the rest of the article follows.
The Ingestion Pipeline, Component by Component
A knowledge base turns files into searchable vectors in five stages. Each stage is a configuration decision with an exam-visible trade-off.
Data source ──► Parser ──► Chunker ──► Embeddings model ──► Vector store
(S3, custom, (default, (fixed, (Titan V2, (OpenSearch,
connectors) BDA, FM) semantic, Cohere, Aurora, Neptune,
hierarchical, Nova multimodal) S3 Vectors, ...)
none, Lambda)Stage 1: Data Sources
A customer-managed knowledge base reads from Amazon S3 (general-purpose buckets only, in the same Region as the knowledge base, optionally scoped by inclusion prefixes) and from a custom data source that you feed directly through the API. Connectors for Confluence, SharePoint, Salesforce and the Web Crawler exist today but, as noted above, cannot be newly created on customer-managed knowledge bases after 30 September 2026; the managed knowledge base is where AWS is investing in connectors (including Google Drive and OneDrive). Multimodal content (images, audio, video) is supported only through S3 and custom data sources; other connectors skip those files.
Syncs are incremental: each StartIngestionJob crawls content that was added, modified or deleted since the last sync, so re-indexing a large corpus after a small change is cheap. The data source carries a data deletion policy (DELETE the vectors when the data source is deleted, or RETAIN them) and an optional customer-managed KMS key for the transient data created during ingestion. One line from the documentation is worth quoting for Domain 5 questions: everything you sync becomes available to anyone with bedrock:Retrieve permission on the knowledge base, including documents that had restrictive permissions at the source. Access control for a knowledge base is an IAM problem on the retrieval API, not an inheritance of the source system’s ACLs (the managed knowledge base has an optional ACL-awareness feature for exactly this reason).
Stage 2: Parsing
Parsing is how raw files become text the chunker can split. There are three parsers:
| Parser | What it extracts | Cost | When the exam wants it |
|---|---|---|---|
| Bedrock default parser | Text only, from .txt, .md, .html, .doc/.docx, .xls/.xlsx and .pdf | Free | Text-only documents, lowest cost |
| Amazon Bedrock Data Automation (BDA) | Text plus figures, charts, tables and images from PDFs and .jpeg/.png files, with no prompting required; also transcribes audio and summarises video | Per page / per image | Documents with tables, charts or scanned pages; multimodal content; “no prompt engineering” |
| Foundation model parser | The same multimodal extraction using a foundation model, with a customisable parsing prompt | Per input/output token; total file size across the data source capped at 100 GB | You need to control how figures are described or tables are serialised |
Two gotchas appear in scenario questions. If you pick BDA or a foundation model, that parser processes every PDF in the data source, including text-only ones, so your bill rises even for plain documents. And multimodal parsers can store the extracted images and tables in an S3 destination that you name during setup, so retrieval results can return the original figure alongside the text.
Stage 3: Chunking Strategies
Chunking decides what unit of text gets embedded, searched and handed to the model. It is the single most consequential design choice, and it cannot be changed after the data source is created (you create a new data source to switch). The strategies are:
| Strategy | Parameters | Behaviour | Trade-off |
|---|---|---|---|
| Default | none | Roughly 300-token chunks that respect sentence boundaries | Sensible starting point, no tuning |
| Fixed-size | max tokens per chunk, overlap percentage | Uniform chunks; overlap preserves context across boundaries | Predictable size and cost; can split a thought mid-paragraph |
| Semantic | max tokens, buffer size, breakpoint percentile threshold | Splits where the meaning changes, measured by embedding dissimilarity between neighbouring sentences; a higher threshold yields fewer, larger chunks | Better topical coherence; extra cost because a foundation model is used during chunking |
| Hierarchical | parent max tokens, child max tokens, overlap tokens | Embeds small child chunks for precise matching, then returns the larger parent chunk to the model for context | Precision of small chunks plus context of large ones; fewer results than numberOfResults because siblings collapse into one parent; not recommended with S3 Vectors above roughly 8,000 combined tokens because of metadata size limits |
| No chunking | none | Each file is one chunk; you pre-split files yourself | Full control; you lose page-number citations and the page-number metadata filter |
| Custom transformation (Lambda) | your code, an intermediate S3 bucket | A Lambda function receives the parsed content and returns chunks and metadata of your design | Any logic you want, at the cost of writing and operating it |
The exam-relevant intuition: small chunks retrieve precisely but starve the model of context; large chunks give context but dilute the match. Hierarchical chunking is AWS’s packaged answer to that tension, semantic chunking is the answer when documents switch topics unpredictably, and fixed-size is the answer when you want predictable token costs. A newer behaviour worth knowing: when parsed content contains a table or figure, Bedrock can attach the whole page or whole table (up to 10,000 characters) as broader context and return it in place of the matching chunk, under any strategy with a token limit.
For multimodal files the text strategies do not apply. With Nova multimodal embeddings, chunking happens inside the embeddings model, and you configure an audio/video chunk duration of 1 to 30 seconds (default 5). With the BDA parser, media is first converted to transcripts and scene summaries and then chunked as text.
Stage 4: Embeddings Models and Dimensions
An embeddings model converts each chunk into a vector. The knowledge base documentation lists the dimension each model produces, and your vector index must be created with a matching dimension:
| Embeddings model | Dimensions |
|---|---|
| Amazon Titan Text Embeddings G1 | 1,536 |
| Amazon Titan Text Embeddings V2 | 1,024, 512 or 256 (you choose) |
| Cohere Embed English v3 | 1,024 |
| Cohere Embed Multilingual v3 | 1,024 |
| Amazon Nova Multimodal Embeddings | used for native image/audio/video embedding |
Three design points recur in questions. Lower dimensions mean smaller indexes and cheaper storage at some cost in nuance, which is why Titan V2 offers 256 and 512 alongside 1,024. Binary embeddings shrink storage further but are supported only by OpenSearch Serverless and OpenSearch managed clusters. And the embeddings model is fixed at knowledge base creation; because a query is embedded with the same model as the documents, switching models means re-ingesting everything.
Stage 5: Vector Stores
This is where the exam’s generic list and Bedrock’s specific list diverge, so here are both.
| Vector store | Knowledge Bases support | In the AIF-C01 “stores embeddings” list? | Notes |
|---|---|---|---|
| Amazon OpenSearch Serverless | Yes, quick-create default | Yes (as Amazon OpenSearch Service) | Supports hybrid search, binary vectors and the richest metadata filters (in, startsWith, listContains, stringContains); uses the faiss engine |
| Amazon OpenSearch Service managed cluster | Yes (bring your own domain) | Yes | Public-access domains only; version 2.13+ for k-NN, 2.16+ for binary vectors; supports binary embeddings |
| Amazon Aurora PostgreSQL (pgvector) | Yes, quick-create available | Yes (Aurora) | Hybrid search via a tsvector GIN index; custom metadata in a JSONB column; same account as the knowledge base |
| Amazon Neptune Analytics | Yes, quick-create available | Yes (Neptune) | GraphRAG: builds a graph of entities and relationships so retrieval can follow connections between chunks |
| Amazon S3 Vectors | Yes, quick-create available | Not named | Lowest-cost store for infrequent query workloads; float embeddings only; 1 KB of custom metadata and 35 keys per vector; startsWith/stringContains filters unsupported |
| Pinecone, Redis Enterprise Cloud, MongoDB Atlas | Yes (third-party, credentials in Secrets Manager) | Not named | MongoDB Atlas supports hybrid search with a text index; metadata filtering needs manual index configuration |
| Amazon DocumentDB, Amazon RDS for PostgreSQL | Not as knowledge base stores | Yes | Named in the exam guide as AWS services with vector search; you would wire them up yourself |
How to use this on exam day: if a question says “which AWS services can store vector embeddings”, any of OpenSearch Service, Aurora, Neptune, DocumentDB and RDS for PostgreSQL is a valid pick. If it says “a Bedrock knowledge base needs a vector store with the least setup”, OpenSearch Serverless quick-create is the default answer. “Lowest cost for an archive that is rarely queried” points to S3 Vectors. “Answers must follow relationships between entities across documents” points to Neptune Analytics GraphRAG. “Reuse the relational database the team already runs” points to Aurora PostgreSQL. Encryption questions are simple: the vector store’s own encryption applies, third-party stores can be encrypted with a KMS key, and S3 Vectors buckets use SSE-S3 or SSE-KMS chosen at creation.
The Query Path: Retrieve vs RetrieveAndGenerate
Once documents are indexed, an application queries a knowledge base through one of two runtime APIs (both also have streaming or agent-driven variants):
| API | Returns | Use when |
|---|---|---|
| Retrieve | The matching chunks with relevance scores, source location and metadata; no generation | You want to build your own prompt, use a model outside Bedrock, post-process results, or just power a search box |
| RetrieveAndGenerate | A generated answer with citations back to the chunks, plus an optional sessionId for multi-turn conversations | You want the fully managed RAG answer with minimal code |
The exam often phrases this as “a developer wants to use the knowledge base’s retrieval but generate the answer with a custom workflow”: that is Retrieve. “Return grounded answers with citations in one call”: that is RetrieveAndGenerate. Agents for Amazon Bedrock can also attach a knowledge base, in which case the agent decides when to query it (our Bedrock guide covers that relationship).
Number of Source Chunks
numberOfResults caps how many chunks come back, five by default. With hierarchical chunking it counts child matches, and siblings that share a parent collapse into one parent, so the response can hold fewer items than requested. More chunks give the model more evidence and cost more input tokens; fewer chunks are cheaper and sharper. This is the knob a question means when it talks about “the amount of retrieved context passed to the model”.
Search Type: Semantic, Hybrid or Default
| Search type | How it matches | Supported stores |
|---|---|---|
| Semantic | Vector similarity only | Every store |
| Hybrid | Vector similarity plus raw-text (keyword) search, combined | OpenSearch Serverless, Aurora/RDS PostgreSQL and MongoDB Atlas with a filterable text field |
| Default | Bedrock picks the strategy for your store | All |
Hybrid search is the right answer when queries contain exact identifiers (part numbers, error codes, product names) that pure embeddings blur. If the store does not support hybrid, Bedrock silently falls back to semantic search.
Metadata Filtering
Each S3 document can carry a sidecar file named document.pdf.metadata.json (same folder, up to 10 KB) with string, number, boolean or string-list attributes:
{
"metadataAttributes": {
"department": { "value": { "type": "STRING", "stringValue": "finance" }, "includeForEmbedding": true },
"fiscal_year": { "value": { "type": "NUMBER", "numberValue": 2026 }, "includeForEmbedding": false },
"is_public": { "value": { "type": "BOOLEAN", "booleanValue": false }, "includeForEmbedding": false }
}
}At query time the application applies a filter such as equals, notEquals, greaterThan, lessThan, in, notIn, startsWith, stringContains or listContains, combined with andAll / orAll groups (up to five filters per group, one level of nesting). Bedrock also writes its own attributes, including x-amz-bedrock-kb-document-page-number for PDFs (not available with no-chunking). Two newer features extend this. includeForEmbedding: true concatenates the metadata to the chunk text before embedding, so a query that mentions the department name scores higher against finance documents. And implicit metadata filtering lets an Anthropic Claude model read a schema of your attributes and generate the filter from the user’s question, so “what did finance publish in 2026?” becomes a department = finance AND fiscal_year = 2026 filter without the application writing it.
For the exam, metadata filtering is the answer to “restrict results to the latest version of a policy”, “only search documents the user’s business unit owns”, or “improve relevance when many documents are semantically similar”. It narrows the candidate set before similarity ranking, which improves both accuracy and cost.
Reranking
Vector similarity is a fast approximation of relevance. A reranker model re-scores the retrieved chunks against the query with a more expensive cross-attention model and reorders them, so the best evidence is at the top of the context window. Bedrock offers reranker models through the Rerank API and as a retrieval configuration option (Amazon Rerank and Cohere Rerank models are available), and the managed knowledge base includes a built-in reranker at no extra charge. In a scenario, reranking is what you add when “the correct passage is usually retrieved but not ranked first” or when the application retrieves many chunks and needs to trim to the most relevant few.
Query Decomposition
Enabling QUERY_DECOMPOSITION in the orchestration configuration lets Bedrock split a compound question into sub-queries, run each against the knowledge base, and compose a final answer. The documentation’s example is “Who scored higher in the 2022 FIFA World Cup, Argentina or France?”, which becomes two retrievals, one per team. It costs more retrievals and tokens, and it is the fix for “multi-part questions return incomplete answers”.
Generation Controls
RetrieveAndGenerate exposes the same levers as a direct model call: inference parameters (temperature, topP, maxTokens, stopSequences, plus model-specific fields), a custom prompt template with the placeholders $query$, $search_results$, $output_format_instructions$ (required for citations to appear) and $current_time$, and an attached Amazon Bedrock Guardrail by ID and version. The inference parameters guide explains the parameter effects; the prompt-attack security guide explains why a guardrail on a RAG endpoint matters when retrieved documents themselves can contain injected instructions.
Beyond Text: Structured and Multimodal Knowledge Bases
Two extensions change what “knowledge base” means on the exam.
Structured data stores. A knowledge base can connect to a structured data store through a query engine instead of a vector index. Bedrock converts the natural-language question into SQL (NL2SQL), runs it against the warehouse, and returns the rows or a generated answer. The GenerateQuery API exposes the SQL conversion on its own, so an application can review or log the query before running it. The scenario cue is “answer questions over tables in a data warehouse without users writing SQL”. Note that most retrieval configurations in this guide (filters, search type, reranking) apply to unstructured sources only; orchestration and generation settings apply to both.
Multimodal content. With Nova multimodal embeddings, images, audio and video are embedded natively, so you can search with an image and retrieve visually similar content, or find a moment in a video by text. With BDA processing, media is converted to text first (ASR transcripts, scene summaries, OCR) and then embedded, which is what enables RetrieveAndGenerate to write an answer about a call recording. Results carry timestamps for audio and video so an application can jump to the matching segment. The exam cue is any requirement to search across “product images, training videos and support-call recordings” alongside documents.
Cost and Security Considerations the Exam Likes
Knowledge Bases themselves carry no fee; you pay for the parts. That makes the cost questions tractable:
- Embeddings generation is charged per token at ingestion and per query. Smaller dimensions and fewer re-syncs reduce it.
- Vector store charges dominate for large corpora. OpenSearch Serverless bills for compute units; Aurora bills as a database; S3 Vectors is the low-cost option for infrequent queries.
- Parsing with BDA or a foundation model adds per-page or per-token costs, and applies to every PDF once selected.
- Semantic chunking invokes a foundation model during ingestion, so it costs more than fixed-size or default chunking.
- Generation is standard Bedrock token pricing; more source chunks and query decomposition mean more input tokens. The generative AI cost optimisation guide places these against the alternatives.
On security, the service role of the knowledge base needs read access to the data source, the embeddings model and the vector store; data in the store is encrypted by the store’s mechanism (KMS where supported); transient ingestion data can use a customer-managed key; and retrieval permission is all-or-nothing per knowledge base unless you layer metadata filtering in your application or use the managed knowledge base’s ACL awareness. These are the facts the security, compliance and governance guide expects you to connect to Domain 5.
Worked Exam Scenarios
Work through these before you check the answers.
- A legal team’s PDFs contain many tables, and answers about fee schedules are wrong because table cells are jumbled. → Switch from the default parser to Bedrock Data Automation (or a foundation model parser); the default parser extracts text only.
- Support agents search for exact error codes, but semantic search returns similar-sounding but wrong articles. → Use hybrid search, which combines keyword matching with vector similarity (requires a store such as OpenSearch Serverless or Aurora).
- An HR assistant must answer only from the current year’s policy documents even though older versions remain indexed. → Add a
yearattribute in.metadata.jsonfiles and apply a metadata filter at query time. - A chatbot retrieves the right passages, but the best one is rarely at the top so the model overlooks it. → Enable reranking.
- Users ask “compare the Q1 and Q2 refund policies” and get one-sided answers. → Enable query decomposition.
- A product team wants natural-language questions over a sales table in a data warehouse without anyone writing SQL. → A knowledge base connected to a structured data store (NL2SQL /
GenerateQuery). - A compliance archive is queried a few times a month; the vector store is the largest line item. → Move to Amazon S3 Vectors.
- Answers require connecting facts spread across documents (a supplier mentioned in one contract, its subsidiary in another). → Neptune Analytics GraphRAG.
- A startup wants RAG with no infrastructure to manage, native SharePoint and Google Drive connectors, and built-in reranking. → Bedrock Managed Knowledge Base.
- A developer needs the retrieved passages to feed a custom prompt and a non-Bedrock model. → Call Retrieve, not
RetrieveAndGenerate. - Retrieved chunks are precise but too short for the model to answer well, and larger fixed chunks ruin precision. → Hierarchical chunking.
- A knowledge base must search product photos using an uploaded image. → Nova multimodal embeddings (native image embedding), not BDA text conversion.
Common Mistakes
- Treating “RAG” and “fine-tuning” as the only decision. The exam now distinguishes within RAG: parser, chunking, store, filters. Reading the scenario for the specific failure (wrong tables, wrong ranking, stale documents, cost) tells you which knob is being tested.
- Assuming the chunking strategy can be tuned later. It is fixed per data source; you must create a new data source to change it.
- Confusing the exam’s vector-service list with Bedrock’s store list. DocumentDB and RDS for PostgreSQL are valid “AWS services that store embeddings” but are not knowledge base stores; S3 Vectors and Neptune Analytics are knowledge base stores and only Neptune is on the exam’s list.
- Expecting hybrid search everywhere. It needs a store with a filterable text field (OpenSearch Serverless, Aurora/RDS PostgreSQL, MongoDB Atlas); elsewhere Bedrock uses semantic search.
- Assuming source-system permissions carry over. Anyone with
bedrock:Retrieveon the knowledge base can retrieve any synced document; enforce access with IAM, metadata filters or the managed knowledge base’s ACL feature. - Forgetting that
Retrievedoes not generate. It is a retrieval API; the answer-with-citations behaviour belongs toRetrieveAndGenerate. - Overlooking Amazon Kendra’s role. A knowledge base can also use a Kendra GenAI index as its retriever, and Amazon Q Business uses managed RAG over enterprise connectors; the AWS AI services guide and the Amazon Q guide draw those boundaries.
How to Practise This
AIF-C01 does not require hands-on work, but thirty minutes in the console makes every term above concrete. Create a knowledge base with the quick-create OpenSearch Serverless option, upload three PDFs and a .metadata.json file to S3, sync, then use the test panel to toggle Generate responses on and off (that is RetrieveAndGenerate versus Retrieve), change the number of source chunks, add a filter, and switch the search type. Delete the collection afterwards; OpenSearch Serverless is the component that costs money while idle.
Then test recognition under time pressure. Sailor.sh’s AWS Certified AI Practitioner (AIF-C01) Mock Exam Bundle includes eight full-length, timed mock exams with 520+ scenario-style questions across all five domains, including the Domain 3 design scenarios where the distinction between a parser problem, a chunking problem and a ranking problem decides the answer. Start with the free AIF-C01 practice questions if you want a baseline first, and use the model evaluation metrics guide to connect RAG quality to the metrics the exam names.
Frequently Asked Questions
What is Amazon Bedrock Knowledge Bases in one sentence?
A managed service that ingests your documents (parsing, chunking, embedding and indexing them in a vector store) and exposes retrieval APIs so a foundation model can answer questions grounded in that data with citations.
Does AIF-C01 ask about chunking strategies?
Not by API name, but Domain 3 design-consideration questions describe symptoms (lost context, poor precision, cost) whose fixes are chunking choices. Knowing that small chunks favour precision, large chunks favour context and hierarchical chunking combines both is enough.
Which vector databases does the AIF-C01 exam guide name?
Amazon OpenSearch Service, Amazon Aurora, Amazon Neptune, Amazon DocumentDB (with MongoDB compatibility) and Amazon RDS for PostgreSQL. Bedrock Knowledge Bases additionally supports Amazon S3 Vectors, OpenSearch Serverless and managed clusters, Pinecone, Redis Enterprise Cloud and MongoDB Atlas.
What is the difference between Retrieve and RetrieveAndGenerate?
Retrieve returns matching chunks, scores and metadata with no model generation. RetrieveAndGenerate retrieves and then has a foundation model write an answer with citations, optionally across a multi-turn session.
What is hybrid search in Bedrock Knowledge Bases?
A search type that combines vector (semantic) similarity with raw-text keyword matching. It is supported on OpenSearch Serverless, Aurora/RDS PostgreSQL and MongoDB Atlas stores that have a filterable text field, and it helps when queries contain exact identifiers.
Can a knowledge base query a database instead of documents?
Yes. A knowledge base connected to a structured data store converts natural-language questions to SQL (NL2SQL) through a query engine, and the GenerateQuery API exposes that conversion directly.
Is a Bedrock Managed Knowledge Base different from a regular knowledge base?
Yes. The managed flavour runs the data store, embeddings model and reranker for you, adds agentic retrieval and more native connectors (including Google Drive and OneDrive), and requires no infrastructure management. The customer-managed flavour lets you choose and control the vector store and the full set of chunking and parsing options.
Why would I choose Amazon S3 Vectors as a knowledge base store?
Cost. S3 Vectors offers durable, elastic vector storage with sub-second queries for infrequent query workloads, without provisioning a search cluster. It supports float embeddings only and has tighter metadata limits, so it suits archives more than hot chat applications.
Conclusion
A knowledge base is a pipeline, not a checkbox. Documents are parsed (text-only or multimodal), chunked (default, fixed, semantic, hierarchical, none or custom), embedded (with a model whose dimensions the index must match) and stored (in OpenSearch, Aurora, Neptune, S3 Vectors or a third-party store). Questions are embedded with the same model, narrowed by metadata filters, matched semantically or hybridly, optionally reranked and decomposed, and finally answered by a model with citations. Every AIF-C01 scenario about RAG design is pointing at one of those stages, and once you can name the stage, the answer is usually the only option that touches it.
Keep the two higher-level maps in mind as well: the exam’s own list of embedding-capable AWS services, and the managed-versus-customer-managed split that AWS now leads with. Then let timed practice do the rest; recognising “this is a parser problem” in twelve seconds is the skill the exam actually measures.