AWS AI Practitioner Exam Notes

Task Statement 3.1: Design Considerations for Applications That Use Foundation Models

This task statement focuses on choosing and using foundation models (FMs), controlling their responses, grounding them with enterprise data, customizing them, and enabling them to perform multi-step tasks.

1. Foundation Model Selection Criteria

A foundation model should not be selected solely because it is the largest or most accurate model. Selection should be based on the application’s requirements, constraints, and business goals.

A useful approach is to evaluate models based on:

Cost
Modality
Latency
Language support
Model size and complexity
Customization options
Input and output length
Prompt caching
Accuracy and task performance
Security, privacy, and compliance
Availability and licensing

1.1 Cost

FM-related costs can include:

Model training or customization
Inference requests
Input and output tokens
Storage
Data transfer
Vector database storage and queries
Provisioned capacity
Monitoring and maintenance

Key tradeoff

A larger or more capable model may produce better results, but it usually costs more to run and may have higher latency.

A smaller model may be:

Less expensive
Faster
Easier to deploy
Sufficient for simple tasks

However, it might provide lower-quality results for complex reasoning, multilingual tasks, or specialized domains.

Exam perspective

The best model is not necessarily the most accurate model. The correct model is the one that satisfies the required level of quality while meeting cost, latency, and operational constraints.

Example

A customer support chatbot may not need the largest available model. A smaller model could provide adequate answers at a lower cost and with faster response times.

A legal research or medical reasoning application may justify the higher cost of a larger model if accuracy is more important than latency or price.

1.2 Modality

A model’s modality describes the types of input and output it can process.

Common modalities include:

Text
Images
Audio
Video
Speech
Multimodal combinations, such as text plus images

Selection questions

Ask:

What type of data does the application receive?
What type of output is required?
Does the model support both the required input and output modalities?
Is a single multimodal model needed, or can multiple specialized models be combined?

Examples

Image classification requires an image-capable model.
Text summarization requires a text model.
Speech transcription requires an audio or speech model.
A virtual assistant that interprets images and responds with text requires a multimodal model.

Embeddings and modality

Different modalities generally require different embedding models.

For example:

Text embeddings represent semantic meaning in text.
Image embeddings represent visual features.
Audio embeddings represent characteristics of audio.

When using vector search, the query and stored data generally need to be embedded in a compatible vector space.

1.3 Latency and Inference Speed

Inference is the process of providing input to a trained model and receiving an output.

Latency is the time between sending a request and receiving a response.

Latency requirements depend on the application:

Real-time applications need low latency.
Batch processing can tolerate longer response times.
Interactive chat applications need acceptable time-to-first-token and overall response time.
Safety-critical applications may require deterministic and rapid decisions.

Factors that affect latency

Model size
Number of parameters
Input length
Requested output length
Hardware
Network connectivity
Number of concurrent requests
Provisioned versus on-demand capacity
Additional RAG retrieval steps
Agent orchestration and API calls

Larger models

Larger models often provide stronger capabilities, but may:

Take longer to respond
Cost more per request
Require more computational resources
Have lower throughput

Exam tip

When the question emphasizes real-time response, low latency, high throughput, or cost efficiency, consider a smaller or optimized model rather than automatically choosing the most capable model.

1.4 Multilingual Support

If an application serves users in multiple countries, verify that the FM supports:

The required languages
The required dialects
Translation between languages
Cultural and regional context
Appropriate language quality
Input and output language combinations

A model may technically support a language but perform poorly compared with its performance in English or other heavily represented languages.

Potential concerns

Uneven quality across languages
Bias in training data
Poor understanding of regional expressions
Incorrect translation of technical terms
Difficulty with low-resource languages

1.5 Model Size and Complexity

Model complexity can be associated with:

Number of parameters
Number of layers
Number of computational operations
Memory requirements
Architecture
Context-window size

A more complex model can often learn more sophisticated relationships, but it generally requires more resources.

Benefits of larger models

Better reasoning
Better language understanding
Stronger performance on complex tasks
Less need for extensive prompting or customization in some cases

Disadvantages

Higher inference cost
Higher latency
Greater infrastructure requirements
More difficult monitoring and maintenance
Less explainability
Potentially more difficult deployment

Important exam distinction

Model size is not the same as model quality for every task. A smaller, task-specific model may outperform a larger general-purpose model for a narrow use case.

1.6 Model Architecture

Different architectures have different strengths.

Examples include:

Convolutional neural networks, commonly used for image-related tasks
Recurrent neural networks, traditionally used for sequential data
Transformer-based models, widely used for language and multimodal applications
Encoder models, often used for representation and embedding tasks
Decoder or generative models, often used for text generation

For the AI Practitioner exam, focus primarily on matching the model’s capabilities to the use case rather than memorizing detailed architecture internals.

1.7 Performance Metrics

Models should be evaluated using metrics that match the business problem.

Common metrics include:

Accuracy
Precision
Recall
F1 score
Mean absolute error, or MAE
Root mean squared error, or RMSE
Mean average precision, or mAP

Classification metrics

Accuracy

The proportion of predictions that are correct.

Accuracy can be misleading when the dataset is imbalanced.

Example:

If 99% of transactions are legitimate, a model that always predicts “legitimate” achieves 99% accuracy but detects no fraud.

Precision

Of all items predicted as positive, how many were actually positive?

High precision is important when false positives are expensive.

Example:

Avoiding unnecessary fraud investigations
Avoiding incorrectly blocking legitimate customers

Recall

Of all actual positive cases, how many did the model identify?

High recall is important when missing a positive case is costly.

Example:

Detecting disease
Detecting security threats
Detecting fraudulent transactions

F1 score

The harmonic mean of precision and recall.

F1 is useful when both false positives and false negatives matter.

Regression metrics

MAE

The average absolute difference between predictions and actual values.

It is easier to interpret because it is expressed in the original unit.

RMSE

The square root of the average squared error.

RMSE penalizes large errors more strongly than MAE.

Object detection

Mean average precision, or mAP, is often more relevant than simple accuracy because object detection evaluates:

Whether objects were identified
Whether they were classified correctly
Whether their locations were predicted accurately

Exam trap

Do not assume accuracy is always the best metric. The appropriate metric depends on the data distribution and business consequences of errors.

1.8 Customization Options

Consider whether the model must be customized for:

Company-specific terminology
Specialized writing style
Unique business processes
Domain-specific knowledge
New labels or classes
Special output formats
Organization-specific behavior

Customization choices include:

Prompt engineering
In-context learning
RAG
Fine-tuning
Continued pre-training
Model distillation

These approaches differ significantly in cost, complexity, data requirements, and operational overhead.

1.9 Input and Output Length

Input and output length are important model selection criteria.

Input length

The input includes:

User instructions
Conversation history
Retrieved documents
Examples
System instructions
Embedded context

A model must support a sufficiently large context window for the application.

Output length

Applications may need:

Short answers
Long-form reports
Summaries
Code
Structured JSON
Multi-step explanations

Longer outputs usually increase:

Inference cost
Latency
Token usage
Risk of irrelevant or repetitive content

Exam tip

If an application needs to process large documents or long conversations, verify the model’s context window. If the application needs short, fast responses, avoid unnecessarily large output limits.

1.10 Prompt Caching

Prompt caching allows reusable parts of a prompt to be cached so they do not need to be fully processed repeatedly.

Potentially reusable content includes:

Long system instructions
Repeated policies
Product catalogs
Large reference documents
Common conversation context

Benefits

Lower latency
Lower cost for repeated prompt content
Better performance for applications with repeated context

Design considerations

Prompt caching is most useful when:

The same long prompt prefix is reused frequently
Many requests share common instructions or data
The model and service support caching for the use case

It is less useful when every request has completely different context.

Exam trap

Prompt caching is not the same as storing embeddings in a vector database. Prompt caching avoids repeatedly processing identical prompt content, while vector search retrieves semantically relevant information from a knowledge repository.

1.11 Bias, Explainability, and Compatibility

Before selecting a model, consider:

Bias in the training data
Known limitations
Safety behavior
Licensing
Documentation
Community and vendor support
Update and maintenance history
Framework compatibility
Deployment environment
Data privacy and compliance requirements

Interpretability versus explainability

Interpretability means the model’s internal decision process is inherently understandable.

Examples:

Linear regression coefficients
Decision tree rules

Explainability means using techniques to provide an approximation or explanation of a complex model’s behavior.

Foundation models are usually considered black boxes and are not inherently interpretable. Explainability tools attempt to explain their outputs, but they do not make the underlying model fully transparent.

Exam trap

Do not treat explainability and interpretability as identical:

Interpretability: the model is understandable by design.
Explainability: methods are used to explain a complex model’s behavior.

2. Inference Parameters and Their Effect on Responses

Inference parameters control the behavior of a foundation model when it generates a response.

Different models may support different parameter names and ranges. Always check the model-specific API documentation.

2.1 Temperature

Temperature controls the randomness of token selection.

Low temperature

Produces responses that are generally:

More deterministic
More consistent
More focused
Less creative

Useful for:

Classification
Information extraction
Structured output
Summarization
Answers requiring consistency

High temperature

Produces responses that are generally:

More varied
More creative
Less predictable
Potentially less factually consistent

Useful for:

Brainstorming
Creative writing
Generating alternative ideas

Exam trap

Higher temperature does not mean higher accuracy. It increases variation and creativity, but may also increase undesired or inconsistent output.

2.2 Top-K

Top-K limits the next-token choices to the K most likely tokens.

Lower Top-K: fewer choices, more focused output
Higher Top-K: more choices, greater diversity

Top-K works by restricting the candidate pool before token selection.

2.3 Top-P

Top-P, also called nucleus sampling, selects from the smallest group of tokens whose combined probability reaches a specified threshold.

Lower Top-P: more conservative output
Higher Top-P: more diverse output

Top-P dynamically changes the number of candidate tokens based on the probability distribution.

Top-K versus Top-P

Top-K uses a fixed number of candidate tokens.
Top-P uses a probability-based candidate set.

Exam tip

Temperature, Top-K, and Top-P are primarily used to influence randomness and diversity. They do not add factual knowledge to the model.

2.4 Maximum Output Length

This limits how many tokens the model can generate.

A lower output limit can:

Reduce cost
Reduce latency
Prevent overly long answers

A higher output limit may be necessary for:

Reports
Long summaries
Code generation
Detailed explanations

Important distinction

Maximum output length limits the generated response. It does not necessarily determine the model’s context-window capacity.

2.5 Input Length and Context

The input length determines how much information the model can process in one request.

If the prompt exceeds the model’s context window:

The request may fail
Content may need to be truncated
Relevant information may be lost
Cost and latency may increase

RAG systems must account for the size of retrieved documents when constructing the final prompt.

2.6 Stop Sequences

A stop sequence tells the model to stop generating when it reaches a specified string or token sequence.

Examples:

Stop after a newline
Stop after a closing JSON marker
Stop after a section delimiter

Stop sequences help control output format and avoid unnecessary generation.

2.7 Penalties

Some models support penalties that reduce repetition or influence token selection.

They may be useful for:

Reducing repeated phrases
Encouraging more varied wording
Preventing repetitive loops

Parameter availability and behavior can vary by model provider.

2.8 Tuning Parameters in Production

Inference parameters should be:

Tested with representative prompts
Evaluated against business metrics
Monitored in production
Adjusted as requirements change

A parameter setting that works for one task may be inappropriate for another.

Exam summary

Temperature: controls randomness
Top-K: controls number of likely token choices
Top-P: controls probability mass of token choices
Maximum output tokens: controls response length
Stop sequences: stop generation at specified text
Penalties: can reduce repetition or influence diversity

3. Retrieval-Augmented Generation, or RAG

3.1 Definition

Retrieval-Augmented Generation is a technique in which an application:

Retrieves relevant information from an external data source
Adds that information to the model prompt
Uses the foundation model to generate a response grounded in the retrieved information

RAG combines:

A retriever, which searches for relevant data
A generator, usually an FM or LLM, which creates the final response

3.2 Why Use RAG?

Foundation models are trained on data available during training. They may not know:

Current company policies
Private business information
Recent events
Internal product documentation
Customer-specific information
Frequently changing data

RAG allows the application to provide current and domain-specific information at inference time without retraining the FM.

Benefits

Uses private or proprietary data
Can provide more current information
Reduces the need for model retraining
Can improve factual grounding
Supports citations or source references
Allows knowledge to be updated independently of the FM

Important qualification

RAG can reduce hallucinations, but it does not eliminate them. Incorrect retrieval, incomplete documents, poor chunking, or incorrect interpretation can still produce inaccurate answers.

3.3 Typical RAG Workflow

Data ingestion phase

Collect documents from data sources.
Split documents into chunks.
Generate embeddings for each chunk using an embedding model.
Store the embeddings and original content or references in a vector database.
Index the data for similarity search.

Query phase

The user submits a question.
The question is converted into an embedding.
The vector database searches for similar embeddings.
Relevant documents or chunks are retrieved.
The retrieved content is added to the original prompt.
The FM generates a grounded response.

Conceptual flow

Documents
   ↓
Chunking
   ↓
Embedding model
   ↓
Vector database

User question
   ↓
Query embedding
   ↓
Similarity search
   ↓
Relevant context
   ↓
Prompt + context
   ↓
Foundation model response

3.4 Embeddings

An embedding is a numerical representation of data that captures semantic meaning and relationships.

Embeddings can represent:

Words
Sentences
Documents
Images
Audio
Other objects

Semantically similar items should have similar vectors in the embedding space.

Example

The questions:

“How do I reset my password?”
“I forgot my password. What should I do?”

may have different wording but similar embeddings.

A vector search can identify them as semantically related even if they do not contain exactly the same keywords.

3.5 Vector Databases

A vector database stores and searches vector embeddings.

It commonly provides:

Similarity search
Indexing
Metadata filtering
Data management
Authentication and authorization
Fault tolerance
Scalability
Query capabilities

Vector database versus ML model

These are different components:

An embedding model converts data into numerical vectors.
A vector database stores and searches those vectors.
A foundation model generates the final answer.

The embedding model is used to create the vector representation; the vector database does not itself create the embedding unless an integrated service performs that operation.

3.6 Amazon Bedrock Knowledge Bases

Knowledge Bases for Amazon Bedrock is a managed capability for implementing RAG.

It can:

Connect foundation models to enterprise data
Ingest and process data sources
Generate embeddings
Store and retrieve relevant information
Provide retrieved context to an FM
Support more relevant and context-aware responses

Knowledge Bases can reduce the amount of custom RAG infrastructure that an organization must build and maintain.

Business applications

Internal company question answering
Customer support
Product documentation search
Policy and compliance assistants
Employee help desks
Technical troubleshooting
Research assistants
Personalized recommendations
Content generation based on company data

4. AWS Services for Storing Embeddings

The exam may ask which AWS services can store or search embeddings.

Examples include:

Amazon OpenSearch Service

Supports:

Vector storage
Similarity search
Semantic search
Hybrid keyword and vector search
RAG applications
Recommendation engines
Dashboards and analytics

OpenSearch Serverless can provide vector search without requiring the customer to manage the underlying vector database infrastructure.

Exam association

Use OpenSearch when the question emphasizes:

Search
Semantic search
Low-latency retrieval
Search analytics
Vector search
RAG with search capabilities

Amazon Aurora

Aurora, particularly Aurora PostgreSQL-compatible deployments, can support vector storage and similarity search through PostgreSQL vector capabilities such as pgvector, depending on the configuration and service support.

Exam association

Consider Aurora when the organization already uses a relational database and wants to combine:

Relational data
SQL queries
Metadata
Vector similarity search

Amazon RDS for PostgreSQL

RDS for PostgreSQL can use the pgvector extension to:

Store embeddings
Perform vector similarity searches
Combine vector search with relational queries

Exam association

Use RDS for PostgreSQL when the application already relies on PostgreSQL or needs vector search alongside traditional relational data.

Amazon Neptune

Amazon Neptune can support graph-oriented applications and vector capabilities, depending on the Neptune feature and configuration being used.

It can be appropriate when the application needs to combine:

Relationships between entities
Knowledge graphs
Graph traversal
Semantic or vector-based retrieval

Amazon DocumentDB

Amazon DocumentDB with MongoDB compatibility can support vector search use cases in appropriate configurations.

It may be useful when application data is already stored as document-oriented data.

Redis-Compatible Services

Redis-compatible services can support vector search and are useful for:

Low-latency retrieval
Real-time recommendations
Semantic search
Similarity matching
Session and cache-oriented applications

Important exam point

A vector database is not the only component in a RAG system. A complete RAG architecture may require:

A source data repository
A document ingestion process
A chunking strategy
An embedding model
A vector store
A retriever
A foundation model
Prompt construction
Access control and monitoring

5. FM Customization Approaches and Cost Tradeoffs

Different customization approaches have different costs and levels of complexity.

5.1 In-Context Learning

In-context learning provides instructions and examples directly in the prompt without changing the model’s parameters.

It is often called few-shot prompting when examples are included.

Advantages

Fast to implement
No model training required
Low initial engineering effort
Easy to modify
Useful for formatting and simple behavior changes

Disadvantages

Prompt tokens increase inference cost
Long prompts increase latency
Limited by the context window
Behavior may be less consistent
Does not permanently change the model

Best use cases

Prototyping
Simple classification
Output formatting
Demonstrating desired behavior
Small numbers of examples

5.2 Retrieval-Augmented Generation

RAG adds external information to the prompt at inference time.

Advantages

No need to retrain the base FM for changing knowledge
Good for private and current information
Knowledge can be updated in the data store
More grounded answers
Often lower cost than model training

Disadvantages

Requires data ingestion and retrieval infrastructure
Adds retrieval latency
Requires document chunking and embedding
Results depend on retrieval quality
Retrieved content increases input-token cost
Access controls must be implemented correctly

Best use cases

Enterprise knowledge
Frequently changing information
Internal documentation
Customer support
Policy and compliance data

5.3 Fine-Tuning

Fine-tuning adapts a pre-trained FM using task-specific or domain-specific data.

It changes model parameters or uses a customization method supported by the service.

Advantages

Can improve performance for a specialized task
Can teach preferred style, terminology, or response format
May reduce the need for large prompts
Can provide more consistent behavior than prompting alone

Disadvantages

Requires high-quality training data
Has customization and training costs
Requires evaluation and testing
May require ongoing updates
Can introduce bias or overfitting
Does not automatically provide current factual knowledge

Important exam distinction

Fine-tuning is not the ideal solution for frequently changing factual information. RAG is generally more appropriate for dynamic enterprise knowledge.

5.4 Continued Pre-training or Additional Pre-training

Additional pre-training uses large amounts of domain data to further train the model.

Advantages

Can improve domain language understanding
Useful for specialized terminology and patterns
Can produce broad domain adaptation

Disadvantages

Very expensive
Requires substantial data and compute
Longer development cycle
More complex evaluation
Higher operational risk

This approach is generally more expensive than prompting, RAG, or fine-tuning.

5.5 Model Distillation

Model distillation transfers knowledge from a larger teacher model to a smaller student model.

Advantages

Smaller model may have lower inference cost
Lower latency
Reduced memory and compute requirements
Useful for high-volume or edge deployments

Disadvantages

Student model may lose some capabilities
Requires training and evaluation
May not preserve all reasoning performance
Additional engineering effort is required

Best use cases

Cost-sensitive, high-volume inference
Low-latency applications
Deployment to resource-constrained environments

5.6 Relative Cost and Complexity

A general ordering is:

Prompting / in-context learning
        ↓
RAG
        ↓
Fine-tuning
        ↓
Model distillation
        ↓
Additional pre-training

This is not an absolute price ranking for every implementation, but it is a useful exam-level comparison.

Simplified comparison

Approach	Changes model?	Uses external data at inference?	Relative effort	Best for
In-context learning	No	Only if included in prompt	Low	Instructions and examples
RAG	No	Yes	Medium	Current or private knowledge
Fine-tuning	Yes or adapts parameters	Not necessarily	Medium/High	Specialized behavior
Distillation	Creates smaller model	Not necessarily	High	Lower latency and cost
Pre-training	Yes, extensively	No	Very high	Broad domain adaptation

Exam traps

RAG does not retrain the FM.
Fine-tuning does not automatically make the model aware of current data.
In-context learning does not permanently modify the model.
Larger models are not always the most cost-effective.
Distillation is used to create a smaller model, not to add a knowledge base.
Use the least expensive method that satisfies the requirements.

6. AI Agents

6.1 Definition

An AI agent is software that uses a foundation model to reason about a user request, plan steps, interact with external systems, and complete actions.

An FM by itself generally generates text. It does not automatically:

Book a flight
Process a purchase order
Update a customer record
Query a private database
Call an enterprise API
Complete a transaction

An agent provides orchestration around the FM and connects it to tools, data, and business workflows.

6.2 Agent Components

An agent commonly includes:

A foundation model
Instructions
A planning or orchestration process
Knowledge bases or external data sources
Action groups
APIs or Lambda functions
Session and conversation state
Permissions and security controls

Typical operation

Receive the user request.
Interpret the intent.
Break the request into steps.
Retrieve relevant information if required.
Decide which action or API to call.
Call the external system.
Use the result to continue reasoning.
Return a response to the user.

6.3 Agents for Amazon Bedrock

Agents for Amazon Bedrock is a managed AWS capability for building generative AI applications that can:

Orchestrate multi-step tasks
Use foundation models
Invoke APIs
Use action groups
Query Knowledge Bases
Access organization-specific data
Generate responses based on action results

Agents can connect the FM to business workflows without requiring all orchestration logic to be manually written.

Action groups

Action groups define actions the agent can perform, commonly through:

APIs
AWS Lambda functions
Existing business services

For example, an action group might allow an agent to:

Check flight availability
Create a reservation
Retrieve an order status
Submit a purchase order
Update a customer account

6.4 Agent Business Applications

Examples include:

Travel booking assistants
Customer service agents
Order management
IT service desk automation
Claims processing
Financial workflow assistance
Employee HR assistants
Appointment scheduling
Inventory management
Business process automation

RAG versus agents

These serve different purposes:

RAG retrieves information to improve an answer.
Agents use reasoning and orchestration to complete tasks, often by calling tools and APIs.

An agent may use RAG as one of its capabilities.

Example

A customer asks:

“Find a replacement product, check inventory, and place the order.”

RAG can retrieve product information and policies.
An agent can retrieve the information, check inventory through an API, ask for confirmation, and submit the order.

6.5 Agent Security Considerations

Agents can take actions in external systems, so design must include:

Least-privilege IAM permissions
Authentication and authorization
Input validation
API safeguards
Human approval for high-impact actions
Logging and monitoring
Protection against prompt injection
Protection of sensitive information
Transaction limits and rollback procedures

Exam trap

An agent should not be assumed to have unrestricted access. Secure agents require controlled permissions and carefully defined actions.

7. Key Exam Tips and Traps

Model selection

Do not always select the largest model.
Balance quality, cost, latency, throughput, and operational complexity.
Match modality to the application input and output.
Verify multilingual support rather than assuming it.
Check the model’s context window and maximum output length.
A model with slightly lower accuracy may be the correct choice if it is much cheaper and meets requirements.
More parameters generally mean greater capability, but also more cost and latency.

Inference parameters

Temperature controls randomness.
Top-K limits the number of candidate tokens.
Top-P limits candidates by cumulative probability.
Maximum tokens control response length.
Stop sequences terminate generation at defined markers.
Higher temperature does not improve factual accuracy.
Inference parameters modify response behavior; they do not add new knowledge.

RAG

RAG retrieves external information and includes it in the prompt.
RAG does not retrain or modify the FM.
RAG is well suited for private, current, or frequently changing information.
A vector database stores embeddings and supports similarity search.
An embedding model creates embeddings; the vector database stores and searches them.
RAG can reduce hallucinations but cannot guarantee that every response is correct.
Knowledge Bases for Amazon Bedrock provides managed support for RAG workflows.

Customization

In-context learning is quick and does not change model weights.
Fine-tuning changes or adapts the model for specialized behavior.
RAG is usually preferable to fine-tuning for changing factual knowledge.
Pre-training or continued pre-training is the most resource-intensive approach.
Distillation creates a smaller, less expensive, lower-latency student model.
Always choose the simplest and least expensive approach that meets the requirement.

Agents

An FM generates content; an agent orchestrates actions.
Agents can call APIs, invoke Lambda functions, and use Knowledge Bases.
Agents are appropriate for multi-step workflows and real-world actions.
RAG answers questions using retrieved information; agents can perform tasks.
Agents require strong security controls because they can affect external systems.

8. Quick Review Table

Concept	Main purpose
Foundation model	General-purpose model trained on broad data
Inference	Generate an output from a model input
Temperature	Control response randomness
Top-K	Limit candidates to the K most likely tokens
Top-P	Select tokens within a cumulative probability threshold
Context window	Maximum input context the model can process
Embedding	Numerical representation of semantic meaning
Vector database	Store and search embeddings
RAG	Retrieve external data and add it to the prompt
Knowledge Bases for Amazon Bedrock	Managed RAG capability
Fine-tuning	Adapt a model to specialized behavior
In-context learning	Guide a model using instructions and examples in the prompt
Distillation	Create a smaller model from a larger teacher model
AI agent	Orchestrate a model, tools, data, and APIs to complete tasks
Agents for Amazon Bedrock	Managed service for building FM-powered agents

9. Likely Exam Scenarios

Scenario 1: Current internal policies

A company wants an assistant to answer questions using frequently changing internal policies.

Best fit: RAG using Knowledge Bases for Amazon Bedrock.

Why: The information changes frequently and should be retrieved from an external data source instead of retraining the model.

Scenario 2: Consistent output format

A company wants every response returned as a specific JSON structure.

Possible approaches: Prompt engineering, in-context examples, stop sequences, and low-temperature inference.

Why: The requirement concerns response behavior and formatting, not necessarily new factual knowledge.

Scenario 3: Specialized terminology and style

A company wants the model to consistently write using a specific domain vocabulary and style.

Possible fit: Fine-tuning, potentially combined with RAG.

Why: Fine-tuning can teach specialized behavior, while RAG can provide current factual information.

Scenario 4: Low-cost, high-volume application

A company needs millions of simple predictions with low latency.

Possible fit: A smaller model or distilled model.

Why: Inference cost and latency are more important than maximum model capability.

Scenario 5: Booking and transaction workflow

A company wants a conversational assistant that checks availability, obtains a customer’s confirmation, and completes a booking.

Best fit: An AI agent with action groups and APIs.

Why: The application must orchestrate multiple steps and perform real-world actions.

Scenario 6: Imbalanced fraud dataset

A fraud detection model is evaluated using accuracy and achieves 99%.

Potential issue: Accuracy may be misleading because fraudulent transactions are rare.

Better metrics: Precision, recall, and F1 score, depending on the cost of false positives and false negatives.