AIF-C01 Exam Study Guide

The deciding factor is the data, not the task.

Exam scenarios describe a business use case and ask which learning paradigm applies. Candidates often default to supervised learning because the task sounds familiar, even when the scenario explicitly states there are no labels.

Always identify whether the training data is labeled or unlabeled first, then map to the paradigm. If data has no labels, unsupervised is correct regardless of the application domain.

K-means and K-NN share a letter but nothing else.

K-means is an unsupervised clustering algorithm — it groups data points by similarity without any labels.

K-nearest neighbors is a supervised classification algorithm — it assigns a label to a new data point by looking at the labels of its closest neighbors in the training set.

Because the names are visually similar, this is a reliable exam trap. When you see either algorithm as an option, immediately check whether the scenario involves labeled or unlabeled data to eliminate the wrong one.

When interpretability is a requirement, deep learning is wrong.

Certain domains — regulated industries, financial decisions, medical risk scoring — require that a model's reasoning be traceable and explainable to non-technical stakeholders.

Neural networks and deep learning architectures are black boxes: they can produce accurate outputs but cannot clearly articulate why.

Logistic regression and decision trees make their decision boundaries explicit and auditable.

If a scenario mentions regulatory requirements, auditability, or the need to explain a decision to a human, interpretable models are always the correct choice.

EDA and data preprocessing are neighboring steps with entirely different purposes.

Preprocessing is a corrective step: it resolves known data quality problems such as missing values, inconsistent formats, outliers, and unscaled features.

EDA is a discovery step: it uses statistics and visualizations to uncover patterns, distributions, and correlations that inform later decisions.

A scenario describing correlation analysis, distribution plots, or anomaly discovery is describing EDA.

A scenario describing normalization, imputation, or data cleaning is describing preprocessing.

Conflating the two leads to selecting the wrong lifecycle phase.

Compliance and regulatory requirements belong in the business goal phase, not later stages.

Many candidates assume compliance surfaces during data handling or model evaluation. In the ML lifecycle, determining which legal or regulatory frameworks apply to a solution is part of scoping the problem — it is the first step.

Questions that ask when compliance considerations are identified should point to business goal identification.

Precision and recall require reading the scenario carefully for which type of error matters most.

These two metrics measure opposite risks.

Precision answers: "When the model flags something as positive, how often is it actually positive?" It matters when acting on a false positive is costly — wasted resources, unnecessary interventions, eroded trust.

Recall answers: "Of all the things that are actually positive, how many did the model catch?" It matters when missing a true positive is costly — an undetected threat, a missed diagnosis.

Identifying which error is described in the scenario determines the correct metric.

Accuracy is a misleading metric on imbalanced datasets.

A model that always predicts the majority class can achieve high accuracy while failing entirely at its task. When class distribution is skewed — such as rare events or minority categories — F1 score, precision, recall, or AUC give a more honest picture.

Accuracy should only be treated as a reliable standalone metric when classes are roughly balanced.

BLEU and ROUGE are task-specific and not interchangeable.

BLEU was designed for machine translation evaluation: it measures n-gram overlap between a machine-generated translation and a human reference translation.

ROUGE was designed for summarization evaluation: it measures recall of key content from a reference summary.

Neither is appropriate for regression or classification tasks. Applying BLEU to summarization or ROUGE to translation is a common wrong answer.

The fix for overfitting requires increasing regularization, which is counterintuitive.

Overfitting means the model has learned the training data too specifically and fails to generalize. The instinctive response is to train more or increase model complexity — both of which make the problem worse. The correct remedies are to increase the regularization parameter (adding a penalty for complexity), reduce the number of features, or supply more diverse training data.

Decreasing the regularization parameter relaxes constraints on the model and exacerbates overfitting.

Asynchronous and batch inference are not the same despite both being non-immediate.

Asynchronous inference is designed for large individual requests — single inputs up to 1 GB that take a long time to process — where the result is retrieved shortly after completion rather than immediately.

Batch transform is designed for bulk processing of entire datasets at a scheduled time, with no real-time component at all.

Serverless inference is optimized for sporadic, low-frequency workloads where cold starts are acceptable; it is not the same as real-time, which requires consistently low latency.

Reading the scenario for payload size, frequency, and urgency is the key to differentiating these.

Temperature is about output consistency

Temperature controls the probability distribution over possible next tokens at each generation step. Setting it to 0 makes the model deterministically select the most probable token every time, producing stable and repeatable output.

Setting it high allows lower-probability tokens to be selected, increasing variety and creativity at the cost of reliability.

For any scenario that requires consistent, repeatable, or predictable outputs, temperature should be set as close to 0 as possible.

Top K and Top P both narrow token selection but operate on different principles.

Top K sets an absolute limit: at each step, only the K most probable tokens are eligible, regardless of how their probabilities are distributed.

Top P sets a probabilistic threshold: tokens are added to the candidate pool in descending probability order until their cumulative probability reaches P, meaning the actual number of candidates varies by context.

Both reduce randomness, but Top P is more adaptive to the shape of the probability distribution.

The exam may present both as options — Top K controls a count, Top P controls a cumulative percentage.

LLM inference cost is determined by token volume

What drives cost is the total number of tokens processed: input tokens (the prompt, any examples, injected context) plus output tokens (the generated response). To reduce inference cost, reduce prompt length, eliminate unnecessary examples, or constrain maximum output tokens.

Chain-of-thought and few-shot are frequently confused because both involve additional content in the prompt.

Few-shot prompting provides labeled input-output examples that demonstrate a desired format, style, or classification pattern — the model learns by imitation.

Chain-of-thought prompting asks the model to work through intermediate reasoning steps before arriving at a final answer — the model learns to reason, not just imitate.

If the scenario involves showing the model examples of what good output looks like, that is few-shot. If the scenario involves asking the model to explain its reasoning or solve a problem step by step, that is chain-of-thought.

Prompt engineering is always the first and lowest-cost intervention before any model customization.

When a model produces output in the wrong format, language, or structure, the correct first response is to refine the prompt — not to resize the model, adjust the architecture, or initiate fine-tuning.

Prompt changes require no training, no infrastructure, and no cost beyond the token count.

Fine-tuning and retraining are appropriate only after prompt engineering has been genuinely exhausted.

RAG and fine-tuning address fundamentally different problems and cannot substitute for each other.

Fine-tuning reshapes how the model behaves — its tone, vocabulary, output structure, and domain-specific response patterns — but it does not efficiently update the model's factual knowledge over time.

RAG does not change the model at all; instead it retrieves current, relevant information at query time and injects it into the prompt, keeping responses grounded in up-to-date sources.

When knowledge changes frequently, fine-tuning is the wrong tool: you would need to retrain the model every time facts change. RAG handles dynamic knowledge without any retraining.

Fine-tuning and continued pre-training require different data formats and serve different goals.

Fine-tuning requires labeled pairs of prompts and expected completions — structured input-output examples that teach the model to behave in a specific way for a specific task.

Continued pre-training uses large volumes of raw, unlabeled domain text to expose the model to domain-specific terminology and writing patterns, without teaching it to produce any particular output format.

Providing unlabeled text when fine-tuning is expected, or providing labeled pairs when continued pre-training is described, will not produce the intended result.

Embedding models and generation models serve opposite purposes and cannot be swapped.

An embedding model converts text or images into dense numerical vectors for use in similarity comparisons, semantic search, and RAG retrieval pipelines — it does not generate readable output.

A generation model produces new content: text, images, or audio.

When a use case involves searching, matching, or ranking content by semantic similarity, an embedding model is needed. When it involves producing new content from a prompt, a generation model is needed.

Multi-modal variants exist for both — they accept or produce combinations of text and images, but the embedding vs. generation distinction still applies.

BLEU is a comparative metric, not an absolute quality score.

A BLEU score only has meaning when comparing two systems translating the same source content against the same human reference. It cannot tell you whether a translation is "good" in isolation — only whether it resembles the human reference more or less than another system does.

BLEU also does not measure fluency, meaning, or style directly. It is specifically a translation evaluation tool and should not be applied to summarization, classification, or other generative tasks.

Guardrails and watermark detection are completely separate features that do not overlap in purpose.

Guardrails are a runtime content control mechanism: they inspect model inputs and outputs and enforce rules around harmful content categories, blocked topics, sensitive information, and specific words. ** Watermark detection** is a provenance tool: it determines whether a given image was generated by the Amazon Titan Image Generator, helping identify AI-created images after the fact.

One filters what the model says; the other identifies the origin of an image. They are not interchangeable and serve unrelated use cases.

Amazon Bedrock does not expose user data to the underlying model providers.

A common assumption is that using a third-party model through Bedrock means the model vendor can see your prompts and responses. This is not the case: Amazon Bedrock does not share user inputs or model outputs with any third-party model provider. This data privacy assurance is frequently tested and is a key differentiator from direct API access to those same model vendors.

A fine-tuned model in Bedrock cannot serve traffic until Provisioned Throughput is purchased.

Fine-tuning in Bedrock creates a custom model artifact, but that artifact is not automatically deployable. Unlike base models, which can be invoked on demand, custom fine-tuned models require a Provisioned Throughput commitment before they can receive inference requests. Skipping this step means the custom model has no serving capacity and cannot be used in production.

Built-in content filters and configured denied topics are not the same mechanism, and the default content filter categories are narrower than most candidates expect.

Content filters target universally harmful content: violence, hate, sexual content, insults, and misconduct. They do not, by default, block topics that are sensitive but not inherently harmful — such as politics, religion, competitor products, or gambling. Those types of restrictions require explicitly configuring a denied topics list.

Assuming that content filters cover all unwanted content is a common error; topic-based restrictions require a separate and deliberate configuration step.

SageMaker Clarify and SageMaker Model Monitor are both quality tools but address different problems at different lifecycle stages.

Clarify is used during development: it statistically evaluates training data and model outputs for bias across demographic groups, and it generates feature-level explanations (using Shapley values) for why a model made specific predictions.

Model Monitor is used in production: it continuously compares live inference data against a baseline to detect when the model's input distribution or output behavior has drifted from its original state.

Clarify does not detect drift; Model Monitor does not explain predictions or detect bias in training data.

SageMaker Model Cards and SageMaker Model Registry are commonly confused because both involve recording information about models.

Model Cards are documentation artifacts for transparency and compliance: they describe the model's intended use, training methodology, performance characteristics, limitations, and ethical considerations.

Model Registry is a versioning and lifecycle management system: it stores the trained model artifacts, tracks versions, and controls the promotion workflow from development to production.

One is a human-readable document; the other is a software catalog and deployment pipeline.

Amazon Rekognition is a computer vision service with no language or translation capabilities.

Rekognition analyzes images and video frames to detect objects, faces, scenes, and text embedded within visual content. It does not translate, understand natural language, or handle multilingual content.

Any scenario involving multiple spoken or written languages should point to Amazon Translate for text conversion between languages, or Amazon Polly for synthesizing speech in a target language — not Rekognition.

Performing sentiment analysis on audio is a two-service pipeline, not a one-service task.

Amazon Transcribe converts audio to text; it does not analyze sentiment.

Amazon Comprehend analyzes text for sentiment, entities, and key phrases; it cannot process audio.

Neither service covers the full workflow alone. Selecting only Transcribe leaves the analysis undone; selecting only Comprehend ignores the fact that the input is audio. The correct answer always requires both services in sequence.

Amazon Textract and Amazon Comprehend both deal with text but operate at completely different layers.

Textract is an extraction tool: it reads scanned documents, PDFs, and images and pulls out the raw text and structured data embedded within them, such as tables and form fields.

Comprehend is an analysis tool: it processes text that has already been extracted and derives meaning from it — sentiment, named entities, key phrases, PII, language.

Textract sees pixels and produces text; Comprehend sees text and produces insight. They are complementary services, not alternatives.

The Amazon Q variants target completely different user personas and are not interchangeable.

Q Business serves general enterprise employees querying internal company knowledge bases.

Q Developer serves software engineers within an IDE for coding, testing, and documentation tasks.

Q in QuickSight serves business analysts creating data visualizations through natural language.

Q in Connect supports live customer service agents during active customer interactions.

Selecting Q Business for a developer productivity scenario, or Q Developer for an enterprise knowledge question, are common mistakes caused by treating "Amazon Q" as a single product rather than a family of purpose-specific tools.

RAG addresses knowledge gaps; fine-tuning addresses behavioral gaps. Applying the wrong one wastes time and money.

If the issue is that the model does not know certain facts, lacks access to specific documents, or produces outdated information, RAG is the appropriate solution — it retrieves the relevant knowledge at query time without modifying the model.

If the issue is that the model produces output in the wrong format, tone, structure, or domain-specific style despite having the necessary knowledge, fine-tuning is the appropriate solution — it shapes behavior through additional training.

Attempting to fine-tune a model on factual documents to keep it current requires retraining every time facts change, which is expensive and operationally impractical.

Fairness and explainability are related concepts that test different things.

Fairness is a population-level property: it asks whether the model produces equitable outcomes across different demographic or social groups, and whether certain groups are systematically advantaged or disadvantaged by the model's predictions.

Explainability is a decision-level property: it asks whether the reasoning behind a specific prediction can be articulated in a way that a human can understand, verify, and act on. A model can be explainable but unfair if its transparent reasoning is based on biased patterns.

The exam differentiates them by whether the scenario describes a group-level outcome disparity (fairness) or the need to justify a specific individual decision (explainability).

Sampling bias and measurement bias are both data problems but have different root causes and different solutions.

Sampling bias is a coverage problem: the data collection process failed to represent certain groups, conditions, or scenarios in proportion to how they appear in the real world. The model then learns a skewed view of reality.

Measurement bias is an accuracy problem: data was collected from the right population but recorded, labeled, or quantified inconsistently — the same real-world condition is captured differently across subgroups or time periods.

Fixing sampling bias requires collecting more representative data; fixing measurement bias requires standardizing collection and labeling procedures.

Pitfall — RLHF and Amazon A2I both involve human feedback but operate at completely different points in the AI lifecycle and should never be confused.

RLHF (Reinforcement Learning from Human Feedback) is a training-time technique: human raters evaluate model-generated outputs during the training process, and those preferences are used as reward signals to steer the model toward better behavior before deployment.

Amazon A2I is an inference-time mechanism: it routes individual production predictions to human reviewers when the model's confidence falls below a defined threshold, providing a safety net around live outputs without modifying the model.

RLHF improves the model itself during training; A2I supplements the deployed model with human oversight in production.

Customer security responsibility scales with how much of the stack the customer owns, and the exam tests this spectrum directly.

When a company consumes AI through a fully managed third-party application, the vendor and AWS handle nearly all infrastructure and model security; the customer is responsible only for access management and appropriate usage.

As customers move toward building, fine-tuning, or training their own models, they absorb increasing responsibility for training data security, model artifact protection, output validation, and infrastructure configuration.

The exam will describe an implementation approach and ask where responsibility lies — always map the approach to its position on the spectrum from fully managed to fully custom.

Data access isolation across multiple teams in Bedrock requires separate, scoped service roles — not a single shared role filtered at the application layer.

A single Bedrock service role with broad S3 permissions satisfies basic functionality but violates least privilege and creates no enforcement boundary between teams. Each team should be assigned a role scoped exclusively to their own data resources.

Relying on application logic or user self-reporting to limit data access is not a security control — it is an assumption, and it fails the moment the application has a bug or a user makes a mistake.

AWS PrivateLink is the correct and only answer when traffic between a VPC and an AWS service must not traverse the public internet.

CloudFront is a content delivery network that accelerates public-facing traffic — it does not create private network paths. Internet gateways route traffic through the public internet by definition, which is the opposite of what private connectivity requires.

A VPN connects on-premises networks to AWS but does not create a private path between AWS services within the same cloud environment.

PrivateLink creates an internal network endpoint within the AWS backbone, ensuring that data between the VPC and the service never leaves the AWS network and never touches the public internet.

CloudTrail, CloudWatch, Config, and Audit Manager all relate to monitoring but serve non-overlapping purposes, and selecting the wrong one is a common exam error.

CloudTrail records who made API calls, from where, and when — it is the authoritative source for access auditing and investigating unauthorized activity.

CloudWatch monitors what the system is doing right now — collecting operational metrics, logs, and events to trigger alarms and dashboards.

Config evaluates whether AWS resource configurations comply with defined rules over time, answering whether infrastructure is set up according to policy.

Audit Manager aggregates evidence across services to support formal compliance assessments against frameworks like ISO or SOC, producing structured audit reports.

Each serves a distinct governance layer; the scenario's question — who accessed what, what is the system doing, is the configuration compliant, or what does our compliance evidence show — determines the correct service.

Amazon Macie is the purpose-built service for automated sensitive data detection across S3.

Comprehend can detect and redact PII within text that is already extracted and passed to it programmatically, but it requires integration work and does not natively scan S3 buckets.

Macie continuously monitors S3 objects for sensitive data patterns — including PII, credentials, and financial information — and generates automated findings and alerts without requiring application code to orchestrate it.

When a scenario describes automated, ongoing discovery of sensitive content in S3 with minimal development effort, Macie is the answer.

Encrypting training data protects it at rest and in transit, but does not prevent a trained model from learning and reproducing that information.

A common misconception is that if sensitive data is encrypted before being used for training, the model cannot expose it. Encryption governs access to the raw data — it does not affect what patterns the model learns. If personally identifiable, confidential, or regulated information is present in training data, the model may reproduce or infer that information in its outputs regardless of how the source data was stored. The correct approach to preventing a model from generating responses based on sensitive training content is to remove or de-identify that data before training ever begins.

Data residency and data lineage are distinct governance concerns that are frequently conflated.

Data residency is a geographic constraint: regulations in many jurisdictions prohibit certain types of data — patient records, financial data, citizen data — from being stored or processed outside a defined geographic boundary. It is a where question.

Data lineage is an audit and traceability concern: it tracks how data has moved, been transformed, and been used throughout its lifecycle. It is a history question.

A scenario about regulatory requirements preventing data from crossing a national border is a data residency concern; a scenario about tracing the origin of a dataset used to train a model is a data lineage concern.

Prompt injection is an input-layer attack and cannot be mitigated by changing the underlying model.

The vulnerability exists because LLMs process user-supplied input and system instructions in the same text stream, making it possible for a crafted user message to override, neutralize, or extract the system's configured behavior.

Switching to a different base model or fine-tuning does not close this vulnerability because the architecture of how instructions and inputs are combined remains unchanged.

Defenses must be applied at the input handling and prompt construction layer: using Guardrails to inspect inputs, structuring prompts to separate system instructions from user content, and using denied topics to block extraction attempts.