The AWS Certified AI Practitioner (AIF-C01) exam will not ask you to train a neural network, but it will absolutely ask you to make the two decisions every real generative-AI project starts with: which foundation model do I use, and how do I configure its inference to get the output I want? Those two questions map directly to Amazon Bedrock — AWS’s managed, serverless gateway to foundation models from multiple providers — and they show up on the exam as scenario questions. “A team needs a low-latency model for a customer-facing chatbot on a tight budget.” “Outputs must be deterministic and repeatable.” “The model keeps rambling past the answer.” Each phrase points to a specific model choice or a specific inference parameter, and the exam is testing whether you can make that connection.
This guide covers the model-selection and inference-tuning knowledge the AIF-C01 rewards: how to choose a foundation model by capability, modality, context window, cost, and latency; and what temperature, top-p, top-k, max tokens, and stop sequences actually do to a model’s output. We will keep it grounded in how you configure these on Bedrock, with comparison tables and a decision framework, then close with an FAQ. If you are still building your foundation, start with the generative AI fundamentals guide and the Amazon Bedrock overview.
Why Model Selection Is an AIF-C01 Skill, Not a Data-Science One
The AIF-C01 is a foundational, business-and-concepts exam. It does not expect you to fine-tune weights or read a research paper. It expects you to reason like someone advising a project: given requirements, pick the right managed building block. Amazon Bedrock is the center of that story because it removes the hard parts — no infrastructure to provision, no models to host — and exposes many models through one API. That design is itself testable: Bedrock’s value proposition is choice of models plus serverless access plus enterprise controls (privacy, guardrails, and integration with the rest of AWS).
Because Bedrock offers many models, the exam can fairly ask you to choose among them. The choice is never “which model is best” in the abstract — it is “which model best fits these constraints.” That reframing is the whole skill.
The Dimensions of Foundation Model Selection
When a scenario asks you to pick a model, evaluate it along these dimensions. Most questions turn on exactly one of them being the binding constraint.
| Dimension | The question it answers | Exam signal words |
|---|---|---|
| Modality | Does it handle text, images, embeddings, or multiple? | “generate images,” “search by meaning,” “multimodal” |
| Capability / quality | Is it strong enough for the reasoning/complexity needed? | “complex reasoning,” “high-quality,” “nuanced” |
| Context window | How much input + output can it handle at once? | “long document,” “entire codebase,” “large context” |
| Latency | How fast must the first/last token arrive? | “real-time,” “low latency,” “interactive chatbot” |
| Cost | What is the budget per token / per request? | “cost-effective,” “high volume,” “tight budget” |
| Customization | Can it be fine-tuned or grounded with your data? | “fine-tune,” “domain-specific,” “company data” |
| Language / region | Does it support the needed languages and Region? | “multilingual,” “available in region” |
Modality: match the model to the data type
The first filter is almost always modality, and getting it wrong makes every other consideration moot:
- Text generation models produce and reason over text — chat, summarization, drafting, Q&A.
- Image generation models produce images from text prompts (text-to-image).
- Multimodal models accept more than one input type — for example, an image plus a text question.
- Embedding models convert text (or images) into numeric vectors that capture meaning. They do not generate prose; they power semantic search, clustering, and Retrieval-Augmented Generation.
A frequent trap: a scenario about “finding documents by meaning rather than keywords” or “powering a RAG knowledge base” wants an embedding model, not a text-generation model. If you see semantic search or vector search, think embeddings. For how embeddings feed a knowledge base, see the foundation-model applications, RAG & fine-tuning guide.
Context window: the size of the model’s working memory
The context window is the maximum amount of text — measured in tokens — a model can consider in a single request, counting both your input (prompt) and its output (completion). A token is a chunk of text, very roughly ¾ of a word in English. A model with a small context window cannot “see” a 200-page contract all at once; a model with a large window can.
Two exam-relevant consequences follow. First, if a scenario needs the model to reason over a long document or a long conversation history in one shot, it needs a large context window — or an architecture (like RAG) that retrieves only the relevant slices. Second, larger inputs cost more and are slower, because pricing and latency scale with tokens processed. Context window is capability, but it is not free.
Cost and latency: the trade-off the exam loves
Bigger, more capable models generally cost more per token and respond more slowly. Smaller models are cheaper and faster but less capable on hard tasks. This tension drives a huge share of selection questions:
- Customer-facing chatbot, high volume, tight budget → favor a smaller, faster, cheaper model; the task is usually simple enough.
- Complex legal or financial analysis, accuracy critical → favor a larger, higher-capability model; the cost is justified by the stakes.
Bedrock pricing is token-based for on-demand use (you pay per input and output token), which is why cost questions and context-window questions are related — more tokens, more money. For predictable high-throughput workloads, Bedrock also offers Provisioned Throughput, where you buy dedicated model capacity for a steadier cost and guaranteed performance. Recognizing that “on-demand pay-per-token vs provisioned dedicated capacity” distinction is enough for the AIF-C01.
Inference Parameters: Shaping the Output
Once you have chosen a model, inference parameters control how it generates text at request time — without changing the model itself. They fall into two groups: parameters that control randomness (how creative vs deterministic the output is) and parameters that control length (how much it generates and when it stops). This is the most reliably tested corner of the whole topic, so learn each one precisely.
How a model actually generates text
A language model predicts the next token by producing a probability distribution over all possible next tokens. “The sky is ___” might yield blue at 60%, clear at 15%, falling at 2%, and so on. The randomness parameters decide how the model picks from that distribution. Understanding this one sentence makes temperature, top-p, and top-k intuitive instead of memorized.
Temperature: the creativity dial
Temperature rescales the probability distribution before sampling. It typically ranges from 0 to 1 (some models allow higher).
- Low temperature (near 0) sharpens the distribution toward the most likely tokens. Output becomes focused, deterministic, and repeatable — the model almost always picks the top choice. Use it for factual answers, extraction, classification, and code, where you want consistency.
- High temperature (toward 1) flattens the distribution, giving lower-probability tokens a real chance. Output becomes diverse, creative, and surprising — and more prone to going off-topic or hallucinating. Use it for brainstorming, marketing copy, and creative writing.
The exam’s favorite phrasings: “outputs must be consistent and repeatable” or “deterministic” → low temperature. “More creative / varied / diverse” → high temperature.
Top-P (nucleus sampling): cumulative-probability cutoff
Top-p limits sampling to the smallest set of tokens whose probabilities add up to p. With top_p = 0.9, the model considers only the most likely tokens that together account for 90% of the probability mass, and ignores the long tail. Lower top-p → fewer candidate tokens → more focused output; higher top-p → wider net → more variety. It is an alternative lever on the same randomness that temperature controls, cutting by cumulative probability rather than by rescaling.
Top-K: fixed-count cutoff
Top-k limits sampling to the k most likely tokens, regardless of their probabilities. With top_k = 50, only the 50 highest-probability tokens are eligible. It is the count-based cousin of top-p: top-k caps the number of candidates; top-p caps the cumulative probability of candidates.
You do not usually tune all three at once. The AIF-C01 wants you to know what each does and, most importantly, that temperature, top-p, and top-k all govern randomness/diversity — lower values mean more focused and deterministic output, higher values mean more varied and creative output.
| Parameter | Cuts by | Lower value → | Higher value → |
|---|---|---|---|
| Temperature | Rescaling the whole distribution | Focused, deterministic | Creative, random |
| Top-P | Cumulative probability (e.g. top 90%) | Fewer candidates, focused | More candidates, diverse |
| Top-K | Fixed count (e.g. top 50 tokens) | Fewer candidates, focused | More candidates, diverse |
Length parameters: max tokens and stop sequences
Two more parameters control how much the model produces:
- Maximum tokens (max length) caps the number of tokens in the response. Set it too low and the answer is truncated mid-sentence; set it high enough for the expected output. This is also a cost control, since you pay per output token. Exam trap: “responses are being cut off” → the max tokens limit is too low.
- Stop sequences are strings that tell the model to stop generating as soon as it produces one. If you define
\n\nor"END"as a stop sequence, generation halts there. They are how you keep a model from rambling past the answer or from continuing into an unwanted next section.
Putting It Together on Amazon Bedrock
On Bedrock, these choices are made in two places. You select the model (by its model ID, e.g. through the Bedrock console’s model catalog or the InvokeModel API), and you pass inference parameters in the request body — temperature, topP, topK, maxTokens, and stopSequences (exact field names vary slightly by model provider). The Bedrock playground lets you experiment with prompts and sliders for these parameters before writing any code, which is the fastest way to build intuition for how each dial changes the output.
A worked example ties the concepts together. Suppose you are building a support-ticket classifier that must always return one of five category labels, cheaply, at high volume:
- Model: a smaller, low-latency, low-cost text model — the task is simple classification, not deep reasoning.
- Temperature: near 0 — you want the same label for the same ticket every time (deterministic).
- Max tokens: low — the output is a single short label, so cap it to save cost and prevent rambling.
- Stop sequence: optionally a newline, so it emits the label and stops.
Change the requirement to “generate three creative marketing taglines” and every dial flips: a higher-capability model, higher temperature, higher max tokens. Same framework, opposite settings — which is exactly the reasoning the exam is checking.
Decision Cheat Sheet
| The scenario says… | The answer involves… |
|---|---|
| ”Search documents by meaning / power a RAG store.” | An embedding model. |
| ”Generate images from a text prompt.” | An image generation model. |
| ”Reason over a very long document at once.” | A model with a large context window. |
| ”Real-time chatbot, high volume, low budget.” | A smaller, faster, cheaper model. |
| ”Accuracy on complex reasoning is critical.” | A larger, higher-capability model. |
| ”Outputs must be consistent / deterministic.” | Low temperature (near 0). |
| ”Make responses more creative / varied.” | Higher temperature (and/or top-p/top-k). |
| ”Responses are getting cut off mid-sentence.” | Raise max tokens. |
| ”Stop the model after a certain marker.” | Define a stop sequence. |
| ”Steady, predictable high-throughput capacity.” | Bedrock Provisioned Throughput. |
From Concepts to Confident Answers
The reason this topic feels slippery at first is that temperature, top-p, and top-k all push in the same direction, and it is easy to blur them together. The fix is not more reading — it is answering scenario questions until the mapping from requirement phrase to parameter is automatic, and until you can spot which single dimension a model-selection question actually turns on. That is precisely the pattern-recognition the AIF-C01 rewards.
Sailor.sh’s AWS AI Practitioner (AIF-C01) mock exam bundle gives you full-length, timed practice exams built around these decision points — model selection, inference tuning, Bedrock capabilities, and responsible AI — with explanations that reinforce why each answer is right, not just which letter to pick. Work through those alongside the AIF-C01 study plan and the prompt engineering guide, and by exam day the two starting questions of every GenAI project — which model, which settings — will be second nature. For the exam’s structure and domains, keep the AIF-C01 exam guide for 2026 handy.
Frequently Asked Questions
What is the difference between temperature and top-p?
Both control randomness, but by different mechanisms. Temperature rescales the entire probability distribution — low values make the top tokens dominate (focused), high values give unlikely tokens more chance (creative). Top-p instead keeps only the most likely tokens whose probabilities sum to p (e.g. 90%) and samples from that nucleus. Lowering either one makes output more focused and deterministic; raising either makes it more varied.
What does temperature 0 do?
It makes the model almost always choose the single most probable next token, producing focused, deterministic, and repeatable output. Use it when you need consistency — factual answers, classification, extraction, or code — rather than creativity.
Why are my model’s responses getting cut off?
The maximum tokens (max length) parameter is set too low, so generation stops before the answer is complete. Raise it to accommodate the expected output length. Remember that output tokens are billed, so size it to the task rather than maxing it out blindly.
What is a context window and why does it matter?
The context window is the maximum number of tokens — input plus output — a model can process in one request. It matters because it limits how much text (a long document, a long conversation) the model can consider at once, and because larger token counts cost more and add latency. For inputs bigger than the window, use retrieval (RAG) to feed only the relevant portions.
When should I choose an embedding model instead of a text-generation model?
Choose an embedding model when the task is about understanding or comparing meaning rather than producing prose — semantic search, finding similar documents, clustering, or building the vector store behind a RAG application. Text-generation models produce answers; embedding models produce the numeric vectors that let you search and retrieve.
How do I pick a foundation model on Amazon Bedrock?
Match the model to the binding constraint in your requirements: modality first (text, image, embeddings, multimodal), then capability, context window, latency, cost, and customization needs. Bedrock exposes many models through one API, so you can compare them in the playground and switch by changing the model ID rather than re-architecting.
Do I need to set temperature, top-p, and top-k all at once?
No. They are overlapping levers on the same randomness. In practice you tune one primary control (often temperature) for the behavior you want. The AIF-C01 expects you to know what each parameter does and that all three move output along the same focused-to-creative axis, not to hand-tune all three simultaneously.