AIF-C01 Domain 2: Fundamentals of Generative AI
Part 3 of 6 in the AIF-C01 exam prep series for developers. Previous: Domain 1: Fundamentals of AI and ML.
Domain 2 is where the exam checks that you understand how generative AI actually works, and what it costs. As a developer you've probably used an LLM API. This domain asks you to explain what happens underneath: tokens, embeddings, the model lifecycle, and why the bill looks the way it does. It also covers where generative AI is the wrong tool and which AWS service fits which kind of builder.
Domain at a glance#
Domain 2 is 24% of scored content, about 12 of the 50 scored questions.
| Task | What it covers |
|---|---|
| 2.1 | Explain the basic concepts of generative AI |
| 2.2 | Understand the capabilities and limitations of GenAI for business problems |
| 2.3 | Describe AWS infrastructure and technologies for building GenAI applications |
Objective checklist#
| # | Objective | Section |
|---|---|---|
| 2.1.1 | Tokens, chunking, embeddings, vectors, prompt engineering, transformers, LLMs, FMs, multimodal and diffusion models | Core concepts |
| 2.1.2 | GenAI use cases | Use cases |
| 2.1.3 | The foundation model lifecycle | The foundation model lifecycle |
| 2.1.4 | Token-based pricing and its effect on cost and performance | Token-based pricing |
| 2.1.5 | The role of context engineering | One-liner below; full coverage in Post 5 |
| 2.1.6 | Agentic AI concepts: multi-agent patterns, MCP, memory, tools, orchestration | One-liner below; full coverage in Post 5 |
| 2.2.1 | Advantages of GenAI | Advantages and disadvantages |
| 2.2.2 | Disadvantages of GenAI | Advantages and disadvantages |
| 2.2.3 | Factors for selecting a GenAI model | Choosing a model |
| 2.2.4 | Business value and metrics | Business value and metrics |
| 2.3.1 | AWS services to develop GenAI applications | AWS services for building GenAI |
| 2.3.2 | Advantages of AWS GenAI services | Why build on AWS |
| 2.3.3 | Benefits of AWS infrastructure for GenAI | Why build on AWS |
| 2.3.4 | Cost trade-offs of AWS GenAI services | Cost trade-offs |
Basic concepts of generative AI#
Core concepts#
| Concept | What it is | Why it matters |
|---|---|---|
| Token | The unit a model reads and writes: a word, part of a word, or punctuation. In English, roughly ¾ of a word | Context limits and pricing are both measured in tokens |
| Chunking | Splitting long documents into smaller pieces before embedding them | Chunk size and overlap decide what RAG can retrieve. Too small loses context; too large dilutes relevance |
| Embedding | A list of numbers (a vector) that represents the meaning of text, an image, or audio | Similar meanings produce nearby vectors, which enables semantic search |
| Vector | The numeric array an embedding produces; its length is its dimensionality | Stored in vector databases and compared by similarity, often cosine similarity |
| Prompt engineering | Designing the input to get better output | Covered in Post 4 |
| Transformer | The neural network architecture behind modern LLMs. Self-attention lets it weigh every token against every other token, in parallel | Why LLMs handle long-range context well |
| Large language model (LLM) | A transformer trained on massive text to predict the next token | The engine of chat, summarization, and code generation |
| Foundation model (FM) | A large model pre-trained on broad data and adaptable to many tasks | LLMs are one kind; FMs can also handle images, audio, and video |
| Multimodal model | Accepts or produces more than one data type, such as text and images | Answering questions about a photo, or generating an image from text |
| Diffusion model | Generates images by learning to reverse a noising process, turning random noise step by step into an image | The architecture behind most modern image generators |
Figure: Documents and questions pass through the same embedding model, so their vectors are comparable. This is the retrieval half of RAG.
Use cases#
The guide's examples of what generative AI does well:
- Content generation: image, video, and audio generation.
- Text work: summarization, translation, and code generation.
- Conversation: AI assistants and customer service agents.
- Retrieval: search and recommendation engines.
What they share: open-ended inputs, outputs that are created rather than looked up, and tolerance for some variation in the answer.
The foundation model lifecycle#
Figure: The foundation model lifecycle, a likely ordering question. Feedback from production drives the next round of data and tuning.
| Stage | What happens |
|---|---|
| Data selection | Gather and curate large, diverse, high-quality training data |
| Model selection | Choose an architecture, or an existing model to build on |
| Pre-training | Self-supervised training on massive unlabeled data; the expensive part |
| Fine-tuning | Adapt the model to specific tasks with smaller, often labeled datasets |
| Evaluation | Measure quality, safety, and bias against benchmarks and human review |
| Deployment | Serve the model through an API or endpoint |
| Feedback | Collect user feedback and monitoring data to improve the next iteration |
Most builders never pre-train. They pick a pre-trained model and start at fine-tuning or, more often, just at deployment with good prompts.
Token-based pricing#
Objective 2.1.4 is new, and it covers cost and performance together.
How pricing works:
- Foundation model APIs charge per token.
- Input and output tokens are priced separately.
- Output tokens usually cost several times more than input tokens.
Here is the number of tokens and is the price per million tokens.
Worked example (illustrative prices). A support chatbot uses a model priced at 3.00 USD per million input tokens and 15.00 USD per million output tokens. Each request sends 1,500 input tokens, of which 1,200 are the same system prompt every time, and receives 300 output tokens. It handles 100,000 requests a day.
Now turn on prompt caching for the 1,200-token system prompt, with cached reads billed at about 10% of the normal input price.
Input cost drops from 450 to about 126 USD a day, ignoring small cache-write charges. Nothing about the application changed except that the repeated prefix is no longer reprocessed.
How tokens affect performance:
- Longer input means higher latency. The model must process the whole prompt before producing the first token.
- Longer output means a longer response time, because output is generated one token at a time.
- Prompt caching also cuts latency, not just cost, because the cached prefix isn't reprocessed.
Amazon Bedrock's inference options all trade cost against speed and guarantees:
| Option | Price vs. Standard | Best for |
|---|---|---|
| Standard (on-demand) | Baseline, pay per token | Most synchronous traffic |
| Priority | About 75% more | Latency-critical, customer-facing paths |
| Flex | About 50% less | Work that tolerates slower, variable response times |
| Batch | About 50% less; asynchronous through S3 | Offline bulk jobs: classification, summarization, evaluation |
| Reserved | Fixed price for reserved tokens per minute | Predictable, mission-critical traffic |
| Provisioned Throughput | Hourly charge for dedicated capacity | Guaranteed throughput and hosting custom models |
Beyond these options, three levers change the size of the bill:
- Prompt caching: cached reads are up to about 90% cheaper, and cached prefixes cut latency. It requires a stable prefix.
- Intelligent Prompt Routing: sends each request to the cheapest model in a family that can handle it.
- Model distillation: trains a small model to imitate a large one for a narrow task. Covered in Post 4.
Context engineering and agentic concepts#
- Context engineering (2.1.5) is deciding what goes into the model's context window at each step: instructions, retrieved documents, conversation history, tool definitions, and memory. It's the cost math above applied to accuracy. More tokens cost more, add latency, and eventually make answers worse.
- Agentic AI concepts (2.1.6) are how agents use tools, memory, MCP, and multi-agent patterns to complete multi-step tasks.
Capabilities and limitations#
Advantages and disadvantages#
| Advantages (2.2.1) | Disadvantages (2.2.2) |
|---|---|
| Adaptability: one model handles many tasks | Hallucinations: confident, fluent, false output |
| Responsiveness: answers in seconds | Interpretability: hard to explain why it said what it said |
| Conversational capability: natural-language interaction | Inaccuracy: errors, outdated knowledge from a training cutoff |
| Content generation: text, images, code, audio | Nondeterminism: the same prompt can produce different outputs |
| Simplicity: capabilities without training your own model | Also: bias from training data, cost at scale, latency for long outputs |
Nondeterminism comes from sampling. The model picks each next token from a probability distribution, and parameters like temperature control how much randomness is allowed. Lowering temperature makes answers more consistent, but it doesn't make them correct.
Choosing a model#
| Factor | Question to ask |
|---|---|
| Model type and modality | Text only, or images, audio, video? Generate or understand? |
| Performance requirements | How accurate does it need to be for this task? |
| Capabilities | Reasoning, code, tool use, languages supported? |
| Constraints | Context window size, data residency, availability in your Region |
| Compliance | Licensing, regulatory requirements, data handling |
| Cost | Price per token at your expected volume |
| Latency | Does a user wait for the answer? |
| Model complexity and size | Bigger models are more capable, slower, and more expensive; is a smaller one good enough? |
The right model is the smallest, cheapest one that meets the requirement, not the best-scoring one on a leaderboard.
Business value and metrics#
| Metric | What it measures |
|---|---|
| Return on investment (ROI) | Value delivered relative to total cost |
| Efficiency | Time or effort saved per task |
| Conversion rate | Share of users who complete a desired action, such as a purchase |
| Average revenue per user (ARPU) | Revenue divided by active users |
| Customer lifetime value (CLV) | Total revenue expected from a customer over the relationship |
| Accuracy | Share of outputs that are correct |
| Cross-domain performance | How well the model performs across different tasks or domains |
AWS infrastructure and technologies#
AWS services for building GenAI#
| Service | What it is | Who it's for |
|---|---|---|
| Amazon Bedrock | Serverless API access to foundation models from Amazon and third parties, plus Knowledge Bases, Guardrails, Model Evaluation, Prompt Management, Flows, and customization | Developers building GenAI apps without managing infrastructure |
| Amazon SageMaker AI | Full platform to build, train, tune, and deploy your own models | ML teams that need full control |
| SageMaker JumpStart | Hub of pre-trained open-source and proprietary models that you deploy or fine-tune on your own SageMaker endpoints | Teams wanting a specific open model on infrastructure they control |
| Amazon Quick | Agentic workspace for business users: BI, research, and no-code automation over company data | Analysts and business teams |
| Kiro | Agentic, spec-driven IDE | Developers writing and maintaining code |
| Strands Agents | Open-source SDK for building agents in code | Developers building agents |
| Amazon Bedrock AgentCore | Managed platform for running agents securely in production | Teams deploying agents at scale |
Bedrock, JumpStart, and SageMaker AI sit on a control-versus-convenience spectrum:
| Amazon Bedrock | SageMaker JumpStart | SageMaker AI (custom) | |
|---|---|---|---|
| Infrastructure | None to manage | Endpoints in your account | Everything in your account |
| Models | Curated catalog through one API | Hub of pre-trained models | Anything you build |
| Pricing | Per token or per request | Per instance-hour | Per instance-hour |
| Control | Least | More | Most |
| Effort | Least | Moderate | Most |
Amazon Nova is Amazon's own family of foundation models on Bedrock, and it's on the in-scope list. Exam questions typically use the original names:
| Model | Role |
|---|---|
| Nova Micro | Text only; lowest latency and cost |
| Nova Lite | Low-cost multimodal (text, image, video input) |
| Nova Pro | Balanced capability and cost |
| Nova Premier | Most capable; useful as a teacher for distillation |
| Nova Canvas / Nova Reel | Image generation / video generation |
| Nova Sonic | Speech-to-speech conversation |
Amazon has since introduced the Nova 2 generation (such as Nova 2 Lite and Nova 2 Sonic), plus Nova Act for browser-automation agents and Nova Forge for building custom Nova model variants. Know the roles above; check current model availability before building anything real.
Why build on AWS#
Advantages of AWS GenAI services (2.3.2):
- Accessibility: many models through one API.
- Lower barrier to entry: no ML expertise needed to start.
- Efficiency: managed infrastructure and scaling.
- Cost-effectiveness: pay per use, plus caching, batch, and distillation to cut costs.
- Speed to market.
- Ability to meet business objectives, with built-in evaluation and guardrails.
Benefits of AWS infrastructure (2.3.3):
| Benefit | What it means |
|---|---|
| Security | Encryption in transit and at rest, IAM access control, private connectivity with PrivateLink. Bedrock doesn't use your prompts and outputs to train its base models or share them with model providers |
| Compliance | Services covered by AWS compliance programs, with reports available in AWS Artifact |
| Shared responsibility | AWS secures the infrastructure; you secure your data, access, and application |
| Safety | Built-in controls such as Bedrock Guardrails |
AWS also builds its own ML chips: AWS Trainium for training and AWS Inferentia for inference. Both offer lower cost and better energy efficiency than general-purpose GPUs for supported workloads. They're useful as a distractor-eliminator and for the sustainability questions in Domain 4.
Cost trade-offs#
| Trade-off (2.3.4) | What to weigh |
|---|---|
| Responsiveness | Faster responses cost more (Priority tier, bigger instances) |
| Availability and redundancy | Cross-Region inference spreads traffic across Regions for throughput and resilience |
| Performance | Larger models perform better on hard tasks but cost more per token |
| Regional coverage | Not every model is available in every Region; data residency may limit your choices |
| Token-based pricing | Great for spiky or low volume; can get expensive at sustained high volume |
| Provisioned throughput | Predictable capacity and cost, but you pay whether you use it or not |
| Custom models | Training costs plus dedicated hosting; only worth it when prompting and RAG aren't enough |
Service cheat sheet#
| Service or feature | One line |
|---|---|
| Amazon Bedrock | Serverless foundation models through one API |
| Bedrock batch inference | About 50% cheaper asynchronous bulk processing |
| Bedrock prompt caching | Reuses a repeated prompt prefix; cheaper and faster |
| Bedrock Intelligent Prompt Routing | Routes each request to the cheapest capable model in a family |
| Bedrock Provisioned Throughput | Dedicated model capacity billed hourly |
| SageMaker AI | Build, train, and deploy your own models |
| SageMaker JumpStart | Pre-trained model hub deployed on your SageMaker endpoints |
| Amazon Nova | Amazon's foundation model family on Bedrock |
| AWS Trainium / AWS Inferentia | AWS chips for cost-efficient training / inference |
Commonly confused#
| If the scenario says… | Answer | Not… | Because |
|---|---|---|---|
| Find documents with similar meaning | Embeddings and vector search | Tokens | Tokens count text; embeddings encode meaning |
| Split a 300-page manual before indexing | Chunking | Tokenization | Chunking splits documents; tokenization splits text into model units |
| Generate images from text | Diffusion model | Transformer LLM | Diffusion models denoise toward an image |
| Same 3,000-token system prompt on every call | Prompt caching | Batch inference | The problem is repetition, not timing |
| Classify 2 million reviews overnight | Batch inference | Provisioned Throughput | Offline and asynchronous; about 50% cheaper |
| Traffic mixes trivial and hard questions | Intelligent Prompt Routing | A bigger model | Route easy requests to a cheaper model |
| Deploy an open-source model on infrastructure you control | SageMaker JumpStart | Amazon Bedrock | Bedrock is serverless; JumpStart gives you your own endpoint |
| Same question, different answer each time | Nondeterminism | Hallucination | Consistency problem, not a truth problem |
| Business users want AI over company data without code | Amazon Quick | Kiro | Kiro is for developers |
Practice questions#
Q1 (ordering). Put the stages of the foundation model lifecycle in order.
- A. Deployment
- B. Pre-training
- C. Data selection
- D. Evaluation
- E. Fine-tuning
Show answer
C → B → E → D → A.
Select the data, pre-train on it, fine-tune for the task, evaluate, then deploy. Model selection, between data selection and pre-training, and feedback, after deployment, complete the full lifecycle.
Q2. A company's Bedrock-based assistant sends the same 3,000-token system prompt with every request. Costs are high and responses feel slow. What is the most effective change?
- A. Switch to batch inference
- B. Enable prompt caching for the system prompt
- C. Fine-tune the model so it no longer needs the system prompt
- D. Purchase Provisioned Throughput
Show answer
Answer: B. Prompt caching reuses the repeated prefix. Cached reads are much cheaper and cut time to first token.
- A is for offline jobs, not an interactive assistant.
- C adds training and hosting cost and removes flexibility.
- D buys capacity but doesn't stop reprocessing the same tokens.
Q3. An e-commerce company wants to categorize 2 million product reviews with a foundation model. Results are needed by the next morning, and cost is the main concern. Which option fits best?
- A. Bedrock on-demand calls from a Lambda function
- B. Bedrock batch inference
- C. Bedrock Priority tier
- D. A SageMaker AI real-time endpoint
Show answer
Answer: B. Batch inference processes large offline jobs asynchronously at about half the on-demand price.
- A works but costs more.
- C costs more in exchange for lower latency.
- D keeps an endpoint running for something that doesn't need real-time responses.
Q4 (matching). Match each concept to its description.
| Concept | |
|---|---|
| 1. Token | |
| 2. Embedding | |
| 3. Chunking | |
| 4. Diffusion model |
Descriptions:
- A. A numeric vector that captures the meaning of content
- B. Splitting documents into smaller pieces for retrieval
- C. The basic unit of text a model reads and generates
- D. A model that generates images by progressively removing noise
Show answer
1 → C, 2 → A, 3 → B, 4 → D.
Q5 (multiple response). Which TWO are recognized disadvantages of generative AI?
- A. Hallucinations
- B. Inability to process natural language
- C. Nondeterministic outputs
- D. Requirement to label all input data
- E. Inability to generate images
Show answer
Answer: A and C.
- B and E are the opposite of what GenAI does.
- D confuses GenAI with supervised learning; foundation models are pre-trained on unlabeled data.
Q6. A data science team wants to run a specific open-source LLM on infrastructure they control, with the ability to fine-tune it and choose instance types. Which service fits best?
- A. Amazon Bedrock
- B. Amazon SageMaker JumpStart
- C. Amazon Quick
- D. Amazon Comprehend
Show answer
Answer: B. JumpStart deploys pre-trained models, including open-source ones, to SageMaker endpoints in your account, with control over instances and fine-tuning.
- A is serverless, with no infrastructure control.
- C is a business-user workspace.
- D is a pre-trained NLP service.
Q7. A CFO asks whether a GenAI customer-support assistant has been worth the investment. Which metric best answers the question?
- A. BLEU score
- B. Return on investment (ROI)
- C. F1 score
- D. Token throughput
Show answer
Answer: B. The stakeholder wants business value.
- A and C measure model quality.
- D is an operational metric.
Q8. Users report that a Bedrock-based assistant gives noticeably different answers when they ask the same factual question twice. The answers are all correct but worded and structured differently, which confuses them. What should the team adjust first?
- A. Lower the temperature
- B. Add a knowledge base
- C. Fine-tune the model
- D. Increase maximum output tokens
Show answer
Answer: A. This is nondeterminism, not hallucination. Lower temperature makes token selection more deterministic and responses more consistent.
- B addresses factual grounding, which isn't the problem here.
- C is expensive and unnecessary.
- D only allows longer answers.
Key takeaways#
- Tokens count; embeddings mean. Chunking decides what retrieval can find.
- Know the lifecycle order: data selection → model selection → pre-training → fine-tuning → evaluation → deployment → feedback.
- Input and output tokens are priced separately, and output costs more. Longer inputs increase latency.
- Match the cost lever to the problem:
- Repeated prompt → prompt caching.
- Offline bulk work → batch or Flex.
- Mixed difficulty → Intelligent Prompt Routing.
- Guaranteed capacity → Provisioned Throughput or Reserved.
- Hallucination is a truth problem; nondeterminism is a consistency problem. Different fixes.
- Bedrock → JumpStart → SageMaker AI trades convenience for control.
- Match the persona to the service. Business users → Quick. Developers writing code → Kiro. Agent builders → Strands and AgentCore.
Next: Domain 3: Applications of Foundation Models.
Sources#
Originally published at https://iuriio.com/blog/posts/2026/09/aif-c01-part-3-gen-ai-fundamentals
