An inference parameter controlling randomness — higher values make output more varied.
Temperature is a scaling factor applied to a model’s probability distribution over possible next tokens before sampling. Near 0, the model almost always picks the highest-probability token, producing consistent, near-deterministic output. As temperature rises, lower-probability tokens become more likely, increasing diversity at the cost of coherence. In Amazon Bedrock, temperature is set alongside Top P and Top K as inference parameters. A key exam distinction: temperature reshapes the entire probability distribution, whereas Top P caps sampling to the most probable tokens whose cumulative probability meets a threshold — the two controls are complementary, not synonymous.
A sampling setting that limits token choice to the K most likely options.
Top-K is a token-sampling parameter that restricts the model’s next-token selection to only the K highest-probability candidates. At each step, all other tokens are excluded regardless of probability, and the model samples from that truncated set. In Amazon Bedrock, Top-K is exposed as an inference parameter alongside temperature and Top-P when invoking foundation models. Unlike Top-P, which sets a dynamic probability-mass threshold, Top-K sets a fixed count. A low K (such as 1) produces near-deterministic output, while a very high K approaches unconstrained sampling. When both are used, Top-K narrows the pool first, then Top-P filters further.
Nucleus sampling — choosing from the smallest set of tokens whose probabilities sum to P.
Top-P, also called nucleus sampling, controls randomness by dynamically adjusting how many candidate tokens the model considers. Rather than fixing a count, it includes the fewest tokens whose cumulative probability reaches the threshold P, so the pool shrinks when the model is confident and grows when it is uncertain. In Amazon Bedrock, Top-P sits alongside temperature and Top-K as an inference parameter. The exam distinction: Top-K fixes the candidate count regardless of the distribution, while Top-P adapts to it, so a low value like 0.1 yields more deterministic output.
An inference parameter capping the length of the model's response.
The maxTokens inference parameter in Amazon Bedrock tells a model the maximum number of tokens it may generate in a single response. Because foundation models charge for both input and output tokens, a tight value is a direct cost control: a response capped at 200 tokens costs less than one allowed to run to 2,000. The key exam distinction is that max tokens governs output length only, while the context window governs the combined input-plus-output budget. A model can have a large context window yet still produce a short response if max tokens is low. Confusing the two leads to misdiagnosing why a response was truncated versus why a long prompt was rejected.
Retrieval-Augmented Generation — grounding model answers in relevant retrieved documents.
Retrieval-Augmented Generation (RAG) is a pattern where an application first retrieves relevant documents from an external data source, then passes those documents as context alongside the user’s query to a foundation model, letting the model generate answers grounded in current, private information rather than relying solely on its training data. Amazon Bedrock Knowledge Bases implements managed RAG, handling the full pipeline: ingesting documents into a vector store, chunking and embedding them, and performing semantic retrieval at inference time.
The key exam distinction is that RAG augments the model’s context window at runtime, while fine-tuning permanently adjusts model weights through additional training. RAG is preferred when data changes frequently or when knowledge is proprietary, because updating the data source requires no retraining.
A store of embeddings that supports fast similarity search for retrieval.
A vector database stores high-dimensional embeddings and retrieves the entries most semantically similar to a query vector, typically using approximate nearest-neighbor search. This makes it the backbone of Retrieval-Augmented Generation (RAG): a foundation model in Amazon Bedrock embeds the user’s query, the vector database returns the closest matching document chunks, and those chunks are passed as context before the model answers. On AWS, two common choices are Amazon OpenSearch Service (k-NN plugin) and Amazon Aurora PostgreSQL with the pgvector extension. A vector database handles retrieval — it does not generate the embeddings; that belongs to the embedding model.
Amazon Bedrock Knowledge Bases — managed RAG that connects FMs to your data sources.
Amazon Bedrock Knowledge Bases is a fully managed Retrieval-Augmented Generation (RAG) feature that connects foundation models to private data in sources like Amazon S3. It automates the whole pipeline: ingesting documents, splitting them into chunks, generating vector embeddings, storing them in a managed vector store, and retrieving relevant passages at query time to pass as context to the FM. The key exam distinction is Knowledge Bases versus Bedrock Agents: Knowledge Bases handle passive retrieval from documents, while Agents orchestrate multi-step actions by calling APIs and tools. Confusing retrieval with orchestration is a common AIF-C01 trap.
Amazon OpenSearch Service — a search and analytics engine usable as a vector store for RAG.
Amazon OpenSearch Service is a managed search and analytics engine built on the open-source OpenSearch project. In generative AI it acts as a vector store, indexing high-dimensional embeddings and running k-nearest-neighbor (k-NN) queries to retrieve semantically similar documents — the core retrieval step in a RAG pipeline. Amazon Bedrock Knowledge Bases can use OpenSearch Serverless as a fully managed, auto-scaling vector backend, removing the need to provision or tune cluster capacity. The key exam distinction versus a dedicated vector store like Aurora PostgreSQL with pgvector or Pinecone: OpenSearch combines dense vector search with traditional keyword (BM25) search in one engine, enabling hybrid retrieval. When a question asks which AWS-native service supports both lexical and semantic search together, OpenSearch is the answer.
A PostgreSQL/Aurora extension that stores and searches embedding vectors.
pgvector is an open-source PostgreSQL extension that adds a native vector data type and similarity search operators (cosine, L2, inner product) directly to a relational database. Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL both support it, making either service usable as a vector store for retrieval-augmented generation (RAG) pipelines without provisioning a separate purpose-built vector database. The key exam distinction is that pgvector keeps vector search inside a familiar SQL engine alongside structured relational data, suiting workloads that already run on Aurora. Purpose-built vector databases such as Amazon OpenSearch Serverless or Amazon MemoryDB can offer higher throughput at very large scale, so the exam may test when pgvector is a practical trade-off versus a dedicated service.
Customizing a foundation model by further training it on labeled, task-specific data.
Fine-tuning trains a foundation model further on a labeled, domain-specific dataset, updating its weights so the model internalizes new patterns rather than reading them only at inference. In Amazon Bedrock this is called model customization, available for select base models, adapting it to proprietary tone, terminology, or task formats. The key exam distinction is from retrieval-augmented generation (RAG): RAG keeps weights frozen and injects context from a knowledge base at query time, making it cheaper and easier to update. Fine-tuning bakes knowledge into the weights, which is more powerful for stylistic or behavioral change but requires labeled data, compute, and redeployment when the underlying facts change.
Guiding a model's behavior by including instructions or examples directly in the prompt.
In-context learning shapes a foundation model’s behavior entirely through the text supplied in the prompt — examples, instructions, or role descriptions — without updating any model parameters. Because the weights stay frozen, no training job or fine-tuning pipeline is needed, making it the fastest way to steer a model in Amazon Bedrock. The key exam distinction is between in-context learning and fine-tuning: fine-tuning permanently adjusts model weights using a training dataset, while in-context learning is temporary and prompt-scoped. Zero-shot, one-shot, and few-shot prompting are all forms of in-context learning, differing only in how many examples the prompt embeds.
Further training an FM on large amounts of unlabeled domain data to build domain knowledge.
Continued pre-training trains a foundation model further on large volumes of unlabeled, domain-specific text — such as medical literature or financial filings — so it internalizes specialized vocabulary and context. Amazon Bedrock offers it as a managed customization job that updates model weights without labeled data. The key exam distinction is the data requirement: continued pre-training uses raw, unlabeled corpora to extend domain knowledge, while fine-tuning needs labeled prompt-and-completion pairs to shape task behavior. Both modify the model’s weights, which separates them from retrieval-augmented generation, which leaves the weights untouched and instead injects external context at inference time.