AWS Certified Generative AI Developer – Professional (AIP-C01) — Complete Study Guide

The AWS Certified Generative AI Developer – Professional (AIP-C01) assumes real production experience — not notebooks, not demos, but systems with real users, real cost budgets, real compliance reviews, and real 2 a.m. incident pages.

This is not a "what does Amazon Bedrock do?" exam. Nearly every question is a scenario: a company with specific latency targets, compliance constraints, cost ceilings, or failure symptoms, and four plausible-looking architectures. Your job is to pick the one that best satisfies all the stated constraints. That skill — constraint-driven elimination — is what this guide trains, alongside the raw service knowledge you need to apply it.

Because scoring is compensatory, a weak domain can be offset by strong ones. But with Domain 1 and Domain 2 together carrying 57% of the exam, there is no path to a pass that avoids deep fluency in Bedrock integration patterns, RAG data design, and agentic implementation.

How to Use This Guide

This guide is organized into five Parts that map exactly to the five official exam domains and their weights. Within each Part, every task-statement topic cluster from the official exam guide gets its own teaching section — nothing in the spec is skipped.

Watch for four recurring callouts:

Suggested study plan: Work through Parts 1–5 in order (they mirror domain weight, heaviest first). Build at least one real Bedrock Knowledge Base, one Guardrail, and one Strands agent while studying — the exam's scenario style rewards muscle memory. In the final week, re-read only the callouts and the Exam-Day Checklist.

Part 1 · Foundation Model Integration, Data Management, and Compliance (31%)

Domain 1 is the heart of the exam: choosing and integrating foundation models, designing the data layer that feeds them, and doing both in a governed, compliant way. Expect roughly 20 scored questions from this domain.

GenAI Architecture Design and the Well-Architected Generative AI Lens

Every AIP-C01 architecture question is implicitly a Well-Architected question. The Generative AI Lens of the AWS Well-Architected Framework extends the six pillars with GenAI-specific guidance:

• Operational excellenceversion prompts and flows like code; automate evaluation in CI/CD; trace every model invocation.
• Securitytreat prompts and completions as untrusted data; apply Guardrails, VPC endpoints, and least-privilege IAM to model access.
• Reliabilityplan for throttling (ThrottlingException is a normal operating condition), use cross-Region inference, and design graceful degradation.
• Performance efficiencyright-size the model to the task; stream tokens; cache aggressively.
• Cost optimizationtokens are the unit of cost; measure and budget them like you would GB-months.
• Sustainabilitysmaller models and cached responses reduce compute footprint.

The lens also defines the generative AI lifecycle: scoping → model selection → customization → integration → deployment → continuous improvement. Exam scenarios frequently identify which lifecycle stage a team is in and ask for the appropriate next action.

Core integration patterns you must recognize on sight:

1. 1Direct invocationapplication calls InvokeModel/Converse synchronously. Simplest; fine for low-volume, latency-tolerant flows.
2. 2RAG (Retrieval-Augmented Generation)retrieve enterprise knowledge at query time and inject it into context. The default answer for "the model needs current/proprietary knowledge without retraining."
3. 3Agenticthe model plans, calls tools, observes results, and iterates. The answer when the task requires actions and multi-step reasoning, not just answers.
4. 4Fine-tuned / customizedadjust model weights for domain style, format, or terminology. The answer when prompting and RAG cannot achieve the required behavior and thousands of labeled examples exist.

Proving Value Fast: Bedrock Proofs of Concept

Amazon Bedrock is a serverless, API-first service exposing models from Anthropic, Amazon (Nova/Titan), Meta, Mistral, Cohere, and others behind one API — which is exactly why it is the exam's default PoC vehicle. A well-run PoC:

• •
  Uses the Bedrock console playgrounds (chat, text, image) for zero-code experimentation, then the Converse API for a thin prototype — Converse gives you a uniform request/response shape across model providers, so you can swap models without rewriting code.
• •
  Defines success metrics before building: task accuracy on a golden dataset, p95 latency, cost per 1,000 requests.
• •
  Starts with on-demand inference (pay per token, no commitment) and defers provisioned throughput until load is proven.
• •
  Uses Bedrock Knowledge Bases for a managed RAG PoC instead of hand-rolling ingestion, chunking, and vector search.

FM Benchmarks and Capability Analysis

Professional-level model selection is evidence-driven. You should know the three tiers of evidence:

1. 1Public benchmarksMMLU (broad knowledge), HumanEval (code), HELM/LMSYS-style leaderboards. Useful for shortlisting, but benchmark scores do not predict performance on your task.
2. 2Bedrock Model Evaluation jobsautomatic evaluation (accuracy, robustness, toxicity on built-in or custom datasets), human evaluation work teams, and LLM-as-a-judge for scalable quality scoring against your own prompt dataset.
3. 3Production A/B measurementthe final arbiter.

Capability analysis dimensions to compare: modality support (text, image, video, audio), context window size, tool-use/function-calling support, structured-output reliability, language coverage, latency class, and price per input/output token.

Dynamic Model Selection at Runtime

Static model choice hard-coded in the application is fragile. The exam expects runtime-configurable selection:

• AWS AppConfig (or Parameter Store) holds the active model ID, inference parameters, and prompt version as configuration — change models with a config deployment, no code release, with AppConfig validators and automatic rollback on alarm.
• API Gateway + Lambda as a routing façade: Lambda inspects the request (task type, user tier, complexity heuristics) and routes to the appropriate model — a small, cheap model for classification and summarization; a frontier model for complex reasoning.
• Bedrock Intelligent Prompt Routing routes each prompt within a model family to the cheapest model predicted to meet quality, without custom code.

# Lambda router: model choice is config, not code
import boto3, json
config = json.loads(appconfig_data.get_latest_configuration(...))
model_id = config["tiers"][classify(request)]   # e.g. "haiku" vs "sonnet" tier
bedrock.converse(modelId=model_id, messages=messages,
                 inferenceConfig=config["inferenceParams"])

Resilient GenAI Design

Foundation model APIs throttle, brown out, and occasionally return garbage. Resilience patterns the exam tests:

• Circuit breakers with Step Functionsmodel invocation wrapped in a state machine with Retry (exponential backoff + jitter on ThrottlingException) and Catch routing to a fallback state. A DynamoDB-backed circuit state (CLOSED/OPEN/HALF-OPEN) prevents hammering a failing dependency.
• Cross-Region Inference (inference profiles)Bedrock automatically routes requests across a set of Regions within the same geography, increasing effective quota and absorbing regional capacity spikes with no data stored in the routed Region. This is the managed answer to "we hit throttling during peak."
• Graceful degradationan ordered fallback chain: primary model → smaller/faster model → cached prior answer → static "try again later" response. Degrade quality before degrading availability.
• Bulkheadsseparate provisioned capacity or quota pools for critical vs. best-effort workloads so a batch job cannot starve the customer-facing chat.

FM Customization Lifecycle

When prompting and RAG genuinely cannot deliver (style, format, domain vocabulary), customization enters — and it must be run like software delivery:

• Bedrock fine-tuning (labeled prompt/completion pairs) and continued pre-training (unlabeled domain corpus) produce a custom model that requires Provisioned Throughput (or supported on-demand custom-model inference) to serve.
• LoRA (Low-Rank Adaptation) adapters train small low-rank matrices instead of all weights — cheaper training, small artifacts, and the ability to serve multiple adapters on one base model (e.g., SageMaker multi-adapter inference). The right answer for "many per-tenant customizations without per-tenant model copies."
• SageMaker Model Registry versions every customized model with evaluation metrics, approval status, and lineage — the gate between "trained" and "deployable."
• Rollbackkeep the previous model version registered and serving-ready; alias-based deployment (or AppConfig model-ID switch) makes rollback a pointer flip, not a redeployment. Never delete the prior version until the new one has passed a bake period.

Data Validation and Multimodal Ingestion Pipelines

Garbage into the vector store means confident garbage out of the model. Pipeline building blocks:

• •
  AWS Glue Data Quality — rule-based validation (completeness, uniqueness, freshness, custom rules in DQDL) on ingestion datasets; fail or quarantine bad batches before embedding.
• •
  SageMaker Processing — containerized batch jobs for cleaning, deduplication, PII scrubbing, and format normalization at scale.
• •
  Amazon Transcribe converts audio/video to text (with speaker diarization and PII redaction) so spoken content becomes searchable RAG source material; Amazon Textract does the same for scanned documents; Bedrock Data Automation handles multimodal extraction (documents, images, video, audio) into structured output with a single managed service.
• •
  Orchestrate with Step Functions or Glue workflows; land validated, versioned corpora in S3 with manifest files so every embedding batch is reproducible.

Input Formatting and Preprocessing

• •
  The Converse API takes structured JSON: a messages array with roles, system prompts, inferenceConfig, and toolConfig — one schema across providers. The legacy InvokeModel API requires provider-specific JSON bodies; malformed provider JSON returns ValidationException.
• •
  Amazon Comprehend pre-processes inputs: language detection (route to a multilingual model or translate first), entity extraction (to build metadata filters), sentiment (routing angry customers to humans), and PII detection before the prompt ever reaches the model.
• •
  Normalize encodings, strip boilerplate, and truncate/summarize oversized inputs deliberately (never let silent truncation decide what the model sees).

Vector Store Design and Selection

The exam expects you to choose the right vector store for a constraint set, not to name one favorite:

Metadata Frameworks and Vector Store Maintenance

Metadata is what turns similarity search into correct search:

• •
  Attach structured metadata to every chunk: source URI, document version, tenant/BU, security classification, effective date, language. Bedrock Knowledge Bases supports metadata filtering at retrieval time — the standard mechanism for multi-tenant isolation and freshness filtering inside one index.
• •
  Maintenance disciplines: scheduled re-ingestion syncs for changed sources (KB data-source sync jobs); delete-vectors-on-source-delete so revoked documents actually disappear; re-embed the full corpus when you change embedding models (embeddings from different models are not comparable — never mix them in one index); monitor index size, recall, and query latency as the corpus grows.

Chunking Strategies

Chunking determines what the retriever can find and what the model reads:

Small chunks improve retrieval precision but lose context; large chunks preserve context but dilute similarity scores and burn context-window tokens. Overlap (typically 10–20%) prevents boundary loss.

Embedding Model Selection

• •
  Amazon Titan Text Embeddings V2 supports configurable output dimensions (1024/512/256) — smaller dimensions cut storage and query cost with modest accuracy loss. Titan Multimodal Embeddings places text and images in one vector space for cross-modal search. Cohere Embed models (on Bedrock) are strong multilingual alternatives.
• •
  Selection criteria: language coverage, modality, dimension/cost trade-off, max input tokens, and retrieval accuracy on your corpus (measure recall@k on a labeled query set).
• •
  Changing embedding models is a full re-index event — plan dual-write/dual-read migration windows.

Advanced Retrieval Techniques

• Hybrid searchcombine BM25 keyword scoring with vector similarity (Bedrock KB hybridSearch, OpenSearch rank fusion). Essential when queries contain exact identifiers (SKUs, error codes) that pure semantic search fumbles.
• Rerankersretrieve a generous candidate set (e.g., top 25) cheaply, then apply a reranking model (Bedrock Rerank API with Cohere Rerank or Amazon Rerank) to reorder by fine-grained relevance and keep the top 3–5. Big precision gains for one extra low-cost hop.
• Query expansion / rewritingan LLM pre-step decomposes multi-part questions, resolves pronouns from conversation history, and adds synonyms before retrieval (Bedrock KB query reformulation does this managed).
• MCP clients for retrievalinstead of pre-indexing everything, an agent acting as a Model Context Protocol client queries live enterprise systems (ticketing, CRM, wikis) through MCP servers at answer time. Choose live MCP retrieval for volatile data; choose vector indexes for large, stable corpora.

Prompt Engineering and Prompt Governance

Professional prompt work is engineering, not vibes:

• •
  Techniques: role/system prompting, few-shot examples, chain-of-thought ("think step by step" or structured reasoning fields) for multi-step problems, output contracts ("respond only with JSON matching this schema"), and XML-style delimiters to separate instructions from untrusted user content.
• •
  Bedrock Prompt Management stores prompts as versioned, variable-templated resources with variants for comparison — prompts become deployable artifacts referenced by ARN, not strings buried in code.
• •
  Governance loop: every prompt change runs a regression suite (golden input/expected-property pairs) before promotion; Guardrails attach at the prompt layer so safety survives prompt edits; production references an approved prompt version, never DRAFT.

Prompt Flows and Chaining

Amazon Bedrock Flows (formerly Prompt Flows) is a visual builder that chains prompts, Knowledge Bases, Lambda functions, agents, and conditional logic into a single executable, versioned workflow — ideal for deterministic multi-step pipelines (classify → retrieve → generate → format) without writing orchestration code. For chains needing full programmatic control, long durations, or complex error handling, Step Functions is the heavier-duty alternative. Chaining principle: each step does one job, validates its output (schema check) before passing downstream, and fails loudly — silent propagation of a bad intermediate output is the root cause in many troubleshooting scenarios.

Part 2 · Implementation and Integration (26%)

Domain 2 covers turning designs into running systems: agents, tools, deployment models, enterprise wiring, and resilient APIs. Expect roughly 17 scored questions.

Agentic AI with Memory and State

Three named technologies dominate this domain — know exactly what each is:

• Strands AgentsAWS's open-source, code-first Python SDK for building agents. A model-driven loop: you give it a model, a system prompt, and tools (plain Python functions decorated with @tool, or MCP servers); the model plans and acts in a loop until done. Supports conversation memory, session persistence, streaming, and multi-agent primitives (agents-as-tools, swarms, graphs). Deployable anywhere Python runs — Lambda, Fargate, EKS, Bedrock AgentCore.
• AWS Agent Squad (formerly Multi-Agent Orchestrator) — an open-source framework for routing and coordinating multiple specialized agents: a classifier picks the right agent for each user message, and the framework maintains conversation context across agents in a session. The answer for "several specialized agents, one coherent conversation."
• MCP (Model Context Protocol)an open standard that decouples agents from tools: MCP servers expose tools/resources; MCP clients (agents) discover and call them at runtime. Solves the M×N integration problem — build a tool integration once, use it from any MCP-capable agent.

State layers to design deliberately: short-term conversation memory (context window), session state (DynamoDB or AgentCore Memory), and long-term memory (summaries/facts persisted across sessions, often in a vector store).

from strands import Agent, tool

@tool
def get_order_status(order_id: str) -> str:
    """Look up an order's shipping status."""
    return orders_table.get_item(Key={"id": order_id})["Item"]["status"]

agent = Agent(model="anthropic.claude-sonnet-...", tools=[get_order_status],
              system_prompt="You are a support agent. Use tools; never guess.")
agent("Where is order 8812?")   # model plans → calls tool → answers

Structured Reasoning: ReAct and CoT via Step Functions

• ReAct (Reason + Act)the agent alternates Thought → Action (tool call) → Observation until it can answer. This is the loop inside Strands and Bedrock Agents.
• Chain-of-thought via Step Functionswhen reasoning steps must be auditable, durable, and individually retryable, externalize them: each state invokes the model for one reasoning stage, persists the intermediate output, and applies its own retry/catch policy. Choose Step Functions over in-model CoT when steps have side effects, need human checkpoints, or must survive process restarts.

Safeguarded Agent Workflows

Autonomous loops need brakes:

• Stopping conditionshard caps on iterations/tool calls per task; budget caps on tokens per session; explicit terminal states. An agent without an iteration cap is an infinite-loop cost incident waiting to happen.
• Timeoutsper-tool-call timeouts and end-to-end task timeouts (Step Functions TimeoutSeconds, Lambda timeouts) with defined fallback behavior.
• IAM boundarieseach agent (and each tool) gets its own execution role scoped to exactly the resources it touches; use permissions boundaries so no agent-created or agent-assumed role can exceed a ceiling. The agent's LLM output must never be able to expand its own permissions.
• Blast-radius controlsread-only tools by default; mutating tools require explicit allow-listing and, for high-impact actions, human approval.

Multi-Model Coordination and Human-in-the-Loop

• Multi-model pipelines assign each model what it is best at: a fast, cheap model classifies and routes; a reasoning model plans; a specialized model (code, image) executes; a small model summarizes. Coordinate via Step Functions (deterministic) or a supervisor agent (dynamic).
• Human-in-the-loop (HITL)Step Functions waitForTaskToken pauses a workflow until a human approves via a callback (SendTaskSuccess/SendTaskFailure); Amazon A2I (Augmented AI) provides managed human-review workflows with private or vendor workforces. Insert HITL where errors are irreversible or high-stakes: payments, legal text, medical content, external publication.

Tool Integrations and MCP Servers

Where to run tools and MCP servers:

• Lambdathe default for stateless, short-lived tools (lookups, calculations, API calls): scales to zero, per-invocation isolation, natural fit for Bedrock Agents action groups (OpenAPI-schema-defined) and Strands tools.
• ECS/Fargate (or EKS)for MCP servers and tools that are long-running, stateful, connection-heavy (persistent DB pools, streaming sessions, >15-minute work) or need custom runtimes.
• Bedrock AgentCore Gateway can front existing APIs and Lambda functions as MCP tools with managed auth — turning legacy services into agent tools without rewriting them.

FM Deployment Strategies

LLM Deployment Challenges

Self-hosting (SageMaker/EKS) surfaces the hard physics the exam probes:

• GPU memorymodel weights (billions of params × bytes/param) plus KV cache that grows with context length × concurrent requests. Mitigations: quantization (INT8/FP8), tensor parallelism across GPUs, continuous batching servers (e.g., vLLM on LMI containers).
• Token capacity planningthroughput is measured in tokens/sec, not requests/sec; a 100-token answer and a 4,000-token answer are wildly different loads. Budget by tokens.
• Cascading failuresa slow model makes clients retry, retries add load, latency worsens, the whole chain collapses. Break the cycle with client-side timeouts shorter than server timeouts, retry budgets, load shedding, and queue-based decoupling.

Enterprise Integration

• Amazon EventBridge decouples GenAI capabilities from enterprise systems: business events (order created, ticket filed) trigger GenAI enrichment asynchronously; results are emitted as new events. This is the pattern for adding AI to systems you cannot modify.
• Legacy integrationwrap legacy SOAP/on-prem systems behind API Gateway + Lambda adapters (or MCP servers), so agents consume a clean modern interface.
• Data synchronizationkeep vector stores fresh via CDC/event-driven re-ingestion: DynamoDB Streams / Aurora → EventBridge → re-embed pipeline → KB sync. Stale indexes are a top cause of "the bot gives outdated answers."

Secure Access: Federation, RBAC, Least Privilege

• Identity federationworkforce users authenticate via IAM Identity Center / SAML / OIDC; applications exchange user identity for scoped, temporary credentials (Cognito identity pools, STS AssumeRole with session tags). Never bake long-lived keys into a GenAI app.
• RBAC for GenAIroles map to which models (bedrock:InvokeModel scoped by model ARN), which Knowledge Bases, which agents, and which Guardrail a caller may use. Enforce a mandatory Guardrail with the bedrock:GuardrailIdentifier IAM condition key.
• Row/document-level data securitypropagate the end user's entitlements into retrieval (metadata filters derived from identity claims), so the RAG layer cannot leak documents the user couldn't open directly. The model must never be the entitlement boundary.

Hybrid and Edge Deployment

• •
  AWS Outposts — run inference (SageMaker-deployed models on Outposts capacity) inside your data center when data residency or on-prem processing is mandated; Bedrock itself is a Regional service, so scenarios demanding fully local FM inference point to self-managed models on Outposts/EKS Anywhere.
• •
  AWS Wavelength / Local Zones — place latency-critical pre/post-processing (and small models) at the mobile edge for single-digit-millisecond RTT to 5G users, while heavyweight FM calls go back to the Region.
• •
  Standard hybrid split: edge does fast, small, private; Region does big, smart, stateful.

CI/CD and GenAI Gateways

• Pipeline (CodePipeline/CodeBuild or GitHub Actions): source (prompts, flow definitions, agent code, IaC) → build → automated evaluation gate (regression prompts scored by LLM-as-judge against thresholds) → security scans (dependency/container scanning plus prompt-injection and jailbreak test suites) → staged deploy (canary a new prompt/model version to 5% traffic) → auto-rollback on quality or safety alarm. Prompt and model versions ride the same pipeline discipline as code.
• GenAI gatewaya central proxy (API Gateway/ALB + Lambda or container layer) through which all model calls flow, providing: per-team authn/z and quotas, token metering and cost attribution (chargeback), centralized Guardrail enforcement, model allow-lists, response caching, and unified logging. The answer to "many teams calling many models, platform team needs control and cost visibility."

FM API Integration Patterns

• Synchronous (Converse/InvokeModel) — user waits; keep p95 within API Gateway's timeout or front with streaming.
• Streaming (ConverseStream/InvokeModelWithResponseStream) — tokens arrive as they're generated; deliver to browsers via SSE (Server-Sent Events) for one-way token streams (simplest, HTTP-native) or WebSockets (API Gateway WebSocket APIs) for bidirectional chat with interrupts. Streaming transforms perceived latency: time-to-first-token replaces time-to-full-response.
• Asynchronous with SQSproducer enqueues jobs; worker Lambdas/containers invoke the model; results land in S3/DynamoDB with callback/notification. Use for long generations, bulk work, and absorbing throttling (the queue is your buffer). Add a DLQ for poison messages.

Resilience: Backoff, Rate Limiting, Fallbacks, X-Ray

• Retries with exponential backoff + jitter on ThrottlingException/5xx (AWS SDKs have adaptive retry modes — configure, don't reinvent). Cap total retry time; respect a retry budget so retries can't melt the service.
• Client-side rate limitingtoken-bucket limiting against your known Bedrock quotas (requests/min and tokens/min); queue or shed excess rather than blindly submitting.
• Fallbacksalternate model (cross-Region profile or different family), cached response, or degraded static answer — in that order.
• AWS X-Ray traces the full request path (API Gateway → Lambda → Bedrock → vector store), exposing which hop contributes latency and where errors cluster; correlate trace IDs with Bedrock invocation logs for end-to-end forensics.

Intelligent Routing and Developer Tooling

• AWS Amplifyfastest full-stack scaffolding for GenAI front ends (hosting, auth via Cognito, AIConversation components streaming from Bedrock).
• OpenAPI schemasthe contract language for Bedrock Agents action groups: the schema's operation descriptions are what the model reads to decide when and how to call your API. Vague descriptions → wrong tool calls; this is tested.
• Amazon Q DeveloperAI assistance across the SDLC (code generation, scanning, AWS-aware transformations); know it as the developer-productivity tool, distinct from your app's own FMs.
• Bedrock Data Automation (BDA)managed multimodal ETL: documents, images, audio, video in; structured, schema-conformant insights out (standard or custom blueprints). The answer for "extract structured data from mixed media at scale without building parsers."

Part 3 · AI Safety, Security, and Governance (20%)

Domain 3 is where AWS separates professionals from prompt hobbyists: layered safety, privacy engineering, and audit-ready governance. Expect roughly 13 scored questions.

Input Safety: Guardrails and Real-Time Validation

Amazon Bedrock Guardrails is the exam's centerpiece safety service. Know its policy types cold:

Guardrails attach to model invocations, Agents, Knowledge Bases, and Flows — and via the ApplyGuardrail API they validate text from any source, including self-hosted or third-party models. Custom moderation beyond Guardrails: a lightweight classifier (Comprehend custom classification or a small FM) scoring inputs before the expensive model runs.

Output Safety and Deterministic Alternatives

• •
  Filter outputs through the same Guardrail (output-side policies), plus post-processing: toxicity scoring, schema validation, allow-listed URL/citation checking.
• •
  Deterministic text-to-SQL — never let generated SQL run raw. The safe pattern: the LLM produces a structured intent (or SQL validated against an allow-listed schema), execution happens through parameterized queries with a read-only database role, row limits, and query timeouts. Better yet, map intents to pre-approved query templates. Any option executing raw LLM-generated SQL with write permissions is automatically wrong.

Hallucination Reduction

Layered anti-hallucination stack, in order of leverage:

1. 1Ground in a Knowledge BaseRetrieveAndGenerate forces answers from retrieved passages with citations; instruct "answer only from the provided context; say 'I don't know' otherwise."
2. 2Contextual grounding checks (Guardrails) — automatic post-hoc verification that claims trace to sources.
3. 3Fact-checking passa second model verifies claims of the first against retrieved evidence (verify-then-respond).
4. 4Confidence signalinghave the model emit a confidence rating or abstain; route low confidence to humans.
5. 5Constrained/structured outputsJSON Schema-enforced outputs (Converse structured output / tool schemas) eliminate whole classes of free-text fabrication for extraction tasks.

Defense in Depth

The exam expects a layered pipeline, any one layer of which can fail safely:

1. 1.
   Edge/API layer — WAF, authn, rate limits, size caps.
2. 2.
   Comprehend pre-filters — PII detection, language checks, custom classifiers (e.g., prompt-injection classifier via Comprehend "trust and safety" style filtering) before the FM.
3. 3.
   Guardrails on input at invocation.
4. 4.
   Constrained generation — system prompt contracts, structured outputs.
5. 5.
   Guardrails on output.
6. 6.
   Application post-processing — schema validation, redaction, citation checks.
7. 7.
   Monitoring/audit — invocation logs, anomaly detection, human review queues.

Threat Detection: Injection, Jailbreaks, Adversarial Testing

• •
  Prompt injection — instructions smuggled through user input or retrieved/tool content ("ignore previous instructions…"). Indirect injection via RAG documents is the professional-level twist: sanitize and treat retrieved content as untrusted too.
• •
  Mitigations: Guardrails prompt-attack filter, input sanitization (strip markup/hidden text, delimit user content in tags and tell the model those tags are data, not instructions), privilege separation (the model's tools enforce authz — the prompt doesn't), and dedicated safety classifiers in front of the FM.
• •
  Adversarial testing / red teaming — maintain an attack corpus (jailbreak templates, role-play exploits, encoding tricks, multilingual attacks); run it in CI against every prompt/model/guardrail change; track block-rate as a release gate.

Protected Environments

• •
  VPC interface endpoints (PrivateLink) for Bedrock (bedrock-runtime), SageMaker Runtime, and S3 keep inference traffic off the public internet; endpoint policies restrict which principals and APIs traverse them.
• •
  IAM — scope bedrock:InvokeModel to specific model ARNs; require guardrails via condition keys; separate roles for ingestion vs. inference vs. evaluation.
• •
  AWS Lake Formation — fine-grained (database/table/column/row) permissions on the data lake feeding your RAG pipelines, so ingestion jobs can only read what governance allows; combine with Glue Data Catalog for a governed source-of-truth.
• •
  Encrypt everywhere: KMS CMKs on S3 corpora, vector stores, KB, logs; Bedrock does not store or train on your prompts/completions by default — a favorite reassurance fact.

PII and Privacy Engineering

• •
  Amazon Comprehend DetectPiiEntities/ContainsPiiEntities — real-time PII detection/redaction in prompts and outputs (names, SSNs, cards, addresses…), including async redaction jobs over S3.
• •
  Amazon Macie — continuous, ML-driven discovery of sensitive data in S3 — scan training corpora and RAG source buckets before ingestion; alerts on public/unencrypted sensitive buckets.
• •
  Techniques: masking (replace with [NAME] tokens — reversible via lookup for authorized flows), anonymization (irreversible), pseudonymization (consistent tokens preserving referential integrity for analytics).
• •
  S3 lifecycle policies — enforce retention: transition raw transcripts to Glacier, expire conversation logs and intermediate artifacts on schedule — deletion-by-policy is how you honor data-retention commitments.

Compliance, Traceability, and Organizational Governance

• Model cards (SageMaker Model Cards) document intended use, risk rating, training data provenance, evaluation results, and limitations — the audit artifact for "how do you document model risk?"
• LineageGlue Data Catalog + Glue job lineage tracks which sources → transformations → embeddings → indexes; SageMaker ML Lineage tracks datasets → training → model versions. You must be able to answer "which documents could have influenced this answer?"
• Decision logspersist per-request: input, retrieved chunk IDs, prompt version, model ID, guardrail actions, output, and trace ID (Bedrock model invocation logging to CloudWatch Logs/S3 provides the core record).
• CloudTrailwho called which Bedrock/SageMaker control-plane and data-plane APIs, from where — the access audit complementing invocation logs (the content audit).
• Taggingcost allocation and governance tags on every model, KB, agent, and guardrail (owner, data-classification, environment) enforced via tag policies/SCPs in Organizations.
• Continuous monitoringdashboards + alarms for misuse patterns (guardrail block-rate spikes), drift (input distribution and output quality shifts), bias drift (quality metrics segmented by user cohort diverging over time), policy violations, and redaction failures. SageMaker Model Monitor and Clarify formalize data-quality and bias-drift monitoring for hosted models; scheduled LLM-as-judge sampling does it for Bedrock apps.

Transparent and Fair AI

• Transparency mechanics: show retrieval citations/attribution (KB returns source URIs), display reasoning summaries or step traces for agent actions (Bedrock Agents trace events; Strands/AgentCore observability), and expose confidence indicators — users trust systems that show their work.
• Fairness engineering: define quality metrics per segment (language, region, demographic proxy), run A/B tests across model/prompt variants measuring segment gaps, and use LLM-as-judge rubrics that explicitly score bias/toxicity; SageMaker Clarify quantifies bias metrics pre/post deployment.
• Policy-compliant AI by design: encode company policy as machine-enforceable controls — Guardrails denied topics for prohibited advice, Automated Reasoning checks for provable rules, approval workflows for high-risk outputs — so compliance is architecture, not memoranda.

Part 4 · Operational Efficiency and Optimization for GenAI Applications (12%)

Domain 4 is the economics-and-performance domain: tokens, dollars, milliseconds, and dashboards. Expect roughly 8 scored questions.

Token Efficiency

Tokens are the billing meter and the latency driver:

• •
  Estimation — ~4 characters/¾ words per token in English; count precisely with tokenizer libraries; Bedrock returns exact inputTokens/outputTokens in every response — log them.
• •
  Context optimization — send only what changes the answer: trim conversation history (sliding window + rolling summary), retrieve top-k reranked chunks instead of top-25 raw, strip boilerplate/HTML from documents.
• •
  Prompt compression and pruning — shorten system prompts, replace verbose few-shot examples with fewer/tighter ones, prune dead instructions; every system-prompt token is paid on every call, so a 500-token trim across 1M requests/day is real money.
• •
  Cap output tokens (maxTokens) and instruct terse formats when prose isn't needed.

Cost-Effective Model Selection and Tiered Usage

• •
  Tiered FM usage — classify request complexity, then route: small fast model (e.g., Haiku/Nova Micro class) for classification, extraction, routing; mid-tier for everyday generation; frontier model only for hard reasoning. Typical portfolios send 70–90% of traffic to cheap tiers.
• •
  Price-performance analysis — evaluate candidate models on your golden dataset, plot quality vs. $ per 1K requests, and pick the cheapest model that clears the quality bar (Bedrock model evaluation jobs produce exactly this comparison).
• •
  Structural levers: batch inference (~50% discount) for offline work; prompt caching for repeated prefixes; smaller embedding dimensions for vector cost.

Throughput: Batching, Capacity, Auto Scaling, Provisioned

• Request batchingaggregate offline items into Bedrock batch inference jobs; for self-hosted models, continuous batching at the serving layer maximizes GPU utilization.
• Capacity planning in tokens/minuteforecast peak TPM (requests × avg input+output tokens), compare against quota, and decide: raise quotas, add cross-Region inference, or buy Provisioned Throughput (model units) for the guaranteed baseline while on-demand absorbs burst.
• Auto scalingSageMaker endpoint auto scaling on invocations-per-instance or custom (token-based) metrics; scale the surrounding tier (Lambda concurrency, ECS tasks) in step with model capacity so you don't scale your way into throttling.

Caching Strategies

Cache-safety rules: never cache across tenants/permission scopes without scoping the key; set TTLs matched to data volatility; tune the semantic-similarity threshold to avoid wrong-answer cache hits (a too-loose threshold is a correctness bug, not a performance win).

Latency Engineering

• •
  Streaming first — time-to-first-token is the UX metric; stream everything user-facing.
• •
  Latency-optimized inference — Bedrock offers latency-optimized variants for supported models (performanceConfig: { latency: "optimized" }); also simply choosing a smaller model class is the bluntest latency fix.
• •
  Parallelization — fan out independent sub-tasks (retrieve while you classify; generate sections concurrently) and assemble; Step Functions Parallel/Map or async application code.
• •
  Pre-computation — generate likely content ahead of demand (nightly summaries, precomputed embeddings, warmed caches) so runtime work is lookup, not generation.
• •
  Trim synchronous chain hops; co-locate compute and vector store in-Region; keep p95 dashboards per hop (X-Ray) so you optimize the actual bottleneck.

Retrieval Performance Tuning

• Index optimizationHNSW parameter tuning (ef_search/M trade recall vs. speed), right-sized shards, filtered ANN queries using metadata to shrink the search space, smaller embedding dimensions where recall permits.
• Query preprocessingnormalize, spell-correct, expand, and rewrite queries before embedding; cache frequent query embeddings.
• Hybrid scoringtune the lexical:vector weight for your corpus empirically against a labeled relevance set; add a reranker only where its latency budget fits.

FM Throughput, Concurrency, and Inference Parameters

• •
  Match concurrency to quota: token-bucket admission control in front of Bedrock; SQS buffering for burst absorption; per-tenant fair-share limits so one tenant can't consume the pool.
• •
  Inference parameters you must know: temperature (randomness of sampling — low for factual/extraction, higher for creative), top-p (nucleus sampling mass), top-k (candidate cutoff), maxTokens (hard output cap), stop sequences. Adjust temperature or top-p, not both aggressively. Determinism-sensitive tasks (text-to-SQL, extraction): temperature ≈ 0.
• •
  A/B test parameter changes like any release — parameters shift quality, latency (longer outputs), and cost simultaneously; measure all three.
• •
  Resource allocation — dedicate provisioned capacity to premium/critical paths, on-demand for the long tail; tag and budget per workload.

Observability, Monitoring, and Failure-Mode Frameworks

The three-layer observability model:

1. 1Operational metrics (CloudWatch) — invocation count, latency (incl. time-to-first-token), error/throttle rates, token usage per model/app; alarms on p95 latency and throttle spikes; Cost Anomaly Detection + budgets on Bedrock spend.
2. 2Quality metricssampled hallucination rate (LLM-as-judge on production samples), grounding scores, guardrail intervention rate, output-schema failure rate, drift indicators (embedding distribution of incoming queries shifting from the index's distribution).
3. 3Business dashboardsdeflection rate, CSAT, task completion, cost per resolved conversation — the numbers stakeholders actually fund.

Key plumbing: Bedrock model invocation logging (full request/response to CloudWatch Logs or S3 — enable it day one), X-Ray traces across the chain, agent/tool monitoring (per-tool success rate, tool latency, loop counts, per-step traces from Bedrock Agents trace or AgentCore/CloudWatch GenAI observability), and vector store ops (index size, sync-job failures, query latency, recall spot-checks).

Failure-mode analysis framework — when quality regresses: replay a golden dataset against old vs. new configuration, diff the outputs systematically, and use reasoning traces to localize the failing stage (retrieval? prompt? model? tool?). Institutionalize this as a runbook, not an ad-hoc scramble.

Part 5 · Testing, Validation, and Troubleshooting (11%)

Domain 5 closes the loop: proving quality before release and diagnosing failures after. Expect roughly 7 scored questions — heavily scenario-based "what's broken?" items.

Defining and Measuring FM Output Quality

Quality decomposes into measurable dimensions: relevance (answers the actual question), accuracy/faithfulness (factually correct and grounded), consistency (stable answers to equivalent inputs — test with paraphrase sets and repeated runs), fluency/coherence, completeness, and format compliance. Define per-use-case rubrics with thresholds; "the answers look good" is not a metric.

Systematic Evaluation

User-centered evaluation: in-product feedback (thumbs up/down + reason codes), ratings, implicit signals (regenerations, abandonment, copy events), and structured annotation workflows (A2I or internal tools) that turn flagged responses into labeled eval data. Feedback is a pipeline, not a widget.

QA processes: continuous evaluation (scheduled eval jobs on production samples), regression testing (golden dataset must pass before any prompt/model/parameter/KB change ships), and quality gates in CI/CD — a release is blocked if judge scores, grounding rates, or safety block-rates regress beyond tolerance.

RAG and Retrieval Quality Evaluation

Evaluate RAG in two stages, separately:

• Retrieval metricscontext relevance/precision (are retrieved chunks on-topic?), context recall/coverage (is the needed evidence present?), ranking quality (correct chunk in top-k?), and retrieval latency. Build a labeled set of query → relevant-passage pairs.
• Generation metricsfaithfulness/groundedness (claims supported by retrieved context), answer relevance, citation correctness. Bedrock Knowledge Base evaluation jobs score exactly these with LLM-as-judge.

If faithfulness is low but retrieval precision is high → generation/prompt problem. If retrieval recall is low → chunking/embedding/index problem. This decomposition logic is exam gold.

Agent Evaluation

Agents need trajectory-level evaluation, not just final-answer checks: task completion rate on scenario suites, tool-usage correctness (right tool, valid arguments, results actually used), multi-step reasoning quality (efficient path vs. flailing loops — inspect trace events), safety compliance (respected stopping conditions and boundaries), plus cost/latency per completed task. Maintain a simulation harness of end-to-end scenarios with expected outcomes and run it per release.

Stakeholder Reporting and Deployment Validation

• Reporting: translate eval metrics into business terms — quality trend lines, incident counts, cost per interaction, coverage of high-risk categories — on a scheduled cadence with clear go/no-go recommendations.
• Deployment validation: before and during rollout run synthetic user workflows (canaries executing realistic multi-turn journeys against production), measure hallucination rate on sampled real traffic, watch drift (query mix, grounding scores) and consistency (paraphrase-stability), and predefine rollback triggers. Validation is continuous — models, corpora, and users all drift after launch day.

Context Window Troubleshooting

Symptoms of context overflow: ValidationException (input + max output exceeds the model's limit), silently ignored early instructions, degraded mid-context recall ("lost in the middle"), or truncated conversations. Fixes:

• •
  Token-count before invoking; budget context = system + history + retrieved + headroom for output.
• •
  Dynamic chunking / adaptive retrieval — shrink k or chunk sizes when the budget is tight; summarize older conversation turns into a rolling synopsis instead of replaying them verbatim.
• •
  Place critical instructions at the start and restate constraints near the end for long contexts; move stable bulk (policies, schemas) into RAG rather than the prompt.

API and Integration Debugging

Debug by status class, fastest first:

• •
  ValidationException → malformed request body (wrong provider schema on InvokeModel, oversized context, bad parameter ranges).
• •
  AccessDeniedException → IAM policy, model access not enabled in that Region, or a guardrail/inference-profile ARN mismatch.
• •
  ThrottlingException → quota exceeded — check TPM vs. RPM (which limit tripped?), then backoff config, cross-Region profiles, or provisioned capacity.
• •
  ModelTimeoutException / client timeouts → output too long, cold path, or SDK read-timeout shorter than generation time — raise SDK read timeout, stream, or cap maxTokens.
• •
  Silent wrong answers → check invocation logs to see the exact final prompt (the payload the model saw, not the template you think you sent), then trace with X-Ray to find which upstream step corrupted it.

Triage order: CloudWatch alarms → X-Ray trace (which hop?) →
Bedrock invocation logs (what did the model actually receive/return?) →
component-level replay with the golden dataset.

Prompt and Retrieval Troubleshooting; Prompt Maintenance

• Prompt troubleshootingreproduce with fixed parameters (temperature 0) to separate randomness from prompt defects; run version comparison (Prompt Management variants A/B on the same test set); use structured prompt testing frameworks in CI so every template edit is scored before merge.
• Retrieval troubleshootingembedding diagnostics: verify query and corpus use the same embedding model/version (mismatch = mysterious irrelevance); check that new documents actually synced (KB sync job status); test known query→chunk pairs directly against the Retrieve API. Embedding drift: as content or user language shifts, recall decays — schedule recall spot-checks and re-embedding. Chunking issues: answers cut mid-thought → increase chunk size/overlap or go hierarchical.
• Prompt maintenance at scaletemplate testing suites per prompt; CloudWatch metrics per prompt version (latency, tokens, judge scores) to spot regressions; X-Ray to attribute latency to prompt growth; schema validation on model outputs (reject-and-retry on invalid JSON) so downstream systems never ingest malformed generations.

Exam-Day Checklist

Domain 1 — FM Integration, Data, Compliance (31%)

• •
  Escalation ladder: prompt → RAG → agent → fine-tune; cheapest that meets the requirement wins.
• •
  Cross-Region inference profiles = managed throttling/resilience fix; AppConfig = model/prompt switch without redeploy.
• •
  LoRA = cheap multi-variant customization; Model Registry + alias rollback for custom models; fine-tuned Bedrock models need Provisioned Throughput.
• •
  Vector store mapping: KB = managed; OpenSearch = hybrid at scale; pgvector = SQL + vectors; DynamoDB = metadata only.
• •
  Hierarchical chunking for context-vs-precision; re-embed everything on embedding-model change; hybrid search + reranker for precision.
• •
  Prompt Management versions + regression tests; Flows for visual chaining, Step Functions for heavy orchestration.

Domain 2 — Implementation and Integration (26%)

• •
  Strands = code-first agents; Agent Squad = multi-agent routing; MCP = tool interoperability standard; AgentCore = managed agent runtime.
• •
  Agent safety = iteration caps + timeouts + per-tool least-privilege IAM + HITL (waitForTaskToken/A2I) on irreversible actions.
• •
  Tools: Lambda for stateless/short; ECS/Fargate for stateful/long-running MCP servers.
• •
  Deployment: on-demand (spiky), provisioned (sustained/custom models), batch (offline, ~half price), SageMaker (self-managed/open weights).
• •
  Transport: streaming SSE/WebSockets for chat; SQS for async bulk; backoff + jitter + fallback chain + X-Ray always.
• •
  GenAI gateway = multi-team access control, quotas, cost attribution, central guardrails.

Domain 3 — Safety, Security, Governance (20%)

• •
  Know all six Guardrails policy types; ApplyGuardrail for non-Bedrock models; contextual grounding checks vs. hallucination.
• •
  Text-to-SQL: parameterized, allow-listed, read-only — never raw LLM SQL.
• •
  Everything in the context window is untrusted — including RAG chunks and tool output.
• •
  Macie (find PII in S3) vs. Comprehend (detect/redact in text) vs. Guardrails PII filters (block/mask at model boundary).
• •
  VPC endpoints + KMS + scoped IAM + Lake Formation for protected data paths; CloudTrail (access audit) + invocation logs (content audit) + model cards (documentation).

Domain 4 — Operational Efficiency (12%)

• •
  Cost levers ranked: route to smaller models, shrink tokens, prompt caching, batch inference, semantic caching.
• •
  Prompt caching = repeated prefixes; semantic caching = paraphrased repeat questions — never confuse them.
• •
  Capacity in tokens/minute; provisioned baseline + on-demand burst; temperature ↓ for deterministic tasks.
• •
  Enable invocation logging day one; alarm on p95, throttles, token spend, guardrail-block spikes; golden-dataset diffing for regressions.

Domain 5 — Testing, Validation, Troubleshooting (11%)

• •
  Canonical eval stack: golden datasets + LLM-as-judge + CI quality gates + canary rollout.
• •
  Evaluate RAG in two stages: retrieval metrics vs. generation faithfulness — the split localizes the fix.
• •
  Error map: Validation = malformed/oversized; AccessDenied = IAM or model access; Throttling = quota; Timeout = generation length/SDK timeout.
• •
  Retrieval gone wrong: same embedding model both sides? sync jobs green? chunk boundaries sane?
• •
  Reproduce at temperature 0 before blaming the prompt; read the invocation log to see what the model actually received.

Official Resources

• Official AIP-C01 Exam Guidethe authoritative domain/task list; re-read it in your final week and self-rate every task statement: aws.amazon.com/certification/certified-generative-ai-developer-professional/
• AWS Skill BuilderAIP-C01 Exam Prep learning plan, Official Practice Question Set, and Official Pretest; the practice set mirrors real scenario style.
• Amazon Bedrock documentationuser guide + API reference for Converse, Knowledge Bases, Agents, Guardrails, Flows, Prompt Management, and model invocation logging: docs.aws.amazon.com/bedrock/
• AWS Well-Architected Generative AI Lensthe design-principles source the scenarios are written from.
• Strands Agents documentation (strandsagents.com) and the Agent Squad GitHub repository — read the concepts pages; the exam names both.
• Model Context Protocol specification (modelcontextprotocol.io) — client/server/tool concepts.
• AWS Machine Learning BlogBedrock architecture patterns, GenAI gateway, and RAG evaluation posts frequently prefigure exam scenarios.

Train on real systems, reason from constraints, and eliminate over-engineered answers — that is how this exam is passed. Good luck.