Domain 3 of the AWS Certified AI Practitioner (AIF-C01) exam — “Applications of Foundation Models” — is the single largest domain on the test at 28% of your score, roughly 18 of the 65 questions. It’s also the most technical. This is where AWS stops asking “what is generative AI?” and starts asking “given this business scenario, how would you apply a foundation model — and how would you know if it’s working?”
If you’ve studied the AIF-C01 domain breakdown, you know Domains 1 and 2 build the vocabulary. Domain 3 is where that vocabulary gets put to work: choosing a model, deciding between prompt engineering, retrieval-augmented generation (RAG), and fine-tuning, building RAG pipelines with Amazon Bedrock, and evaluating the results. This guide covers all of it from a practitioner’s angle, with the decision frameworks the exam actually rewards.
We’ll reference Amazon Bedrock throughout — it’s the service that ties Domain 3 together — and we’ll keep prompt engineering brief here because it has its own dedicated prompt engineering guide.
What Domain 3 Actually Tests
The official AIF-C01 exam guide frames Domain 3 around four skills. Here’s the plain-English version:
| Sub-domain | What AWS wants you to do |
|---|---|
| Design considerations for FM applications | Choose the right model for cost, latency, modality, and context needs |
| Prompt engineering | Craft effective prompts and set inference parameters |
| Training & fine-tuning | Know when and how to customize a model (fine-tune, continued pre-training) |
| Retrieval & evaluation | Use RAG to ground responses; evaluate model quality |
The recurring theme is matching a technique to a requirement. Almost every Domain 3 question is really asking: given these constraints, what’s the right approach? Get comfortable with the trade-offs and you’ll answer most of them without memorizing anything.
Selecting a Foundation Model
Before you can apply a model, you have to pick one. Amazon Bedrock gives you a menu of foundation models from multiple providers (Amazon Nova/Titan, Anthropic Claude, Meta Llama, Mistral, Cohere, AI21, Stability AI for images, and more). The exam expects you to reason about selection using a handful of criteria.
The Model Selection Criteria
- Modality — Text, chat, image generation, embeddings, or multimodal? Match the model to the input/output type. Embeddings models (e.g., Titan Embeddings) turn text into vectors for RAG; image models (e.g., Stability) generate pictures.
- Context window — How much text can the model consider at once? Long documents or large RAG contexts need a bigger context window.
- Latency & throughput — Real-time chat needs a fast, often smaller model; batch summarization can tolerate a larger, slower one.
- Cost — Larger models cost more per token. Match capability to the task; don’t pay for a frontier model to do simple classification.
- Accuracy / capability — Complex reasoning may justify a bigger model; routine extraction may not.
- Customization support — Does the model support fine-tuning if you’ll need it later?
- Language & domain coverage — Some models handle multilingual or specialized content better.
Exam heuristic: When a question stresses low cost and high volume for a simple task, pick a smaller model. When it stresses complex reasoning or long documents, pick a larger model or one with a bigger context window. When it stresses up-to-date, company-specific facts, that’s a RAG signal, not a bigger-model signal.
Inference Parameters (Briefly)
Once you’ve chosen a model, inference parameters shape its output. You should recognize these:
- Temperature — Higher = more random/creative; lower = more deterministic/focused.
- Top-p (nucleus sampling) and Top-k — Alternative ways to control randomness by limiting the token pool.
- Max tokens / response length — Caps output length (and cost).
- Stop sequences — Tell the model where to stop.
For a full treatment of these and prompting techniques, see the prompt engineering guide. For Domain 3, just know what each parameter does and when to adjust it (e.g., lower temperature for factual extraction, higher for brainstorming).
The Central Decision: Prompt Engineering vs. RAG vs. Fine-Tuning
This is the most tested concept in Domain 3. AWS wants you to pick the least expensive, least complex technique that solves the problem. The three approaches form a ladder of effort:
| Approach | What it does | Cost / effort | Best when |
|---|---|---|---|
| Prompt engineering | Improves outputs by crafting better instructions/examples | Lowest | The base model already knows enough; you just need to steer it |
| RAG | Injects relevant external/company data into the prompt at query time | Medium | You need current, private, or domain-specific facts the model wasn’t trained on |
| Fine-tuning | Retrains model weights on your labeled data | Highest | You need a consistent style/format/behavior, or specialized task performance |
How to Reason About It
- Start with prompt engineering. It’s free-ish, instant, and often enough. If the model gives wrong-format or vague answers, better prompts frequently fix it.
- Move to RAG when the problem is knowledge, not behavior — the model doesn’t know your product catalog, internal policies, or last quarter’s numbers. RAG supplies that knowledge without retraining, and it keeps answers current because you just update the data source.
- Reach for fine-tuning when the problem is behavior — you need the model to consistently adopt a tone, follow a rigid output format, or perform a narrow task better than prompting alone achieves.
Exam heuristic: “The model needs to answer using our internal documents / latest data” → RAG. “The model needs to consistently respond in our brand voice / specialized format” → fine-tuning. “The model gives okay answers but we want them better-structured” → prompt engineering first. A frequent distractor is choosing fine-tuning when RAG (or even a better prompt) would be cheaper and sufficient.
Retrieval-Augmented Generation (RAG), Explained
RAG is the technique AWS emphasizes most, because it solves two big foundation-model weaknesses — hallucination and stale/missing knowledge — without the cost of retraining.
How RAG Works, Step by Step
- Ingest & chunk — Your documents (PDFs, wikis, tickets) are split into chunks.
- Embed — Each chunk is converted into a numeric vector by an embeddings model (e.g., Amazon Titan Embeddings). Similar meanings produce nearby vectors.
- Store — Vectors go into a vector database / vector store (e.g., Amazon OpenSearch Serverless, Amazon Aurora with pgvector, and other supported stores).
- Retrieve — At query time, the user’s question is embedded, and the system finds the most similar chunks (semantic search).
- Augment & generate — Those retrieved chunks are inserted into the prompt as context, and the foundation model generates an answer grounded in them.
The key insight for the exam: RAG grounds the model in your data at inference time. Nothing about the model’s weights changes. Update the documents and the answers update too — no retraining.
RAG on AWS: Bedrock Knowledge Bases
Amazon Bedrock Knowledge Bases is the managed service that implements this pipeline for you. You point it at a data source (commonly an Amazon S3 bucket), it handles chunking and embedding, stores vectors in a supported vector store, and exposes retrieval that Bedrock models use automatically. You should associate these facts with RAG on AWS:
- Amazon Bedrock Knowledge Bases = managed RAG.
- Embeddings model (e.g., Titan Embeddings) = turns text into vectors.
- Vector store (e.g., OpenSearch Serverless, Aurora/pgvector) = stores and searches vectors.
- Retrieval + generation = the model answers using retrieved context, reducing hallucination.
Why RAG Matters for the Exam
RAG appears constantly as the right answer to scenarios involving: a chatbot that must cite internal policies, a support assistant that needs current product info, or any “the model is making things up / doesn’t know our data” problem. If you learn one Domain 3 technique cold, make it RAG.
Customization: Fine-Tuning and Continued Pre-Training
When prompting and RAG aren’t enough, you customize the model itself. AIF-C01 expects you to distinguish two customization methods available in Amazon Bedrock:
| Method | Data needed | What it changes | Use when |
|---|---|---|---|
| Fine-tuning | Labeled examples (prompt → ideal completion) | Adapts the model to a specific task/style | You have quality labeled data and need consistent, specialized behavior |
| Continued pre-training | Large amounts of unlabeled domain text | Deepens the model’s domain knowledge | You have lots of unlabeled industry data (e.g., legal, medical corpora) |
Both produce a custom model that you access through Provisioned Throughput in Bedrock. Key exam points:
- Fine-tuning needs labeled data; continued pre-training uses unlabeled data.
- Customization is more expensive and more effort than RAG or prompting — it’s the last resort, not the default.
- Fine-tuning changes behavior/style; RAG changes available knowledge. A scenario needing both current facts and a specific format might combine RAG with a fine-tuned model — but the exam usually tests them one at a time.
Related concepts you should recognize: transfer learning (adapting a pre-trained model to a new task is what fine-tuning leverages) and the trade-off that customization risks overfitting if your dataset is small or narrow.
Agents: Orchestrating Multi-Step Actions
The exam also touches on Amazon Bedrock Agents, which let a foundation model go beyond text generation to take actions — calling APIs, querying databases, and chaining steps to complete a task (e.g., “book the meeting and email the summary”). Agents can combine reasoning with Knowledge Bases (RAG) and action groups (API calls). For AIF-C01, understand agents at a conceptual level: they orchestrate multi-step workflows and tool use, extending what a bare model can do.
Evaluating Foundation Models
Applying a model is only half of Domain 3 — you also have to know whether it’s any good. AWS tests both automated metrics and human evaluation, plus the idea that different tasks need different metrics.
Automated Evaluation Metrics
| Metric | Measures | Typical use |
|---|---|---|
| ROUGE | Overlap of n-grams with a reference | Summarization quality |
| BLEU | Precision of n-gram matches to a reference | Translation quality |
| BERTScore | Semantic similarity using embeddings | Meaning-level similarity, beyond exact word overlap |
| Perplexity | How well a model predicts text | Language modeling fluency |
| F1 / accuracy | Correctness against labels | Classification tasks |
You don’t need to compute these by hand, but you should map metric → task: ROUGE for summarization, BLEU for translation, BERTScore for semantic similarity, accuracy/F1 for classification.
Human Evaluation
Automated metrics miss nuance — tone, helpfulness, safety, factual correctness in open-ended answers. Human evaluation (people rating outputs) is often the gold standard for generative quality, especially for subjective or high-stakes use cases. The exam may present a scenario where automated scores look fine but human review is warranted (e.g., a customer-facing assistant).
Amazon Bedrock Model Evaluation
Amazon Bedrock includes a Model Evaluation feature that supports both automatic evaluation (with built-in metrics and curated or custom datasets) and human evaluation workflows. It helps you compare models to choose the best fit for a use case — tying directly back to the model-selection skill at the top of this domain.
Business & Non-Technical Evaluation
Finally, AWS wants practitioners to evaluate models on business dimensions too: cost, latency, and alignment to the business goal. A model that scores highest on ROUGE but costs 10x and answers too slowly for a live chatbot may be the wrong choice. Match the evaluation to what the business actually needs.
Bringing Domain 3 Together: A Scenario Walkthrough
A company wants an internal assistant that answers employee questions using its constantly-changing HR policy documents, in a consistent, professional tone, at low cost.
Reason through it the way the exam wants:
- Knowledge problem? Yes — policies change and are private. → RAG with a Bedrock Knowledge Base over the policy docs in S3.
- Behavior problem? The “consistent professional tone” can likely be handled with prompt engineering (a good system prompt) — cheaper than fine-tuning. Only fine-tune if prompting proves insufficient.
- Model choice? A cost-efficient, moderate model with a context window large enough for retrieved chunks. Real-time chat → favor lower latency.
- Evaluation? Combine automated relevance checks with human evaluation for tone and correctness, plus cost/latency monitoring.
Notice we reached for the cheapest sufficient technique at each step — RAG over fine-tuning, prompting over customization. That instinct is what Domain 3 rewards.
How This Connects to the Rest of the Exam
Domain 3 doesn’t live in isolation. Grounding with RAG and evaluating outputs ties into Domain 4 (Responsible AI) — reducing hallucination and bias — and into Domain 5 (Security & Governance), where you protect the data feeding your RAG pipeline and audit model use. If you haven’t yet, review our security, compliance & governance guide for AIF-C01 to see how data protection wraps around the applications you build here.
Practice Domain 3 Under Real Exam Conditions
Domain 3 is 28% of AIF-C01 — the largest slice — and it’s scenario-heavy, so passive reading only gets you so far. The fastest way to internalize the “which technique fits this constraint?” instinct is to answer many scenario questions and read the explanations for the ones you miss.
The Sailor.sh AWS AI Practitioner Mock Exam Bundle gives you 8 full-length AIF-C01 mocks (520+ questions) with per-domain performance reporting, so you can see exactly how you’re scoring on Applications of Foundation Models and drill the weak spots. Every question includes a detailed explanation of why the right answer is right and why each distractor is wrong — which is how you build the RAG-vs-fine-tuning judgment the exam tests. Prefer to try before you commit? Start with the free AIF-C01 practice test to gauge your readiness.
For the authoritative source, keep the AWS Certified AI Practitioner exam guide and the Amazon Bedrock documentation handy as you study.
Frequently Asked Questions
How much of the AIF-C01 exam is Domain 3?
Domain 3, “Applications of Foundation Models,” is 28% of the exam — the largest domain, roughly 18 of 65 scored questions. It’s also the most technical, so it deserves proportional study time.
When should I choose RAG over fine-tuning on the exam?
Choose RAG when the problem is missing or changing knowledge — the model needs your internal, private, or up-to-date data. Choose fine-tuning when the problem is behavior — you need consistent tone, format, or specialized task performance. RAG is cheaper and keeps data current without retraining, so it’s the default answer for “the model doesn’t know our data.”
What is Amazon Bedrock Knowledge Bases?
It’s Amazon Bedrock’s managed RAG service. You point it at a data source (like an S3 bucket); it chunks and embeds your documents, stores the vectors in a supported vector store, and lets Bedrock models retrieve relevant context to ground their answers — reducing hallucination without any model retraining.
What’s the difference between fine-tuning and continued pre-training?
Fine-tuning uses labeled examples (prompt → ideal response) to adapt a model to a specific task or style. Continued pre-training uses large amounts of unlabeled domain text to deepen the model’s general knowledge of a domain. Both create a custom model accessed via Provisioned Throughput in Bedrock.
Which evaluation metric goes with which task?
Map them directly: ROUGE → summarization, BLEU → translation, BERTScore → semantic similarity, accuracy/F1 → classification, perplexity → language modeling fluency. For subjective or high-stakes outputs, add human evaluation. Amazon Bedrock’s Model Evaluation feature supports both automatic and human workflows.
Do I need to know how to code RAG for AIF-C01?
No. AIF-C01 is a foundational, non-coding exam. You need to understand RAG conceptually — what problem it solves, the ingest → embed → store → retrieve → generate flow, and that Bedrock Knowledge Bases manages it — not how to implement it in code.
Conclusion
Domain 3 is where the AWS AI Practitioner exam asks you to think like a builder: pick the right foundation model for the constraints, reach for the cheapest sufficient technique (prompt engineering before RAG before fine-tuning), ground responses in your own data with RAG and Bedrock Knowledge Bases, customize only when behavior demands it, and evaluate outputs with the metric that fits the task. Master those decision frameworks and the largest, most technical domain of AIF-C01 becomes its most predictable.
When you’re ready to pressure-test that judgment, work through full-length scenarios in the AWS AI Practitioner Mock Exam Bundle and let the per-domain reporting show you exactly where to focus next.