FM Application Design — AIF-C01 Study Guide

Selecting a pre-trained model: the criteria that matter

Designing an FM application starts before you write a prompt: it starts by picking the right model from a catalog, because every later decision (cost, latency, what you can even fit in a request) is downstream of that one choice. The instinct the exam keeps punishing is "reach for the biggest, most capable model"; the skill it rewards is reading a use case and matching it to the model whose cost, modality, latency, and context window actually fit. Amazon Bedrock^[1] exposes many foundation models^[2] (Amazon Nova and Titan, Anthropic Claude, Meta Llama, Mistral, Cohere, AI21, Stability AI) behind a single API, so you compare candidates without re-architecting or managing servers. The selection criteria the AIF-C01 blueprint calls out map to concrete questions you must answer for your use case:

Cost. Bedrock on-demand pricing scales with the number of input tokens plus output tokens processed, so a longer prompt or a more verbose answer costs more, and a larger model costs more per token than a smaller one. Check the current rate card on Amazon Bedrock pricing^[3]. The exam-correct instinct is that bigger is not automatically better: a smaller or distilled model is the right answer when unit cost and speed dominate a narrow task.
Modality. Match the model to the input and output the task needs: text-only, image generation (diffusion-family models such as Stability AI), or multimodal models that accept an image plus text and return text. A text-only model cannot serve an image use case no matter how capable it is.
Latency. Larger, higher-capability models respond more slowly. Interactive, real-time experiences (chat, autocomplete) push you toward a smaller, faster model; an offline batch summarization job can tolerate a slower, stronger one.
Multi-lingual support. If the application must understand or generate non-English languages, confirm the candidate model is trained for them; not all models cover the same language set.
Model size and complexity. Capability generally rises with size, but so do cost and latency: this is the central trade-off, not a free lunch.
Input/output length and context window. The context window is a hard ceiling: the prompt and the generated completion share one finite token budget. A model whose window is too small will truncate a long document regardless of how capable it otherwise is, which is the design reason RAG (introduced in RAG: grounding the model on your data below) retrieves only relevant chunks rather than pasting whole corpora.
Customization path. Decide up front whether the use case will be served by prompting alone, by RAG, or by fine-tuning a custom model^[4]: not every model supports fine-tuning, so this can rule candidates in or out.
Prompt caching. For workloads that resend a large, stable context (a long system prompt, a fixed document) across many requests, prompt caching^[5] lets Bedrock reuse the cached portion so you are not billed full price to reprocess the same tokens every call: a direct cost and latency lever on supported models.
Responsibility and compliance. Provider, licensing, content-safety behavior, and regulatory fit are selection criteria too; a model that cannot meet a compliance constraint is disqualified whatever its benchmark scores.

Inference parameters: tuning randomness and length

Once a model is chosen, inference parameters^[6] shape how it generates, at request time, without retraining and without changing a single model weight. They fall into two groups: parameters that govern randomness, and a parameter that caps length. The figure groups them that way: the randomness controls (temperature, top-p, top-k) in one box, the length cap in the other. A critical exam point: none of these add knowledge or fix a wrong answer; they only control sampling and size.

Randomness controls. A model produces a probability distribution over the next token; these parameters decide how that distribution is sampled.

Temperature flattens or sharpens the distribution. A low temperature near 0 makes the model favor its single most-likely token, producing focused, repeatable, effectively deterministic output, the right setting for extraction, classification, or any task that needs the same answer every time. A high temperature widens the distribution and yields more varied, creative output, suited to brainstorming or diverse phrasings. (Even at temperature 0, output is not guaranteed byte-identical, but it is as deterministic as the model gets.)
Top-p (nucleus sampling) restricts sampling to the smallest set of tokens whose cumulative probability reaches p. Lowering top-p shrinks the candidate pool to only the most probable tokens, reducing variability.
Top-k restricts sampling to the k most-likely tokens. Lowering k narrows the pool the same way.

Temperature, top-p, and top-k are complementary levers on the same goal: narrow them together for consistency, loosen them together for creativity.

Length control.

The maximum-token / response-length parameter caps how long the completion can be. This directly bounds both latency and cost (you pay per output token), but it does not improve answer quality. It only limits output size, and setting it too low truncates a legitimately long answer mid-sentence.

The exam pattern is clean: "needs a single consistent, reproducible answer" → lower temperature (and top-p/top-k); "needs creative or varied output" → raise them; "control cost or cut off run-on answers" → set the max-token limit; "answer is factually wrong / out of date" → none of these parameters help, because that is a grounding problem solved by RAG or fine-tuning, not a sampling setting.

Inference parameters fall into two groups: randomness controls (temperature, top-p, top-k) and length control (the maximum-token limit).

RAG: grounding the model on your data with embeddings

Retrieval Augmented Generation (RAG)^[7] is the design pattern for making an FM answer from your private, current data instead of only its frozen training knowledge, without retraining or fine-tuning. Because you update the data store rather than the model weights, RAG is how you serve information that changes often (policies, catalogs, ticket histories) and how you cut hallucination by grounding answers in retrievable source text.

The pipeline, end to end (the figure below models the AWS RAG architecture diagram on that What is RAG page):

Chunk. Source documents are split into passages small enough to retrieve precisely and fit the context window.
Embed. Each chunk is converted by an embedding model into a vector: a fixed-length list of numbers that places semantically similar text near each other in vector space.
Store. Those vectors land in a vector store that supports similarity (nearest-neighbour) search.
Retrieve. At query time the user's question is embedded with the same model, and the most semantically similar chunks are pulled from the store.
Augment & generate. The retrieved chunks are inserted into the prompt as grounding context, and the FM answers from them, ideally citing the source passages.

This is why RAG retrieves only the relevant chunks rather than stuffing an entire corpus into a maximal context window: it is cheaper, lower-latency, and keeps the model focused. Amazon Bedrock Knowledge Bases^[8] is the managed AWS service that implements this whole pipeline (ingestion, chunking, embedding, storage, and retrieval) so you do not build and operate it yourself; you point it at a data source and a vector store and it handles the rest.

Business framing for the exam: RAG fits when answers must come from private or frequently changing documents, when you want citations to source text, and when fine-tuning would be too slow or too costly to keep current. It does not fit when the goal is to teach the model a durable style, format, or domain behavior. That is fine-tuning's job, because RAG injects changing facts at query time, it does not change how the model behaves.

The five ordered RAG stages: chunk, embed, and store at ingestion, then at query time retrieve the most similar chunks and augment the prompt so the FM answers from them.

AWS vector stores for RAG embeddings, and when each fits

RAG needs somewhere to store and similarity-search the embeddings, and a recurring AIF-C01 objective is identifying which AWS services can hold vectors in a vector database. AWS deliberately supports vectors across several managed services so you can keep embeddings next to data you already run, and Amazon Bedrock Knowledge Bases^[8] can use these as its underlying vector store^[9]. The selection logic is "keep vectors near the data and skills you already have":

Amazon OpenSearch Service^[10] (including OpenSearch Serverless) provides a k-NN vector engine and is the common default for a new, purpose-built RAG workload. Choose it when you do not already have a database the vectors must live in and you want a search-native store.
Amazon Aurora PostgreSQL-Compatible Edition^[11] supports vectors via the pgvector extension. Choose it when relational operational data already lives in PostgreSQL and you want embeddings and business data in one database instead of standing up a separate store. (Plain Amazon RDS for PostgreSQL also has the pgvector extension as a database, but Aurora PostgreSQL is the PostgreSQL store Bedrock Knowledge Bases lets you select.)
Amazon Neptune Analytics^[12] adds vector search to graph data (GraphRAG). Choose it when your knowledge is already a graph (relationships between entities) and you want similarity search over it.
Third-party and serverless stores. Knowledge Bases also supports the cost-effective Amazon S3 Vectors store and the third-party stores Pinecone, Redis Enterprise Cloud, and MongoDB Atlas; pick these when you already operate one of them or want S3-priced vector storage.
Amazon Kendra^[13] is a managed intelligent-search service that can act as the retriever for RAG without you managing a raw vector index at all. Connect a Kendra index when you want managed enterprise search as the retrieval layer rather than operating your own vector engine.

The exam tests the mapping, not deep internals: "already run Aurora PostgreSQL, want vectors alongside" → Aurora PostgreSQL with pgvector; "graph data" → Neptune Analytics; "new RAG project, no existing DB" → OpenSearch Serverless; "want managed search as the retriever" → Kendra.

Agents for multi-step tasks. The store above answers where retrieved facts live; the next design building block answers what an FM can do beyond a single answer. A single FM call returns text for one prompt; an agent turns that into autonomous multi-step work: the model plans a sequence of actions, calls external tools or APIs, queries knowledge bases, and reasons over intermediate results before answering. Amazon Bedrock Agents^[14] is the managed capability for this: it connects an FM to action groups^[15] backed by AWS Lambda functions or APIs and to Knowledge Bases, so the agent can both retrieve grounding data and take real actions, for example, look up an order and then issue a refund. Reserve agentic AI for genuinely multi-step or tool-dependent requests; a single lookup or one generation does not need an agent's planning overhead. The Model Context Protocol (MCP) is an emerging open standard for connecting models to external tools and data sources in this same agentic pattern.

Cost trade-offs across customization approaches

A core Task 3.1 objective is explaining the cost trade-offs of the different ways to customize an FM. The four approaches form a ladder from cheapest/lowest-effort to most expensive/highest-effort (modeled below on the AWS custom-model^[4] customization guidance), and the design skill is picking the lowest rung that meets the requirement:

In-context learning / prompt engineering changes only the prompt. Model weights are untouched, no extra infrastructure, lowest cost and effort. It is the first thing to try for formatting, tone, and simple steering. Its limit: the model still knows only its training data plus whatever you type into each prompt.
Retrieval Augmented Generation (RAG) adds retrieved external context to the prompt; weights are still untouched. Moderate cost and effort: you need an embedding step and a vector store such as Bedrock Knowledge Bases^[8]. It is the strongest lever for grounding answers in private, large, or frequently changing knowledge and for reducing hallucination, and it stays current because you update the data store, not the weights.
Fine-tuning updates the model's weights on your curated, labeled examples to teach durable style, format, or domain behavior. Highest cost and effort short of pre-training: it needs quality labeled data and a custom-model training run^[4], and the result is frozen at training time. It goes stale until you retrain. Fine-tuning adapts behavior; it does not supply live facts.
Pre-training builds a foundation model from scratch on a vast corpus. This is the most expensive option by far and is essentially never the AI-practitioner answer: the whole point of an FM is to reuse an expensive pre-trained base rather than fund another one.

The decisive distinction the exam leans on: RAG vs fine-tuning. Need live, changing, or private facts with citations? → RAG (update data, not weights). Need the model to internalize a fixed behavior, style, or format that rarely changes? → fine-tuning. Need it both grounded and behaving a certain way? → they are complementary, not mutually exclusive.

Customization cost/effort ladder: prompt engineering (lowest), then RAG, fine-tuning, and pre-training from scratch (most expensive). Pick the lowest rung that meets the need.

Exam-pattern recognition: design-decision stems

Task 3.1 questions are almost always disguised design decisions. Read the requirement keyword in the stem and let it select the answer; the distractors are usually right tools for the wrong requirement.

RAG vs fine-tuning vs prompting.

Stem says private / internal / frequently changing data, must cite sources, reduce hallucination, no retraining → RAG (Amazon Bedrock Knowledge Bases). Update the vector store, not the weights.
Stem says teach a durable style, tone, format, or domain behavior; specialized vocabulary; consistent persona → fine-tuning (a custom model).
Stem says quick formatting, tone steering, a one-off task, cheapest option, no infrastructure → prompt engineering / in-context learning.
Stem says build a model from scratch → almost never correct for an AI practitioner; pre-training is the most costly path and contradicts reusing an FM.

Vector-store selection. (These are the stores Bedrock Knowledge Bases lets you select.)

"already use Amazon Aurora PostgreSQL, want embeddings in the same database" → pgvector on Aurora PostgreSQL.
"new RAG workload, no existing database, want a search-native vector engine" → Amazon OpenSearch Serverless (OpenSearch Service managed clusters are also supported).
"graph data / relationships" → Amazon Neptune Analytics. "MongoDB / document-style data, already on MongoDB Atlas" → MongoDB Atlas. "managed enterprise search as the retriever" → Amazon Kendra. "lowest-cost serverless vector storage" → Amazon S3 Vectors.

Inference-parameter tuning.

"output must be consistent / reproducible / focused / the same every time" → lower temperature (and lower top-p / top-k).
"more creative / varied / diverse output" → raise temperature (and top-p / top-k).
"control cost or limit response length / stop run-on answers" → set the maximum-token (response-length) parameter, and remember it does not improve quality.
"answer is factually wrong or out of date" → a trap if an option says "change temperature"; the fix is RAG or fine-tuning, because parameters tune sampling, not knowledge.

Multi-step / agent stems.

"plan several dependent steps, call external APIs or tools, then act (look up then update/refund)" → Amazon Bedrock Agents (agentic AI; action groups + Knowledge Bases; MCP for tool connectivity).
"one prompt-and-response or a single lookup is enough" → an agent is over-engineering; a plain FM call (or RAG) is the right, cheaper answer.

Model-selection stems. Watch for the "largest / most capable model for everything" distractor: the correct answer weighs cost, latency, modality, context window, and customization against the task, and a smaller or distilled model is often right when speed and unit cost dominate. "Long document keeps getting truncated" → the context window is too small (or use RAG to retrieve only relevant chunks). "Same large fixed context resent on every call, cut cost/latency" → prompt caching.

FM customization approaches: prompt engineering vs. RAG vs. fine-tuning

Aspect	Prompt engineering / in-context learning	Retrieval Augmented Generation (RAG)	Fine-tuning
What it changes	Only the prompt; model weights untouched	Adds retrieved external context to the prompt; weights untouched	Updates the model's weights on your examples
Data freshness	Limited to what you type into each prompt	Always current: answers from the live vector store you keep updated	Frozen at training time; stale until you retrain
Cost / effort	Lowest; no extra infrastructure	Moderate; needs embeddings + a vector store (e.g. Bedrock Knowledge Bases)	Highest; needs curated labeled data and a training run
Reduces hallucination	Somewhat, via better instructions	Strongly, by grounding answers in retrieved source data	Indirectly, by adapting behavior: does not supply live facts
Best for	Quick tasks, formatting, and steering tone	Answering from private, large, or frequently changing knowledge	Teaching durable style, format, or domain behavior

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Bedrock exposes many FMs behind one API

Amazon Bedrock is a fully managed, serverless service that serves foundation models from many providers (Amazon Nova and Titan, Anthropic Claude, Meta Llama, Mistral, Cohere, AI21, Stability AI, and others) through a single API. Because there are no servers to run and the API is shared, you can compare candidate models and swap one for another without re-architecting the application. The provider roster changes often, so name a representative subset rather than treating any list as exhaustive.

Bigger model is not automatically the right model

Model selection weighs cost, latency, modality, context window, customization path, language coverage, and compliance against the specific task, not raw capability alone. A smaller or distilled model is the correct answer when unit cost and speed dominate a narrow, well-scoped task, and a larger model only earns its keep when the task genuinely needs the extra capability.

Trap Reaching for the largest or most capable model for every workload, when a cheaper, faster small model meets a narrow task at lower cost.

5 questions test this

Bedrock cost scales with input plus output tokens

Bedrock on-demand pricing is token-based, charged per token processed with separate rates for input (prompt) tokens and output (completion) tokens. A longer prompt or a more verbose answer therefore costs more, and a larger model costs more per token than a smaller one, making prompt length, response length, and model choice all direct cost levers. Use the Bedrock pricing page as the only authoritative source for actual per-token figures.

Trap Assuming only output tokens are billed, when input (prompt) tokens are charged too, so a long fixed context drives cost even with short answers.

2 questions test this

Match the model's modality to the task

Model selection must match input and output modality: text-only, image generation (diffusion-family models such as Stability AI), or multimodal models that accept image plus text and return text. A text-only model cannot serve an image use case no matter how capable it otherwise is, so modality is a hard filter applied before any quality comparison.

Trap Picking a model on benchmark quality first and modality second, when a text-only model can never serve an image task however capable it is.

1 question tests this

A marketing team wants to use Amazon Bedrock to generate original product images from text descriptions for an advertising campaign. Which…

Larger models trade capability for higher latency

Larger, higher-capability models generally respond more slowly, so latency is a first-class selection criterion. Interactive, real-time experiences such as chat or autocomplete push toward a smaller, faster model, whereas an offline batch summarization job can tolerate a slower, stronger one without hurting the user.

Trap Choosing the strongest model for a real-time chat or autocomplete feature, when its higher latency degrades the interactive experience a smaller model would keep fast.

1 question tests this

A retail company is building a real-time customer service chatbot on Amazon Bedrock. The chatbot must return responses to users as quickly…

Context window is a hard shared token ceiling

The context window is a finite token budget that the prompt and the generated completion must share, a hard ceiling, not a soft guideline. A model whose window is too small truncates a long document regardless of its capability, so a recurring symptom of "the long document keeps getting cut off" points to an undersized context window, or to using RAG to retrieve only the relevant chunks instead of stuffing the whole document in.

Trap Treating the context window as covering only the input prompt, when the generated completion shares the same token budget, so a long answer can exhaust it too.

4 questions test this

Confirm multi-lingual support per model

Language coverage is an explicit selection criterion because models do not all support the same languages. An application that must understand or generate non-English text needs a model trained on those languages, which can rule a candidate in or out before cost or latency even enter the decision.

Trap Assuming any capable FM handles every language, when language coverage varies per model and an unsupported language rules a candidate out before cost or latency matter.

1 question tests this

A global software company wants to deploy a generative AI assistant on Amazon Bedrock that can understand and respond to employees in…

Not every model supports fine-tuning customization

The intended customization path (prompting, RAG, or fine-tuning) is itself a model-selection criterion, because not every Bedrock model can be fine-tuned. Deciding the customization approach up front can disqualify candidate models that support only prompting and retrieval, so settle the approach before settling the model.

Trap Selecting a model on capability and assuming you can fine-tune it later, when not every Bedrock model supports fine-tuning and the choice can lock you out.

Prompt caching reuses a large stable context

Prompt caching lets Bedrock cache a static prefix of the prompt (a long system prompt or a fixed document resent across many queries) and skip recomputing it on later calls, so cached-read tokens bill at a reduced rate and latency drops. It is the cost-and-latency lever when the same large, unchanging context is resent on every request; the cached prefix must stay byte-identical between calls or the cache misses.

Trap Expecting prompt caching to help when the reused context changes between calls, since the cached prefix must stay byte-identical or every request misses the cache.

Inference parameters tune sampling, not knowledge

Inference parameters shape how a model samples and how long it generates at request time, without retraining or changing any weight. They add no knowledge and cannot fix a wrong answer: a factually wrong or out-of-date response is a grounding problem solved by RAG or fine-tuning, never by nudging temperature. Treat these parameters as controls over randomness and length only.

Trap Raising or lowering temperature to fix a factually wrong answer, when sampling parameters change variability and length but never the model's knowledge.

1 question tests this

A financial services company is using Amazon Bedrock to generate standardized regulatory compliance reports. The reports must follow…

Lower temperature gives focused deterministic output

Temperature reshapes the next-token probability distribution: a low value near 0 steepens it so the model favors its highest-probability tokens, giving focused, repeatable, more-deterministic output, the right setting for extraction, classification, or any task needing a consistent answer. A high temperature flattens the distribution toward lower-probability tokens for more varied, creative output.

Trap Raising temperature to make output more accurate or consistent, when higher temperature increases randomness and a low value is what gives focused, repeatable answers.

13 questions test this

Top-p (nucleus) caps cumulative probability mass

Top-p, or nucleus sampling, restricts sampling to the smallest set of most-likely tokens whose cumulative probability reaches p: for p = 0.8, only the top 80% of the probability mass. Lowering top-p removes lower-probability tokens and shrinks the candidate pool, reducing output variability in the same direction as a lower temperature.

Trap Reading top-p as a fixed count of tokens, when it bounds cumulative probability mass so the candidate pool size varies with the distribution's shape.

Top-k limits sampling to the k likeliest tokens

Top-k restricts sampling to the k most-likely next tokens: set k = 50 and the model only considers the 50 most probable candidates. Lowering k narrows the pool and reduces variability, the same direction as lowering temperature or top-p; the three are complementary randomness levers, narrowed together for consistency and loosened together for creativity.

Trap Confusing top-k with top-p, when top-k caps a fixed count of tokens while top-p caps a cumulative probability share.

Max-tokens caps length but not quality

The maximum-response-length parameter caps how many tokens the completion can contain, directly bounding both latency and output cost since you pay per output token. It does not improve answer quality, and setting it too low truncates a legitimately long answer mid-sentence. Use it to control cost or stop run-on responses, not to make answers better.

Trap Raising max-tokens expecting a higher-quality answer, when the parameter only bounds response length and cost, not correctness.

RAG grounds an FM on private current data

Retrieval Augmented Generation feeds an FM relevant information from your own data sources at query time, improving the relevance and accuracy of answers without retraining or fine-tuning. Because you update the data store rather than the model weights, RAG serves frequently changing or private information and reduces hallucination by grounding each answer in retrievable source text. Managed implementations also return citations so accuracy can be checked.

Trap Assuming RAG retrains or updates the model's weights with your data, when it leaves the weights untouched and injects retrieved text into the prompt at query time.

17 questions test this

RAG pipeline: chunk, embed, store, retrieve, augment

The RAG pipeline runs end to end: chunk source documents into passages, embed each chunk into a vector with an embedding model, and store the vectors in a vector store; then at query time embed the user question with the same model, retrieve the most similar chunks, and augment the prompt with them so the FM generates a grounded answer. Retrieving only the relevant chunks rather than stuffing the whole corpus is what keeps RAG cheaper and lower-latency than enlarging the prompt.

Trap Augmenting the prompt with the whole corpus instead of the retrieved chunks, which erases the cost and latency advantage RAG gets from retrieving only relevant passages.

2 questions test this

Embeddings place similar text near each other

An embedding is a fixed-length numeric vector produced by an embedding model that places semantically similar text close together in vector space. Retrieval then runs nearest-neighbour similarity search over those vectors (performed by the vector store, not the embedding model) and the query must be embedded with the same model used for the stored chunks, or the distances are meaningless.

Trap Embedding stored documents and live queries with two different embedding models, which puts them in incomparable vector spaces and breaks retrieval.

3 questions test this

Bedrock Knowledge Bases is managed RAG

Amazon Bedrock Knowledge Bases is the managed AWS service that implements the whole RAG pipeline (ingestion, chunking, embedding, storage, and retrieval) so you do not build and operate it yourself; you point it at a data source and a vector store and it handles the rest, returning citations with each answer. It is the answer for "ground an FM on our documents without building RAG infrastructure," and a knowledge base can also be attached to a Bedrock agent.

Trap Standing up your own chunking, embedding, and vector-retrieval pipeline when Bedrock Knowledge Bases delivers the same managed RAG without building the infrastructure.

20 questions test this

Vector store options across AWS managed services

Bedrock Knowledge Bases lets you select from several vector stores: Amazon OpenSearch Serverless and OpenSearch Service managed clusters, Amazon Aurora PostgreSQL via the pgvector extension, Amazon Neptune Analytics for graph data (GraphRAG), the cost-effective Amazon S3 Vectors store, and the third-party stores Pinecone, Redis Enterprise Cloud, and MongoDB Atlas; you can also connect an Amazon Kendra index for managed retrieval instead of a raw vector store. The exam tests mapping a scenario to the right store, not deep internals.

Trap Selecting plain Amazon RDS for PostgreSQL or DocumentDB as a Knowledge Bases vector store. They hold vectors as databases but are not selectable stores; only Aurora PostgreSQL is.

4 questions test this

OpenSearch is the default new-RAG vector engine

Amazon OpenSearch Service, including OpenSearch Serverless, provides a k-NN vector engine and is the common default for a new, purpose-built RAG workload. Choose it when no existing database has to hold the vectors and you want a search-native store. The Bedrock console can even create an OpenSearch Serverless store for you automatically.

Trap Reaching for OpenSearch when relational data already lives in PostgreSQL, where co-locating embeddings via Aurora pgvector fits better than a separate search-native store.

5 questions test this

pgvector keeps embeddings beside PostgreSQL data

Amazon Aurora PostgreSQL-Compatible Edition supports embeddings through the pgvector extension and is the PostgreSQL store you select for a Bedrock Knowledge Base. Choose it when relational operational data already lives in PostgreSQL and you want embeddings and business data in one database rather than a separate vector store. Note that plain RDS for PostgreSQL supports pgvector as a database but is not a selectable Knowledge Bases store, only Aurora is.

Trap Selecting RDS for PostgreSQL as the Knowledge Bases pgvector store, when only Aurora PostgreSQL is a selectable store despite RDS also supporting the extension.

2 questions test this

Neptune for vectors over graph data

Amazon Neptune Analytics adds vector similarity search to graph data, the basis of GraphRAG in Bedrock Knowledge Bases. Choose it when your knowledge is already a graph of relationships between entities and you want similarity search over that graph rather than standing up a separate vector engine.

Trap Standing up a separate vector engine when the knowledge is already a graph of entity relationships that Neptune Analytics can search in place via GraphRAG.

2 questions test this

Kendra is managed retrieval without a raw vector index

Amazon Kendra is a managed intelligent enterprise-search service that can act as the retriever for RAG without you operating a raw vector index at all. Choose it when you want managed enterprise search as the retrieval layer instead of provisioning and tuning your own vector engine.

Trap Provisioning and tuning a raw vector engine for enterprise search when Kendra acts as a managed RAG retriever without one.

1 question tests this

A consulting firm wants to implement a RAG solution for their knowledge management system. They are evaluating whether to use Amazon Kendra…

Customization ladder from cheapest to most expensive

The FM customization approaches form a cost/effort ladder: prompt engineering and in-context learning (cheapest, weights untouched), then RAG (moderate, needs embeddings and a vector store), then fine-tuning (high, needs labeled data and a training run), then pre-training from scratch (most expensive by far). The design skill is choosing the lowest rung that meets the requirement rather than reaching past it.

Trap Climbing straight to fine-tuning when prompt engineering or RAG, the cheaper lower rungs, already meet the requirement without touching weights.

4 questions test this

Pre-training from scratch is almost never the answer

Pre-training builds a foundation model from scratch on a vast corpus and is by far the most expensive option, in data, compute, and time. It is essentially never the AI-practitioner answer, because the whole point of using an FM is to reuse an expensive pre-trained base rather than fund another one, so "train a model from scratch" in a stem is almost always a distractor.

Trap Choosing pre-training a model from scratch when prompting, RAG, or fine-tuning would meet the requirement at a fraction of the cost.

3 questions test this

RAG vs fine-tuning: facts versus behavior

RAG supplies live, changing, or private facts with citations by updating the data store, not the weights; fine-tuning teaches a durable style, format, persona, or domain behavior by updating the weights, and goes stale until retrained. RAG injects facts at query time without changing behavior; fine-tuning changes behavior without supplying live facts. They are complementary, and many real designs use both rather than choosing one.

Trap Fine-tuning a model to inject frequently changing facts, when RAG updates a data store without a retraining run and keeps answers current.

6 questions test this

Bedrock Agents perform multi-step tool-using tasks

An agent turns a single FM response into autonomous multi-step work: the model breaks a request into steps, calls external APIs or tools, queries knowledge bases, and reasons over intermediate results before answering. Amazon Bedrock Agents is the managed capability that connects an FM to action groups (backed by AWS Lambda functions or APIs) and to Knowledge Bases, so one agent can both retrieve grounding data and take real actions, for example, look up an order and then issue a refund.

Trap Reaching for RAG when the task also has to take real actions like issuing a refund, since RAG only retrieves grounding data while a Bedrock agent calls tools too.

13 questions test this

Reserve agents for genuinely multi-step work

An agent's planning and orchestration overhead is over-engineering for a single prompt-and-response or a one-shot lookup; reserve it for genuinely multi-step or tool-dependent requests. When one generation answers the question, a plain FM call is correct; when one retrieval answers it, RAG is the cheaper correct answer.

Trap Wrapping a single prompt-and-response in a Bedrock agent, adding planning overhead and cost where one plain FM call would do.

11 questions test this

MCP is the open standard for tool connectivity

The Model Context Protocol (MCP) is an open standard for connecting AI models and applications to external tools, data sources, and workflows, the standardized integration layer for the agentic pattern. The AIF-C01 blueprint lists it under the role of agents in multi-step tasks, alongside Amazon Bedrock Agents and agentic AI.

Prompt routing directs requests to the right model

Amazon Bedrock intelligent prompt routing exposes one serverless endpoint that routes each request to a different model within the same model family, predicting per-request which model gives the best response and routing accordingly to balance quality and cost: a cheaper, faster model for simple prompts, a stronger one for hard prompts. It chooses among models in one family (for example Claude Haiku versus Claude Sonnet), not across unrelated providers.

Trap Expecting prompt routing to pick across unrelated providers, when it routes only among models within one family such as Claude Haiku versus Claude Sonnet.

3 questions test this

Knowledge Bases metadata filtering narrows retrieval

In Amazon Bedrock Knowledge Bases you can attach metadata (such as product version, document type, business unit, or project ID) to documents and apply matching filters at query time, so retrieval returns a well-defined subset of the semantically relevant chunks instead of everything that merely matches. It pre-filters before the similarity search, improving relevance and personalizing results, for example, returning only the current software version or one team's documents.

Trap Relying on the FM to ignore stale or other teams' chunks after retrieval, when metadata filtering excludes them before the similarity search returns them at all.

5 questions test this

Selecting a pre-trained model: the criteria that matter

Inference parameters: tuning randomness and length

RAG: grounding the model on your data with embeddings

AWS vector stores for RAG embeddings, and when each fits

Cost trade-offs across customization approaches

Exam-pattern recognition: design-decision stems

FM customization approaches: prompt engineering vs. RAG vs. fine-tuning

Decision tree

Cheat sheet

References