AIF-C01 Cheat Sheet

These four terms nest, they are not synonyms: AI is the broad goal of machine intelligence, ML is the subset that learns patterns from data instead of hand-coded rules, deep learning is the subset of ML built on multi-layer neural networks, and generative AI is the application built on deep-learning foundation models. Because each is contained in the one above, deep learning is a form of ML, never a competing alternative to it.

Trap Treating deep learning as a replacement for or alternative to machine learning, when it is a subset of it.

Deep learning is machine learning that uses neural networks stacked with many hidden layers between the input and output layers of weighted artificial neurons. That depth lets the network learn its own hierarchical features straight from raw, unstructured input, which is why it powers computer vision and NLP without the manual feature engineering classical ML demands.

Trap Calling any single-layer neural network deep learning, when the 'deep' refers to the many stacked hidden layers it adds.

Computer vision and NLP are application domains you map a need onto, not learning techniques. Computer vision extracts insight from images and video (classification, object detection, facial recognition); NLP extracts meaning from text (sentiment, entities, translation, summarization). The exam offers them as the answer to "what kind of problem is this," so don't read them as paradigms or model types.

Trap Picking a learning paradigm (supervised, unsupervised) when the stem is actually asking which problem domain (vision vs language) applies.

An algorithm is the learning procedure (gradient descent, a decision-tree splitting rule); a model is the artifact that procedure produces, storing the learned parameters you then deploy. The exam-portable phrasing is: you train an algorithm on data to produce a model, then run inference with the model. Keep the two roles distinct, because a stem often swaps them to test exactly this.

Trap Calling the algorithm the deployed thing that makes predictions: predictions come from the trained model, not the procedure that built it.

Training is the phase where the algorithm consumes data and adjusts the model's internal parameters; inference is the later phase where the finished model takes new, unseen input and returns a prediction. No learning happens at inference time: it runs read-only against frozen parameters, which is why serving cost and retraining cost are separate concerns.

Trap Assuming a model keeps learning from the live requests it serves: parameters are fixed at inference until you deliberately retrain.

Supervised learning trains on labeled examples (each input paired with its correct output) to learn the mapping from one to the other. It splits into two shapes: classification predicts a discrete category (spam vs not-spam, fraud vs legitimate), and regression predicts a continuous number (price, demand). A stem that hands you historical records already tagged with the answer and asks for a category or a number is supervised.

Trap Reaching for unsupervised learning when the data already carries the labeled outcome you want to predict: labeled targets make it supervised.

Unsupervised learning trains on unlabeled data with no target column and surfaces patterns on its own. Its canonical tasks are clustering (customer segmentation), dimensionality reduction, and anomaly detection. The tell in a stem is the absence of a known answer paired with a discovery goal: "find natural groups," "flag unusual transactions without any prior fraud labels."

Trap Labeling anomaly detection on unlabeled data as supervised: there are no fraud labels to learn from, so the model groups by structure alone.

Reinforcement learning has no fixed table of right answers: an agent takes actions in an environment and learns a policy that maximizes cumulative reward by trial and error. Stem signals are an agent, actions, rewards or penalties, sequential decisions, or a game/robot/control loop. The learning comes from the reward feedback, not from a corpus of labeled or unlabeled examples.

Trap Choosing an answer that frames reinforcement learning as training on a labeled or unlabeled dataset: RL learns from rewards, not a dataset of answers.

To choose supervised vs unsupervised vs reinforcement, read what the data carries, never the business objective: each record tagged with its outcome → supervised; no target, asking to find groups or outliers → unsupervised; an agent earning rewards through a feedback loop → reinforcement. The same business goal can land in different paradigms depending only on the data you hold.

Trap Picking the learning paradigm from the business objective, when only the data you hold (labeled, unlabeled, or reward-driven) decides it.

Labeled vs unlabeled, structured vs unstructured, and the concrete shape (tabular, time-series, image, text) are separate axes: one record can be labeled and tabular and structured all at once. Only the labeled-vs-unlabeled axis decides supervised vs unsupervised; the answer choices reveal which axis a "what type of data" stem is really probing.

Trap Assuming structured data must be labeled or that unstructured data must be unlabeled, when those axes are independent of each other.

Structured data has a standardized tabular format: rows and columns with a defined schema, as in databases and spreadsheets (including timestamp-ordered time-series). Unstructured data (free text, images, audio, video) has no set data model, makes up roughly 80–90% of enterprise data, and typically calls for deep learning, since classical tabular methods can't capture its signal.

Trap Reaching for classical tabular methods on free text, images, or audio, when unstructured data has no schema and typically needs deep learning.

Real-time (online) inference serves one prediction at a time from a persistent low-latency endpoint for interactive use (a chatbot reply, a fraud check at checkout). Batch inference scores a large, bounded set asynchronously on a schedule, trading latency for throughput and a lower cost per prediction (rescore the whole customer base overnight). The deciding question is whether a human or system is waiting on each individual prediction.

Trap Choosing batch versus real-time by dataset size rather than by whether something is waiting on each individual prediction.

Across deployment patterns the tradeoff is fixed: batch inference is cheapest per prediction but highest latency, while a real-time endpoint is lowest latency but pays for always-on compute. Match the pattern to whether anything waits on the result: an overnight bulk job wants batch, a live checkout fraud check needs the real-time endpoint.

Trap Putting an overnight bulk-scoring job on an always-on real-time endpoint: it meets a latency requirement nobody has while paying for idle compute.

A model overfits when it memorizes the noise and quirks of its training data, scoring well on that data but poorly on new, unseen data. The exam signature is "performs well in training but poorly on new data." Crucially, more training of the same kind can increase variance and worsen overfitting, so "insufficient training" is a wrong diagnosis for an overfit model.

Trap Blaming insufficient training for an overfit model: more of the same training tightens the fit to noise and makes overfitting worse, not better.

A model underfits when it is too simple to capture the real signal, so it never finds a meaningful input-output relationship and scores poorly on both training and new data. The mechanical rule that separates the two failure modes: poor on training too → underfit; great on training but poor on new data → overfit.

Trap Diagnosing a model that scores poorly on its own training data as overfit, when poor training performance is the signature of underfitting.

The bias-variance tradeoff maps straight onto fit: an underfit model has high bias (inaccurate on both training and test sets), while an overfit model has high variance (accurate on training but not on test/unseen data). The target is the balanced sweet spot that generalizes, which is exactly why a model's quality is judged on held-out data rather than the data it trained on.

Trap Pairing overfitting with high bias and underfitting with high variance, when it is the reverse: overfit is high variance, underfit is high bias.

On this exam "bias" means two unrelated things. Statistical bias is the underfitting error of a too-simple model. Societal/data bias is about outcomes across groups: a model can be accurate on average yet systematically disadvantage a subgroup because the training data encodes historical inequities. An accuracy-and-error stem points at statistical bias; a demographic-and-fairness stem points at data bias.

Trap Reading every mention of "bias" as the statistical underfitting error, when a fairness stem is about disparate outcomes across demographic groups.

Fairness is a model treating relevant groups equitably, and it is independent of average accuracy: a model can be accurate overall yet unfair to a subgroup. AWS even lists fairness as its own dimension of responsible AI, separate from accuracy/robustness, which is why an accurate-but-biased model can still be the wrong one to deploy and why responsible-AI controls exist as a distinct layer.

Trap Concluding a model is safe to deploy because its overall accuracy is high: fairness across groups is a separate property accuracy can't vouch for.

An embedding model converts text (and, for multimodal embeddings, images too) into numerical vectors that capture semantic meaning, placing similar items close together in vector space. This is the component behind semantic search and Amazon Bedrock Knowledge Bases; a multimodal embedding model puts text and image queries into one shared space so a single model can answer both.

Trap Confusing an embedding model with a generative LLM, when an embedding model outputs numerical vectors for similarity search rather than generated text.

Temperature is an inference parameter that reshapes the next-token probability distribution: a low value near 0 steepens it toward more deterministic, consistent answers (FAQ and support bots), while a high value flattens it toward more random, varied output. Lower the temperature when you need repeatable, factual responses; raise it when you want more diverse, creative generation.

Trap Raising temperature to make a model more accurate: it only increases randomness; for consistent, factual answers you lower it instead.

A token is a sequence of characters a model interprets or predicts as a single unit of meaning, which is not the same as a word: it can be a whole word, a sub-word fragment with grammatical meaning (such as "-ed"), a punctuation mark (such as "?"), or a common phrase (such as "a lot"). Both the prompt you send in and the completion the model generates back are counted in tokens, so token count drives length and cost.

Trap Assuming one token always equals one word. A token is usually a fragment, so token counts run higher than word counts.

Foundation-model spend and length limits are billed and constrained in tokens, not words or characters: Amazon Bedrock on-demand pricing charges separately for input and output tokens, so model choice plus prompt and response length drive the bill. A token is typically a fragment of a word rather than a full word, so token totals exceed word totals, but the exact ratio varies by model and tokenizer.

Trap Treating cost or context limits as measured per word or per character. They are counted in tokens, which don't map one-to-one to words.

An embedding transforms input into a vector of numerical values so different objects can be compared by similarity through a shared numerical representation, placing items with similar meaning close together in that vector space. A vector is just the ordered list of numbers; calling it an embedding signals that the numbers encode semantic meaning. Because comparison is by meaning rather than exact characters, "car" and "automobile" land near each other.

Trap Treating an embedding as a stored copy of the original text or characters rather than a numeric encoding of its meaning.

Embeddings place semantically similar items near each other in vector space, so you can retrieve by meaning instead of matching exact words: convert documents and the user query into embeddings, then find the nearest vectors to surface the most relevant passages. This works even when the query and a document share no literal words, which keyword (lexical) search cannot do.

Trap Calling keyword matching semantic search. Matching shared words is lexical search; semantic search compares embedding meaning.

Chunking is the preprocessing step that splits a large document into smaller passages, each of which is embedded and written to the vector index for retrieval. You chunk because one embedding represents a single bounded passage well but a whole book poorly, and because the model's context window can't hold an entire corpus at once. Chunking is what makes large knowledge bases searchable and feedable to a model.

Trap Embedding a whole long document as one vector instead of chunking it, since a single embedding represents a bounded passage well but a full document poorly.

The prompt is the input you provide to guide the model; inference is the model generating the completion (response) from that prompt. Both the prompt and the completion are counted in tokens, and each request stands alone. The model has no memory of prior turns unless you include them in the prompt.

Trap Assuming the model remembers earlier turns on its own, when each request is independent unless you include prior context in the prompt.

The context window is the maximum number of tokens a model can consider at once for a single request, and the prompt and the completion share that one finite budget. A very long prompt leaves less room for the answer, and a long requested answer constrains how much input fits. Content beyond the window is dropped, which is why long documents are chunked and retrieved rather than pasted whole.

Trap Assuming the context window caps only the input. It bounds prompt and completion together, so a long answer eats into room for context.

A foundation model (FM) has a large number of parameters and is pre-trained on a massive amount of broad, mostly unlabeled data, producing a general-purpose base that can generate text or images and convert input into embeddings. One expensive pre-training run yields a reusable model that organizations customize cheaply through prompting, RAG, or fine-tuning instead of training from scratch. A practitioner typically selects and adapts an existing FM rather than building one.

Trap Reaching for from-scratch training to specialize a model when prompting, RAG, or fine-tuning an existing FM is the intended, far cheaper path.

A large language model (LLM) is a foundation model pre-trained on vast amounts of text so it can understand and generate natural language, the text-and-language flavor of an FM. Every LLM is a foundation model, but not every foundation model is an LLM: an image-generation FM is a foundation model that is not a language model. "Foundation model" is the umbrella term; "LLM" is the text-specialized subset.

Trap Treating "foundation model" and "LLM" as synonyms. Image and other non-text FMs are foundation models but not LLMs.

Modern LLMs are built on the transformer, a neural-network architecture of encoders and decoders whose core innovation is the self-attention mechanism. The transformer is an architecture, not a specific named model; for AIF-C01 you only need to recognize that it is what underpins today's LLMs.

Self-attention lets the model weigh how much every other token in the context should influence each token, capturing long-range relationships across a whole passage in parallel rather than strictly left to right. That parallelism is why transformers scaled to today's LLMs, where earlier architectures that processed one token at a time plateaued.

Trap Picturing self-attention as reading strictly left to right one token at a time, when it weighs every token against every other in parallel.

A multimodal model accepts or produces more than one type of data (text, images, audio, or video) for example taking an image plus a text prompt and returning a text answer, or generating an image from a text description. A single multimodal FM can reason across modalities for richer context. The exam cue is a use case that mixes input or output types.

Diffusion models are the family behind most high-quality image generation. Forward diffusion progressively adds Gaussian noise to an image until only random noise remains; the model learns to reverse that process, iteratively denoising from random noise toward a coherent image, most commonly conditioned on a text prompt. LLMs (transformers) generate text while diffusion models generate images, and production systems often combine both.

Trap Assuming a transformer LLM produces the images. Text comes from the LLM, but the image itself is generated by a diffusion model.

Traditional, discriminative ML classifies data points, mapping an input to a fixed output such as a class label or a number (spam vs. not-spam, a price, a fraud score). Generative AI instead learns the patterns of its training data well enough to create new content (text, images, audio, video, code) in response to a prompt. A discriminative model answers "which category or value is this?"; a generative model answers "produce something new that looks like this."

Trap Picking a discriminative, label-predicting model for a task that requires creating new content, since classification answers "which category?" rather than "produce something new."

A discriminative classifier returns the same definite label for the same input, but generative output is stochastic by default: at each step the model samples the next token from a probability distribution, so the same prompt can yield different completions and the model can hallucinate. Lowering the temperature steepens that distribution toward higher-probability tokens for more deterministic responses (temperature 0 is greedy decoding), but you reduce variability without ever fully guaranteeing determinism.

Trap Expecting identical output every call like a classifier. Generation samples from a distribution, so completions vary unless you constrain randomness.

To store embeddings and query them by similarity (nearest-neighbor / semantic search), Amazon OpenSearch Service is AWS's recommended vector database for Amazon Bedrock, and Bedrock Knowledge Bases can quick-create an OpenSearch Serverless collection as the default fully managed store. It is not the sole option, though: Bedrock Knowledge Bases also supports Aurora PostgreSQL (pgvector), Neptune Analytics, Amazon S3 Vectors, and third-party stores like Pinecone, Redis, and MongoDB Atlas.

Trap Assuming OpenSearch is the only AWS vector store for Bedrock. It is the recommended default, but Aurora pgvector, Neptune, and S3 Vectors also qualify.

Amazon Titan Multimodal Embeddings translates text, an image, or a combination of both into an embedding that carries the semantic meaning of each in the same shared vector space, enabling search and recommendation by comparing meaning rather than matching words. It is the model to pick for visual product search where users query by text, by image, or by both.

Trap Reaching for a text-only embedding model for visual search, when only a multimodal embedding model places images and text in one shared vector space.

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.

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.

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.

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.

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.

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.

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.

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 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 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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

AIF-C01 frames responsible AI as a set of named features a system must satisfy together: the Task 4.1 exam guide lists fairness, bias, inclusivity, robustness, safety, and veracity, while the AWS responsible-AI page names eight core dimensions (fairness, explainability, privacy and security, safety, controllability, veracity and robustness, governance, transparency). The point the exam tests is that no single dimension implies the rest: a model can be accurate yet unfair, or fluent yet untruthful, so a stem describes a scenario and you name the dimension it's about.

Trap Treating high overall accuracy as proof a system is responsible: accuracy speaks to one dimension and says nothing about fairness, privacy, or veracity.

Fairness considers the impact on different groups of stakeholders: the system should not systematically advantage or disadvantage a demographic group. A model can post high overall (average) accuracy while still being unfair to a subgroup, so a single global accuracy number never establishes fairness; you have to slice metrics by group. This is why subgroup analysis, not a headline accuracy figure, is the fairness check.

Trap Reporting one aggregate accuracy number as evidence the model is fair: it can hide a subgroup the model serves badly.

Bias is skew that enters from unrepresentative training data or from features that proxy for a protected attribute; the resulting unfair outcome is what that bias produces. Treat bias as the cause and unfairness as the effect, and the earliest, cheapest defense is representative, balanced, curated data: fixing skew before training beats correcting predictions after. Bias mitigation is the ongoing work of measuring and reducing that skew.

Trap Reaching only for a post-training fairness fix while leaving skewed training data in place: the bias re-enters every retrain.

Veracity (truthfulness) means output that is factually accurate and not misleading; for generative AI its headline failure mode is hallucination: fluent, confident text that is simply wrong. Keep it distinct from a safety failure (toxic or harmful output) and a fairness failure (biased output), because the exam pairs each failure with a different control: grounding/RAG for hallucination, content filters for toxicity, bias analysis for fairness.

Trap Calling hallucinated output a safety or bias problem: fluent-but-false text is a veracity failure, and the fix (grounding) differs from a toxicity or bias fix.

Amazon SageMaker Clarify is the AWS service that detects potential bias and computes bias metrics across the lifecycle: during data preparation, after training, and on deployed models. When a scenario asks how to measure whether a dataset or model is biased across groups, Clarify is the answer; it also produces SHAP-based feature-attribution explainability, but bias measurement is its Task 4.1 role.

Trap Reaching for SageMaker Model Monitor to measure bias on a dataset or freshly trained model: Model Monitor watches a live endpoint over time; point-in-time detection is Clarify.

Amazon SageMaker Clarify computes pre-training bias on the raw dataset before any model exists, so you catch skew before spending on training. The metrics are model-agnostic and include Class Imbalance (CI) and Difference in Proportions of Labels (DPL) among eight pre-training measures. A stem that says "check whether the training data is skewed before training" maps to Clarify pre-training bias metrics.

Trap Assuming a balanced count of records per group rules out data bias: Class Imbalance is only one metric; DPL can still flag skewed positive-outcome labels.

Amazon SageMaker Clarify also computes post-training bias on the trained model's predictions, comparing outcomes across groups with eleven metrics including Difference in Positive Proportions in Predicted Labels (DPPL) and Disparate Impact (DI). This separates bias the model learned from bias already sitting in the data: clean data can still yield a model whose predictions skew by group.

Trap Concluding a model is unbiased because the input data passed pre-training checks: the model can still learn skew, which only post-training metrics like DPPL/DI surface.

Amazon Bedrock Guardrails provides configurable safeguards applied across foundation models to filter undesirable content in both user inputs and model responses, covering toxicity, denied topics, PII, prompt-attack attempts, and ungrounded (hallucinated) output. It is the answer whenever a chatbot or FM produces unsafe, off-topic, hallucinated, or PII-leaking text, and it works alongside (not instead of) grounding and human review.

Trap Treating Guardrails as a complete jailbreak defense: its Prompt Attack filter reduces but does not eliminate prompt-injection success.

Amazon Bedrock Guardrails content filters detect and block harmful text or image content across predefined categories (Hate, Insults, Sexual, Violence, Misconduct, and Prompt Attack) each with an adjustable strength. This is the safety control for "block hateful, toxic, or violent generated content" scenarios, applied to both the prompt and the response.

Trap Assuming content filters also stop the model from discussing a specific forbidden subject: category filtering is broad-harm; a named off-limits topic needs Denied topics.

Amazon Bedrock Guardrails denied topics let you define application-specific subjects the model must refuse to discuss, blocking them in user queries or model responses. This is the controllability/safety control for "stop the assistant from giving investment advice" or any named off-limits subject, distinct from the broad-harm content filters, which catch categories like hate or violence rather than a topic you specify.

Trap Reaching for content filters to block a specific named subject like investment advice. Content filters catch broad-harm categories such as hate or violence, while a topic you define yourself is the job of Denied topics.

Amazon Bedrock Guardrails sensitive-information filters detect and either mask or block personally identifiable information (PII) in both prompts and responses, using probabilistic entity detection (SSN, date of birth, address, and more) plus custom regex patterns. This serves the privacy dimension, "redact or block personal data flowing through the model", for example masking PII in summarized call transcripts.

Trap Reaching for Amazon Macie to redact PII flowing through a prompt or response. Macie discovers and classifies sensitive data at rest in S3, not inline model input and output.

Amazon Bedrock Guardrails contextual grounding checks detect hallucinations by flagging responses that are not grounded in the provided source (factually inaccurate or adding new information) or are irrelevant to the user's query. It is the veracity control for RAG apps, "ensure the answer stays grounded in the retrieved documents", and pairs naturally with a knowledge base that supplies that source.

Trap Expecting content filters or denied topics to stop hallucinations: those target harmful or off-limits content; ungrounded-but-clean answers need contextual grounding checks.

Amazon Bedrock Guardrails is defined as configuration applied independently of the underlying model, so one safety policy enforces consistently across the foundation models available in Amazon Bedrock instead of being baked into a single model. You can even evaluate input and output through the ApplyGuardrail API without invoking an FM, which lets the same policy front-end multiple models or a self-managed one.

Amazon SageMaker Model Monitor continuously watches a deployed model in production against a baseline computed from the training data, alerting on drift across four monitor types: data quality, model quality (e.g. accuracy decay), bias drift, and feature-attribution drift, the last two powered by SageMaker Clarify. "Fair at launch but degrading in production" maps to Model Monitor, which runs on a real-time endpoint or a scheduled batch transform and computes metrics on tabular data only.

Trap Reaching for Clarify alone to catch a model that drifts after deployment: Clarify is point-in-time; ongoing drift monitoring on a live endpoint is Model Monitor.

Detecting bias and monitoring bias are different jobs on AIF-C01: SageMaker Clarify is point-in-time bias detection on a dataset or a trained model, while SageMaker Model Monitor does continuous drift monitoring on a live endpoint (its bias-drift monitor is Clarify integrated). Stems with "over time," "in production," or "keeps degrading" select Model Monitor; "before vs after training" or "is this dataset skewed" select Clarify.

Trap Selecting Clarify for a model that keeps degrading in production. Point-in-time detection is Clarify, but ongoing drift on a live endpoint is Model Monitor.

Amazon Augmented AI (Amazon A2I) is a managed human-in-the-loop service that routes selected ML predictions to human reviewers, removing the need to build review systems yourself. Typical triggers are low model confidence, high business impact, or sensitive content; it is the responsible control when an automated output alone is too risky to act on, and it works whether the model runs on AWS or elsewhere.

Trap Reaching for A2I to measure or reduce bias: A2I adds human review of individual predictions; bias measurement is Clarify and ongoing monitoring is Model Monitor.

Task 4.1 lists responsible practices that are not a single AWS service: analyzing label quality (are labels correct and consistent?), human audits (people review samples of model behavior), and subgroup analysis (slice metrics by demographic group instead of trusting one global accuracy number). When a stem asks how to assess fairness without naming a service, these methodology answers, not Clarify or Model Monitor, are correct.

Trap Naming SageMaker Clarify when the stem rules out tooling and asks for a practice: label-quality analysis, human audits, and subgroup analysis are methods, not services.

Responsible development starts with the data: Task 4.1 names inclusivity, diversity, balanced datasets, and curated data from trustworthy sources as the characteristics of a good dataset. Demographic over- or under-representation in training data translates directly into harms against those groups in the output, which is why fixing the dataset is the earliest lever for fairness, earlier and cheaper than correcting a trained model.

Trap Assuming that simply collecting more training data cures unfairness. Volume without representativeness leaves under-represented groups skewed; the real levers are diversity, balance, and curation.

Bias (underfitting) is a model too simple to capture the real X→Y relationship, so it performs poorly even on the training data and produces systematic inaccuracy for groups. Variance (overfitting) is a model that memorizes training data including noise, scoring well in training but failing to generalize to unseen data. Both leave the system wrong for the people it should serve, which is why the exam ties bias and variance to responsible-AI harms.

Trap Reading strong training-set accuracy as a healthy model: that is the signature of overfitting (high variance), which collapses on new data.

Choosing a model responsibly is not just picking the most accurate one: Task 4.1 calls out environmental considerations and sustainability as selection criteria. Very large foundation models carry a real energy and carbon footprint, so a smaller, distilled, or already-managed model that meets the requirement can be the more responsible (and usually cheaper) choice over reaching for the largest model by default.

Trap Defaulting to the largest, most capable model regardless of need: that ignores the sustainability and cost criteria the exam expects you to weigh.

Task 4.1 enumerates the legal and trust risks of working with generative AI: intellectual-property infringement claims (output reproducing copyrighted material, or training data used without rights), biased model outputs, hallucinations, loss of customer trust, and end-user risk in high-stakes domains. These are why responsible deployment layers controls rather than shipping raw model output into a consequential decision.

The responsible answer for high-stakes or sensitive generative decisions is layered, not a single switch: ground the model with RAG (Bedrock Knowledge Bases) to cut hallucination and provide citations, apply Bedrock Guardrails for safety and PII, and route low-confidence or high-impact outputs to a human via Amazon A2I. "Fully automate it" or "just trust the model" are the wrong answers whenever a stem signals high stakes.

Trap Picking full automation or a single control for a high-stakes decision: the exam expects grounding plus guardrails plus human review combined.

The AWS shared responsibility model makes AWS responsible for security of the cloud (physical infrastructure, the hypervisor, and the managed AI services such as Amazon Bedrock and Amazon SageMaker AI themselves) while you are responsible for security in the cloud: IAM permissions, data classification and encryption, the prompts and fine-tuning datasets you supply, and network configuration. AWS does not decide who may call your model or protect the content you send it; that side of the line is always yours.

Trap Assuming AWS secures your data and access because the AI service is fully managed. Managed covers the infrastructure, not your in-the-cloud configuration.

A managed service like Amazon Bedrock being patched, isolated, and operated by AWS does not make your data or access secure on its own. Classifying data, choosing encryption, scoping IAM, and configuring network access all stay on the customer side of the shared responsibility line. "Fully managed" describes who runs the infrastructure, not who controls who can reach your data, which is a recurring Domain 5 distractor.

Trap Picking "fully managed, so no extra security configuration is needed" for a Bedrock workload, when IAM scoping and network controls are still the customer's job.

AWS Identity and Access Management (IAM) controls who can do what through identities and policies, and least privilege means granting each identity only the permissions it genuinely needs. For example, an application role allowed to invoke one specific Amazon Bedrock model but denied access to the raw training data in Amazon S3. AWS frames this as "grant only the permissions required to perform a task," which limits the blast radius if a credential leaks.

Trap Attaching a broad managed policy like a full-access policy to a model-invocation role because it is convenient, instead of narrowing to the specific action and resource.

AWS recommends that workloads use temporary credentials with IAM roles rather than long-lived access keys embedded in code: a role supplies short-term, automatically rotated credentials that a service or application assumes, so there is no static secret to leak. When a scenario asks how to let an application call a model with temporary credentials, the answer is an IAM role; long-term access keys are reserved for the narrow cases that genuinely cannot use a role.

Trap Hard-coding an IAM user's long-lived access key in the application to call the model, when an assumed IAM role would supply rotating temporary credentials instead.

AWS Key Management Service (AWS KMS) creates and controls the cryptographic keys that encrypt data at rest (Amazon S3 objects, training datasets, and model artifacts) and integrates with services such as Amazon S3, Amazon SageMaker AI, and Amazon Bedrock so encryption is applied consistently. When a stem asks how to protect data or model artifacts on disk, manage and rotate keys, or use customer-managed keys, the answer is AWS KMS.

Trap Reaching for AWS KMS to protect data while it travels between client and service, when KMS encrypts data at rest and TLS is what protects data in transit.

Encryption at rest and encryption in transit are distinct controls: at-rest encryption (AWS KMS) protects stored bytes, while in-transit encryption protects data moving over the network using TLS (AWS requires TLS 1.2 and recommends TLS 1.3). A scenario about protecting data as it travels between client and service wants the in-transit / TLS answer, not at-rest key management.

Trap Choosing AWS KMS key management for a requirement about protecting data as it moves over the network, when in-transit protection comes from TLS.

Encrypting data with AWS KMS protects the bytes at rest but does not by itself decide who may decrypt them. That is governed by the KMS key policy together with IAM, which AWS describes as "ensuring that only trusted users have access to KMS keys." A bucket can be fully encrypted and still exposed if permissions are wrong, so a "who is allowed to read this" requirement is solved by IAM and key policy, not by adding more encryption.

Trap Adding encryption to a bucket to fix an over-permissive access problem, when the exposure comes from IAM and bucket/key policy rather than from unencrypted data.

Amazon S3 applies server-side encryption with S3-managed keys (SSE-S3) as the base level of encryption for every bucket, so all new object uploads are encrypted at rest automatically, at no cost and with no configuration. Step up to server-side encryption with customer-managed KMS keys (SSE-KMS) when you need control over key policy, rotation, and access auditing.

Trap Claiming S3 training data sits unencrypted until you turn encryption on. SSE-S3 is the automatic default for all new objects.

Amazon Bedrock encrypts data both at rest and in transit, and lets you supply your own AWS KMS keys for resources such as model customization (fine-tuning) jobs, the resulting custom models, agents, and knowledge-base ingestion jobs. This reflects the shared responsibility split: AWS provides the encryption capability, while choosing and managing customer-managed keys remains your option.

Trap Assuming Bedrock data is unencrypted unless you configure your own KMS keys, when Bedrock encrypts at rest and in transit by default and customer-managed keys are an added option.

Amazon Macie is a managed data-security service that uses machine learning and pattern matching to automatically discover and classify sensitive data (PII, financial information, and credentials) in Amazon S3. Its exam use case is finding sensitive data such as PII in source or training data before that data is used to train or fine-tune a model.

Trap Reaching for Amazon Comprehend to scan S3 datasets for sensitive data, when Macie is the service that discovers and classifies PII directly in S3.

Amazon Macie flags and classifies sensitive data and generates findings, but it does not move, delete, redact, or encrypt the data for you. AWS frames the findings as something to "review and remediate as necessary." If the requirement is to remediate (mask, delete, or encrypt), Macie alone is not the answer; you act on its findings with other controls such as IAM, KMS, or downstream automation via EventBridge.

Trap Choosing Macie to automatically mask or delete the PII it finds. Macie only detects and reports, leaving remediation to other controls.

An Amazon VPC interface endpoint with AWS PrivateLink establishes a private connection to a service such as Amazon Bedrock, so model traffic stays on the AWS private network and your data "isn't available over the internet." When a stem asks how to connect privately to Bedrock or keep model traffic off the public internet, the answer is a VPC interface endpoint via PrivateLink.

Trap Selecting a public endpoint secured with TLS to keep Bedrock traffic off the internet, when only a VPC interface endpoint with PrivateLink keeps the traffic on the AWS private network.

Documenting data origins is a secure-AI governance practice: data lineage records where a dataset came from and how it was transformed across the pipeline, while a data catalog keeps a central, searchable registry of datasets and their metadata so their origin and ownership are discoverable. Together they establish provenance across the ML lifecycle rather than capturing it at a single checkpoint.

Amazon SageMaker Model Cards document a model's intended use, training details and metrics, evaluation results and observations, and a risk rating (Unknown, Low, Medium, or High) in a single record, and any edit other than an approval-status change creates a new version for an immutable audit trail. When a question asks how to document a model's details, provenance, and risk for governance, Model Cards is the standard answer.

Trap Reaching for an AWS AI Service Card to document a model you built. Service Cards are authored by AWS for AWS-managed services you consume, while you write a Model Card for your own model.

Secure data engineering bundles several best practices (assess data quality, apply privacy-enhancing technologies, enforce data access control, and protect data integrity) so that data is safeguarded across collection, storage, training, and inference rather than only at one stage. Treat it as a lifecycle discipline, not a single gate at ingestion.

Assessing data quality is a security concern as well as a reliability one: poisoned, mislabeled, or low-quality training data undermines a model because it is only as trustworthy as the data it learned from, and tampered data is an integrity attack. Protecting data integrity ensures data is not altered in transit or at rest, closing the gap that data-poisoning relies on.

Trap Treating data poisoning as solved by encrypting the dataset, when encryption protects confidentiality but it is integrity checks and data-quality assessment that catch tampered or poisoned training data.

Privacy-enhancing technologies (anonymization, pseudonymization, masking, and tokenization of PII) let a model train on the useful signal while individuals stay unidentifiable. Apply them as a secure-data-engineering step before sensitive data enters or moves through the training pipeline, rather than trying to scrub a trained model after the fact.

Trap Planning to remove PII from the model after training, when privacy-enhancing technologies have to be applied to the data before it enters the training pipeline.

Amazon Bedrock Guardrails filters harmful content, blocks denied topics, and can detect and block or mask sensitive information including PII in both the user's input prompt and the model's response. It is the application-layer complement to infrastructure controls such as IAM, KMS, and network isolation. It governs what the model is asked and what it returns, not who can reach the service, so it works alongside those controls, not as a substitute.

Trap Treating Guardrails as a replacement for IAM and network isolation. It filters prompts and responses but does not control who can invoke the model.

AWS Secrets Manager stores, manages, and rotates secrets such as database credentials, API keys, and OAuth tokens, so applications and notebooks retrieve them at runtime instead of hard-coding them in source. AWS positions it as the way to "replace hard-coded credentials with a runtime call," supporting the least-privilege and infrastructure-protection goals of securing an AI system. For your AWS encryption keys use KMS, and for AWS access prefer IAM roles. Secrets Manager is for the other credentials your app must hold.

Trap Storing AWS access keys in Secrets Manager so an application can call a model, when an assumed IAM role removes the static AWS credential entirely.

Amazon GuardDuty is a managed threat-detection service that continuously analyzes foundational sources (AWS CloudTrail management events, VPC flow logs, and DNS logs) with machine learning and threat intelligence to flag suspicious activity such as compromised or exfiltrated credentials and anomalous API calls, including against generative-AI workloads. It is the automated detection layer for these scenarios, generating findings with no manual log analysis required, and it pairs with services like Amazon Detective for investigation.

Trap Reaching for Amazon Macie to catch a compromised-credential or anomalous-API-access threat. Macie classifies sensitive data in S3, whereas GuardDuty is the threat detector.