AWS Learning Material Certification Cheatsheets
AIP-C01 Domain 1

Task 1.2: Select and configure FMs

Foundation Model Integration, Data Management, and Compliance · 4,326 words · source: Certified-Generative-AI-Developer-Professional-AIP-C01/domain-1/task-1-2-cheat-sheet.md

Domain 1: Foundation Model Integration, Data Management, and Compliance

Task Statement 1.2: Select and configure FMs

Domain 1 is 31% of scored exam content. Task 1.2 focuses on choosing the right foundation model (FM), configuring model access so applications can switch models without code changes, designing resilience for inference disruptions, and managing customized model deployment over time.

Use this sheet for scenario questions that ask which FM is best, how to compare models, how to route requests dynamically, how to survive Region or model availability issues, or how to deploy and roll back fine-tuned/domain-specific models.

Official Study Path

Use these in order:

  1. AWS Skill Builder: Exam Prep Plan: AWS Certified Generative AI Developer - Professional (AIP-C01)
  2. AWS Skill Builder: Domain 1 Review: AWS Certified Generative AI Developer - Professional
  3. AWS Skill Builder: Domain 1 Task 1.2 review and practice questions
  4. AWS Exam Guide: Domain 1, Task Statement 1.2
  5. AWS Docs: Amazon Bedrock model evaluation, Intelligent Prompt Routing, cross-Region inference, custom models, Amazon SageMaker JumpStart, and SageMaker Model Registry

Exam Objective Map

You should be able to:

Official skill What to know for the exam
Skill 1.2.1: Assess and choose FMs Compare model capability, benchmark results, ground-truth evaluation, latency, cost, context window, modalities, safety behavior, regional availability, quota, and limits
Skill 1.2.2: Create flexible architecture patterns Use configuration-driven routing with API Gateway, Lambda, AWS AppConfig, Amazon Bedrock Converse API, prompt routers, and abstraction layers so model/provider changes do not require application code changes
Skill 1.2.3: Design resilient AI systems Use retries, circuit breakers, Step Functions, graceful degradation, fallback models, queues, and Amazon Bedrock cross-Region inference/inference profiles to preserve service during disruptions
Skill 1.2.4: Implement FM customization deployment and lifecycle management Choose RAG, prompt engineering, Bedrock customization, or SageMaker AI fine-tuning; register model versions, automate deployment, monitor quality, roll back failed versions, and retire old models

One-Minute Mental Model

Task 1.2 is about treating the FM as a production dependency, not a hardcoded library call.

Use case and constraints
  -> model candidates
  -> evaluation with ground truth
  -> model selection or routing
  -> resilient invocation pattern
  -> lifecycle controls for custom models

Exam shortcut:

Need best model for a task -> evaluate candidates against ground-truth prompts.
Need lower cost with similar quality -> smaller model, prompt router, distillation, caching.
Need switch models without code changes -> model abstraction + AppConfig/config-driven routing.
Need survive Bedrock model/Region limits -> inference profiles, cross-Region inference, fallback model, circuit breaker.
Need proprietary/current facts -> RAG first.
Need different behavior/style/task accuracy -> fine-tuning.
Need new domain knowledge in model weights -> continued pre-training.
Need production governance for custom model -> SageMaker Model Registry + CI/CD + approval + rollback.

What Task 1.2 Is Really Testing

The exam expects you to choose and operate FMs with evidence. A professional-level answer includes evaluation, configuration, resilience, and lifecycle management.

Exam area What that means in practice
Model capability Match model to task type: chat, summarization, extraction, code, image, multimodal, embeddings, tool use, or structured output
Model constraints Check context length, supported modalities, supported APIs, Region availability, latency, throughput, quotas, customization support, and cost
Evaluation Use representative prompts, ground-truth answers, business metrics, adversarial prompts, automatic metrics, human review, or LLM-as-a-judge
Dynamic selection Route requests through a central gateway or router instead of hardcoding model IDs in application code
Provider switching Hide model-specific request/response differences behind an abstraction layer and use configuration for model/provider selection
Resilience Design for throttling, service disruption, model unavailability, bad outputs, downstream tool failures, and Region constraints
Customization lifecycle Version custom models, approve releases, automate deployments, compare versions, roll back, and retire obsolete models

Model Selection Checklist

Ask these questions before choosing a model.

Decision factor What to evaluate Exam signal
Business goal Does the model solve the actual workflow or decision problem? "Align with business use case"
Task type Summarization, Q&A, extraction, classification, code, multimodal, embeddings, agent/tool use "Capability analysis"
Quality threshold Accuracy, completeness, groundedness, hallucination rate, instruction following, style, safety "Performance benchmarks"
Latency P50/P95 response time, streaming support, cold starts in surrounding architecture "Interactive user experience"
Cost Tokens, model price, retries, evaluation cost, vector retrieval, provisioned throughput "Cost optimization"
Context window Prompt size, retrieved chunks, conversation history, documents, tool traces "Long context requirements"
Modality Text, image, audio, video, document, or mixed input/output "Multimodal application"
Integration API Converse API, InvokeModel, streaming, batch, embeddings, prompt router, SageMaker endpoint "Implementation fit"
Safety/compliance Data sensitivity, harmful content, prompt injection, PII, auditability "Responsible AI controls"
Availability Region support, quotas, inference profile support, provisioned throughput, fallback options "Limited regional availability"
Customization Fine-tuning, continued pre-training, distillation, SageMaker JumpStart support, adapters/LoRA "Domain-specific fine-tuned model"
Operations Monitoring, model versioning, rollback, approval workflow, retirement "Lifecycle management"

Model Evaluation Strategy

AWS Well-Architected Generative AI Lens recommends testing models against prompt-response pairs from ground-truth data, including challenging or questionable prompts. Amazon Bedrock evaluations can evaluate Bedrock models, knowledge bases, external models/RAG sources, customized models, imported models, prompt routers, and models with Provisioned Throughput.

Evaluation method Use when What it measures
Custom ground-truth dataset You have representative prompts and expected outputs Task accuracy, correctness, regression risk
Built-in benchmark dataset You need a fast baseline or public comparison General model quality dimensions
Programmatic evaluation You need scalable, repeatable metrics Accuracy, robustness, toxicity, semantic similarity, other computed scores
Human evaluation Subjective quality matters Tone, brand voice, usefulness, helpfulness, domain expert preference
LLM-as-a-judge You need faster evaluation at scale with explanations Response quality, correctness, instruction following, safety dimensions
RAG evaluation You are evaluating a knowledge base or retrieval pipeline Retrieval relevance, retrieval correctness, grounded generated answer
Adversarial/safety tests User-facing or sensitive system Prompt injection resistance, harmful output handling, refusal behavior

Exam shortcut:

"Which model is best?" -> Do not guess. Build an evaluation set and compare candidates.
"Subjective brand/tone" -> Human evaluation.
"Need quick automated scoring" -> Programmatic or LLM-as-a-judge evaluation.
"RAG quality issue" -> Evaluate retrieval and generated response separately.

Choosing the Right Model Size and Type

Requirement clue Prefer Why
High reasoning quality, complex instructions, code, difficult synthesis Larger/more capable FM Better quality on complex tasks
High volume, simple classification, extraction, routing, summarization Smaller/faster FM Lower latency and cost may meet quality threshold
Unclear split between simple and complex prompts in one model family Amazon Bedrock Intelligent Prompt Routing Dynamically routes prompts within a model family for quality/cost optimization
Output must be embedded for semantic search Embedding model Generates vector representations, not user-facing text
Answers must use enterprise documents RAG with Bedrock Knowledge Bases/vector store Grounds answers without changing model weights
Model must follow a specific response style or task pattern Fine-tuning Improves task-specific behavior with labeled examples
Model needs domain vocabulary or knowledge in weights Continued pre-training Adapts the model to domain knowledge with larger unlabeled data
Need smaller specialized model with larger-model quality Model distillation Uses a larger teacher model to create a smaller student model
Open model, custom container, low-level deployment controls SageMaker AI / JumpStart More control over endpoint, instance, deployment, and lifecycle

Exam trap: bigger is not automatically better. Choose the smallest and most cost-effective model that meets quality, safety, latency, and compliance requirements.

Dynamic Model Selection Patterns

Task 1.2 explicitly calls out flexible architecture patterns that enable dynamic model selection and provider switching without code changes.

Pattern When to use AWS services/features
Configuration-driven model gateway Multiple apps need a stable inference API while model choices change API Gateway, Lambda, AppConfig, Bedrock Converse API, CloudWatch
Bedrock Intelligent Prompt Routing You want Bedrock-managed routing between models in the same model family Amazon Bedrock prompt routers
Rule-based routing Different task types should use different models Lambda, AppConfig, Step Functions, model metadata
Quality/cost routing Easy prompts use smaller models; difficult prompts use stronger models Prompt router or custom router with evaluation data
Tenant/customer routing Different customers have different data residency, cost, or model approval policies Cognito/IAM, AppConfig, DynamoDB config, Lambda
Provider abstraction You need to switch between Bedrock, SageMaker endpoints, or external providers Model gateway with normalized request/response schema
Blue/green or canary model release You are testing a new model/version with limited traffic AppConfig feature flags, Lambda weights, API Gateway stages, CodeDeploy

Reference Architecture: Model Gateway

Client/app
  -> API Gateway
  -> Lambda or containerized model gateway
  -> read routing config from AppConfig
  -> normalize request to Converse API / SageMaker endpoint / other provider
  -> invoke selected model
  -> validate output
  -> log model ID, version, route, latency, tokens, cost metadata
  -> response

The key exam idea is that model IDs, provider names, inference parameters, prompt versions, and fallback rules should be configuration data, not scattered through application code.

Amazon Bedrock Intelligent Prompt Routing

Amazon Bedrock Intelligent Prompt Routing provides a single serverless endpoint that routes requests between different FMs within the same model family. It predicts response quality for each request and selects the best quality/cost option.

Concept Exam-ready meaning
Same model family Prompt routing is for models within a supported family, not arbitrary providers/models
Default router AWS-provided router that works out of the box for supported model families
Configured router User-defined router with routing criteria and fallback model
Fallback model Reliable baseline model used as an anchor for routing decisions
Response quality difference Threshold used to decide when another model is sufficiently better than the fallback
Traceability Responses include information about which model processed the request
Limitation Routing is optimized for English prompts and may not fit specialized use cases without validation

When to choose prompt routing:

  • The workload uses supported models in the same family.
  • Evaluation shows no single model size clearly dominates every prompt.
  • You need cost reduction while preserving quality.
  • You want Bedrock-managed routing instead of custom orchestration.

When not to choose prompt routing:

  • You need to route across unrelated providers or self-hosted models.
  • You need routing based on application-specific private metrics that Bedrock routing cannot observe.
  • You have non-English or highly specialized prompts and no validation data proving router quality.

Model Configuration Parameters

Different models expose different parameters, but the exam often tests what these controls generally do.

Parameter What it controls Use carefully when
Temperature Randomness/creativity Lower for deterministic extraction/classification; higher for creative generation
Top P / nucleus sampling Diversity of likely token choices Lower for more focused output, higher for broader variation
Top K Limits next-token choices to top candidates Useful for controlling randomness where supported
Max tokens Maximum generated output length Prevent runaway cost or truncated required answers
Stop sequences Strings that stop generation Useful for structured outputs or delimiting sections
System instructions High-level role and behavior Keep stable and governed for production
Tool/function schema Allowed tools and input schema Validate all model-generated tool arguments
Response format/schema Required structure such as JSON Always validate downstream

Exam shortcut:

Reliable extraction -> low randomness + schema + validation.
Creative writing -> allow more variation.
Cost control -> max tokens + prompt trimming + smaller model + caching/routing.

Resilience and Failover

Task 1.2 expects you to keep AI systems operating during service disruptions. Treat model invocation like any other external dependency: it can throttle, fail, return invalid output, or become unavailable in a Region.

Failure mode Best response
Throttling or quota errors Exponential backoff, jitter, queueing, rate limits, Provisioned Throughput where appropriate
Model temporarily unavailable Fallback model, graceful degradation, circuit breaker, retry later
Region capacity issue Amazon Bedrock cross-Region inference profile or cross-Region deployment
Latency spike Timeout, fallback to faster model, streaming, async processing
Invalid model output Output validation, repair prompt, retry with stricter prompt, human review
Tool/action failure Step Functions retry/catch, idempotent tool calls, compensation logic
Poor answer confidence Ask clarification, retrieve more context, escalate to human, return partial answer with caveat
Provider/model change Configuration-driven routing and regression evaluation before promotion

Circuit Breaker Pattern

Use a circuit breaker when repeated model failures would harm user experience or overload dependencies.

Invoke primary model
  -> success: return response and reset failure count
  -> transient failure: retry with backoff
  -> repeated failure threshold reached: open circuit
  -> use fallback model, cached answer, async queue, or human review
  -> periodically probe primary model
  -> close circuit after healthy responses

AWS services to recognize:

Need AWS service/feature
Explicit retries, catches, branches, fallback workflows AWS Step Functions
Burst handling SQS, EventBridge, Step Functions, async workers
Cross-Region Bedrock model routing Amazon Bedrock cross-Region inference profiles
Centralized health and alarms CloudWatch metrics, logs, alarms, dashboards
Audit of Bedrock cross-Region processing CloudTrail in the source Region with inference Region details
Runtime model switch AppConfig feature flags/config profiles

Amazon Bedrock Cross-Region Inference

Cross-Region inference uses inference profiles that define an FM and the Regions to which requests can be routed. It helps manage unplanned traffic bursts and increase throughput for on-demand inference.

Choice Use when Tradeoff
Geographic inference profile Data processing must stay within a geography such as US, EU, or APAC Keeps routing within geographic boundary but less throughput than global
Global inference profile Maximum throughput and cost/performance are more important than geographic boundary Can route to supported commercial Regions worldwide
Provisioned Throughput You need dedicated throughput for supported models/custom models Inference profiles do not currently support Provisioned Throughput
Self-managed cross-Region endpoint deployment You host models in SageMaker AI or need custom failover control More operational complexity

Key exam facts:

  • Cross-Region inference can route inference requests across Regions to improve throughput.
  • Data stays on the AWS network and is encrypted in transit between Regions.
  • Cross-Region inference requests are logged in CloudTrail in the source Region.
  • Choose geographic profiles for data residency constraints; choose global profiles for maximum throughput/cost optimization when allowed.

Customization Decision Table

Do not jump to fine-tuning before simpler options. The exam often tests the right customization level.

Need Choose Why
Add private/current enterprise facts RAG / Bedrock Knowledge Bases Keeps knowledge external and updatable
Improve answer format, tone, instructions, or task framing Prompt engineering / Prompt Management Lowest operational cost and fastest iteration
Improve task-specific accuracy with labeled examples Fine-tuning Adjusts model behavior for a specific task
Add domain knowledge from a large unlabeled corpus Continued pre-training Domain-adapts model weights
Create smaller, cheaper specialized model from a larger model Model distillation Reduces cost/latency while preserving task performance
Improve alignment with preference/reward feedback Reinforced fine-training where supported Optimizes model behavior against feedback/reward functions
Need custom model deployment controls, custom containers, open-weight models, or endpoint-level management SageMaker AI / JumpStart Greater lifecycle and hosting control
Need managed Bedrock custom model inference Amazon Bedrock custom model with Provisioned Throughput Bedrock-managed customization path

Exam traps:

  • Use RAG before fine-tuning when the problem is missing or changing knowledge.
  • Use fine-tuning when the model must perform a task/style more consistently, not merely know more facts.
  • Continued pre-training needs more data and investment than fine-tuning.
  • Custom Bedrock models require Provisioned Throughput for inference.

Bedrock Custom Models vs SageMaker AI

Requirement Amazon Bedrock custom models Amazon SageMaker AI / JumpStart
Managed access to supported FMs Strong fit Possible, but more control than needed
Fine-tune supported Bedrock models Strong fit Use if model/workflow requires SageMaker
Continued pre-training, distillation, reinforced fine-training where supported Strong fit Use if you need SageMaker-specific workflow/control
Deploy open-weight or JumpStart foundation models Not the primary path Strong fit
Custom containers, endpoint scaling policy, advanced deployment patterns Limited compared with SageMaker Strong fit
Model Registry, approval workflow, lineage, CI/CD deployment Integrate with lifecycle tooling as needed Strong fit with SageMaker Model Registry
Inference for a Bedrock custom model Requires Provisioned Throughput SageMaker endpoint/provisioned infrastructure

FM Customization Lifecycle

Professional exam answers include lifecycle management, not just training a custom model.

Select base model
  -> prepare/validate training and evaluation data
  -> customize model
  -> evaluate against baseline and acceptance thresholds
  -> register model/version
  -> approve for staging/production
  -> deploy with canary or blue/green strategy
  -> monitor quality, latency, cost, safety, drift
  -> roll back if metrics fail
  -> retire stale or noncompliant versions
Lifecycle step AWS services/features
Training data storage Amazon S3, KMS, IAM
Fine-tuning/customization Amazon Bedrock custom models, SageMaker JumpStart, SageMaker training jobs
Evaluation Amazon Bedrock evaluations, SageMaker evaluation workflows, custom test harness
Versioning and approval SageMaker Model Registry, model groups, model versions, approval status
Deployment automation CodePipeline, CodeBuild, CodeDeploy, SageMaker Pipelines, CloudFormation/CDK
Progressive release AppConfig feature flags, canary, blue/green, weighted routing
Monitoring CloudWatch, CloudTrail, SageMaker Model Monitor where applicable, custom quality metrics
Rollback Previous model version, previous endpoint config, previous AppConfig route, previous prompt version
Retirement Disable route, archive artifacts, revoke endpoint/provisioned throughput, update documentation

SageMaker Model Registry Cues

Choose SageMaker Model Registry when the question emphasizes model governance and lifecycle.

Exam clue Model Registry capability
"Catalog production models" Stores model packages/groups
"Manage model versions" Registers each trained model as a version
"Approval before production" Tracks approval status
"Lineage and reproducibility" Tracks model lineage and metadata
"Automated deployment with CI/CD" Integrates with deployment pipelines
"Rollback to previous model" Keeps versioned model artifacts/configs
"Share model across teams/accounts" Supports model sharing patterns

Scenario Decision Table

If the question says... Choose...
"Which FM should be selected for this workload?" Evaluate candidate FMs with ground-truth prompt-response pairs and business metrics
"Need subjective tone/brand preference" Human evaluation or domain expert review
"Need fast, repeatable model comparison" Amazon Bedrock programmatic evaluation or LLM-as-a-judge
"Need model selection to change without code deployments" API Gateway/Lambda model gateway with AppConfig-driven routing
"Need routing between supported models in the same family for quality/cost" Amazon Bedrock Intelligent Prompt Routing
"Need switch between Bedrock and SageMaker endpoints" Provider abstraction layer with normalized request/response schema
"Need continuous operation during Region capacity issues" Amazon Bedrock cross-Region inference profile, fallback model, circuit breaker
"Must keep data processing within EU/US/APAC" Geographic cross-Region inference profile where supported
"Need highest throughput and no strict geographic boundary" Global cross-Region inference profile
"Primary model is failing repeatedly" Step Functions circuit breaker with fallback path
"Model returns malformed JSON" Output validation, repair retry, stricter schema, or human review
"Internal docs change often" RAG, not fine-tuning
"Model needs to follow company-specific response style" Fine-tuning if prompt engineering is insufficient
"Need domain adaptation from large unlabeled corpus" Continued pre-training
"Need smaller specialized model for lower latency/cost" Distillation
"Need to version, approve, deploy, and roll back custom models" SageMaker Model Registry with CI/CD
"Need Bedrock custom model inference" Purchase/configure Provisioned Throughput for the custom model

Common Architecture Patterns

Direct selected FM:

App -> API Gateway -> Lambda -> Bedrock Converse API -> response

Config-driven FM selection:

App -> API Gateway -> Model gateway
  -> AppConfig route: task/tenant/version -> model ID + parameters
  -> Bedrock/SageMaker invocation
  -> validation/logging -> response

Prompt router:

App -> Bedrock prompt router endpoint
  -> Bedrock selects supported model in family
  -> response includes selected model information

Resilient inference workflow:

App -> Step Functions
  -> invoke primary model
  -> retry transient failure
  -> catch repeated failure
  -> fallback model / queue / cached response / human review
  -> emit metrics and audit logs

Custom model release:

Training data in S3
  -> fine-tune/customize model
  -> evaluate against baseline
  -> register version
  -> approve
  -> deploy canary
  -> monitor
  -> promote or roll back

Production Anti-Patterns

Anti-pattern Better answer
Hardcoding model IDs in every app Central model gateway and AppConfig routing
Selecting the newest/largest model without testing Evaluate candidate models against ground-truth use-case data
Using one model for every task Route by task, complexity, tenant, cost, latency, and quality
Treating public benchmark scores as sufficient Combine benchmarks with workload-specific evaluation data
Fine-tuning to add changing facts Use RAG or knowledge bases
No fallback model Define fallback path, circuit breaker, and graceful degradation
Retrying indefinitely on model errors Bounded retries with backoff, timeout, and fallback
No output validation Validate JSON/schema/tool arguments before downstream use
Releasing a fine-tuned model without comparison Evaluate against base and previous production model
No model version/approval workflow Use Model Registry or equivalent release governance
Retaining obsolete models indefinitely Retire unused or noncompliant model versions and update routing
Ignoring Region/data residency constraints Choose supported Regions, geographic inference profiles, or regional deployments

Exam Traps

Trap Correct thinking
"Best FM" means the most advanced model Best means the model that meets quality, latency, cost, modality, compliance, and operational needs
"Benchmark winner" automatically wins Workload-specific ground-truth evaluation matters more
Prompt routing replaces evaluation Prompt routers must still be validated for the workload
Cross-Region inference is the same as multi-Region app architecture It routes Bedrock inference requests; the rest of the app still needs resilience design
Global inference profile is always best Geographic profiles are better when data residency matters
Fine-tuning is the answer to every poor response Try prompt engineering, RAG, better retrieval, or model selection first
Fine-tuning adds current enterprise facts RAG is usually better for current/private knowledge
Custom model deployment ends after training Production requires evaluation, versioning, approval, deployment automation, monitoring, rollback, and retirement
Model-generated tool parameters are trustworthy Validate and authorize all tool inputs
Logs can store all prompts/responses freely Prompts and responses may contain sensitive data; encrypt, restrict, redact, and govern retention

Study Checklist

Before moving to Task 1.3, make sure you can:

  • Explain the four Task 1.2 skills in the official exam guide.
  • Build a model selection matrix with quality, latency, cost, modality, context, safety, availability, and customization needs.
  • Choose the right evaluation method: programmatic, human, LLM-as-a-judge, or RAG evaluation.
  • Explain when to use Bedrock Intelligent Prompt Routing and when to build a custom model gateway.
  • Design configuration-driven model switching with API Gateway, Lambda, and AppConfig.
  • Explain cross-Region inference profiles and when to choose geographic vs global profiles.
  • Design a circuit breaker/fallback workflow with Step Functions.
  • Choose between RAG, prompt engineering, fine-tuning, continued pre-training, distillation, and SageMaker AI deployment.
  • Use SageMaker Model Registry cues: versioning, approval, lineage, CI/CD, deployment, rollback.
  • Recognize anti-patterns such as hardcoded model IDs, no evaluation, no fallback, and fine-tuning for changing facts.

Sources