The AWS Certified Generative AI Developer — Professional exam (AIP-C01) is among the first professional-level certifications focused entirely on building production GenAI systems on AWS. This is not a survey course in machine learning, nor a prompt-engineering quiz. The exam tests your ability to make architectural and operational decisions under realistic constraints — latency budgets, compliance regimes, cost ceilings, accuracy thresholds, and vendor trade-offs.

This guide is structured to mirror that decision-making muscle. Every chapter follows the same rhythm: concept first, then services, then decision framework, then practice. You will not find encyclopedic dumps of every AWS feature. You will find the features the exam actually probes, organized so you can recall them under time pressure. Along the way you’ll meet a small set of recurring visual primitives — mental-model figures, service spotlight cards, comparison tables, decision lists, and code-compare panes — that earn their place by carrying the highest-leverage decisions of each chapter.

Who this guide is for

AIP-C01 is a professional-level certification. The content of this book is correspondingly intermediate to advanced and assumes you have already built or shipped at least one cloud application on AWS — you have used IAM, VPCs, S3, Lambda, CloudWatch, and at least one compute or container service in anger — and that you have hands-on familiarity with at least one large language model and a basic understanding of how vector retrieval and embeddings work.

If you are entirely new to AWS or to generative AI, start with the AWS Cloud Practitioner and AI Practitioner certifications first; this guide will move faster than is comfortable for absolute beginners. We will not stop to explain what an S3 bucket is, what an IAM role looks like, what a VPC endpoint does, or what a foundation model is — the exam doesn’t and neither do we.

You are likely:

• A backend or platform engineer with several years of AWS experience, now integrating foundation models into production systems.
• An ML engineer with classical-ML background expanding into generative workloads.
• A solutions architect needing to defend GenAI design choices to security, finance, and product stakeholders.
• A consultant who needs to walk into client conversations with current, exam-grade fluency in the AWS GenAI stack.

Treat anything that lands as “new to me, but I’ve seen the building blocks” as the target reading level. If a chapter feels like it’s assuming things you’ve never touched (a VPC endpoint policy, a SageMaker endpoint, a Lambda execution role), pause — build the missing block in the console for half an hour — then come back. The exam is hands-on by design; the book is hands-on by design.

How to read this book

Each chapter is self-contained and can be read in isolation, but the parts build on each other. Domain 1 establishes vocabulary. Domain 2 covers integration patterns that the rest of the book assumes. Domains 3, 4, and 5 each focus on a non-functional concern: safety, efficiency, and quality. The pattern within each chapter is consistent:

Three callout types appear throughout. Read them — they carry the highest density of exam-relevant material:

A nine-week study plan

The plan below assumes about 10–12 hours per week of focused study. If you have more, accelerate; if you have less, stretch the schedule and prioritize Weeks 1, 4, and 9.

What this guide is not

This is not an AWS service catalog, not a Python tutorial, and not a substitute for hands-on practice. Where source material includes long code listings, we have summarized the conceptual takeaway and pointed you to AWS documentation for current SDK syntax. Treat the official AWS documentation as canonical for any code you intend to ship. The Back Matter sections (Exam Strategy, Glossary, Cheat Sheets) are where the book’s decisions distill into something you can re-read in the fifteen minutes before the test — budget time for them.

A note from the author

I wrote this guide for myself first. I was preparing for the AIP-C01 exam in early 2026 and could not find a study resource that combined the depth I needed with the structure my brain wanted — concepts, then services, then decision frameworks, then drills, with no padding. So I built one. I sat the exam, I passed, and the material in your hands is the same material I used to get there.

This is not an official AWS publication, and it is not a replacement for hands-on practice or for the AWS documentation. It is an opinionated, decision-oriented study guide — a real candidate’s playbook rather than a marketing document. If it helped me pass, I’m confident it can help you pass too.

Good luck. Now: open Part I, brew something hot, and let’s begin.

The AWS Certified Generative AI Developer — Professional exam (code: AIP-C01) is a 180-minute, scenario-driven examination consisting of 100 questions — 85 scored and 15 unscored. You won’t be told which are which; treat them all as scored. It’s delivered through Pearson VUE testing centers and as an online proctored exam, and it carries a recommended prerequisite of two or more years of hands-on experience designing and operating GenAI workloads on AWS.

You do not need to memorize service quotas or current pricing. You do need to be able to look at a multi-paragraph scenario — complete with constraints, red herrings, and competing priorities — and pick the architecture that satisfies the requirements at the lowest reasonable cost and operational burden.

Domain weightings

Five domains are weighted as follows. The percentages are official AWS guidance; treat them as your study budget allocator.

Question formats

The exam uses three question formats. Knowing the difference matters because the marking rules differ.

1. Multiple choice — one stem, four options, exactly one correct answer. The most common format.
2. Multiple response — one stem, five or more options, two or three correct answers. Partial credit is not awarded; you must select the exact correct subset.
3. Scenario / case study — a long preamble (architecture diagram, customer requirements, constraints) followed by 2–4 dependent questions. Read the preamble carefully before starting; the same setup feeds multiple questions.

Passing standard

The reported passing score is approximately 750 / 1000, but AWS uses a scaled scoring model with statistical equating. Aim for ≥ 80% on practice exams to be comfortable on test day. Score reports break results down by domain (“Meets Competencies / Needs Improvement”); use those to direct your final review week.

Time budget

180 minutes for 100 questions = ~1:48 per question average. In practice, scenario questions consume 3–5 minutes each, while plain multiple-choice items can be answered in under a minute. Use the in-exam Flag for Review feature liberally; first-pass anything you cannot answer in 90 seconds, finish the easy questions, and circle back. Back Matter A (Exam Strategy) walks the full five-pass pacing plan in detail.

What the exam loves to test

Across all five domains, expect heavy emphasis on these decision pivots. These are the seams where two services overlap and the “right” answer depends on a single qualifier in the question:

• Bedrock vs. SageMaker JumpStart vs. self-hosted — managed convenience vs. customization vs. control.
• RAG vs. fine-tuning vs. continued pre-training — data freshness, knowledge depth, cost.
• Amazon Bedrock Knowledge Bases vs. Kendra vs. raw OpenSearch — managed vs. document ACLs vs. flexibility.
• On-demand vs. provisioned throughput vs. batch inference — latency, cost, predictability.
• Bedrock Agents vs. custom orchestration with the Converse API — managed vs. flexible.
• Bedrock Guardrails vs. application-level filters vs. Amazon Comprehend — safety surface area.

Each of these pivots gets its own decision framework in the chapters that follow.

1.1 · Is this even a GenAI problem?

The most expensive mistake in generative AI is using a foundation model where a regular expression would do. Before you reach for Bedrock, work through a four-question checklist. If you cannot answer yes to at least three, your problem belongs to traditional ML, classic search, or simple business logic. The exam punishes over-engineering.

1. Does the task require language understanding, generation, or transformation? — summarization, drafting, translation, intent extraction. If the answer is “classification with structured features,” reach for Amazon SageMaker or Amazon Comprehend instead.
2. Is the input variable, unstructured, or open-ended? — free-form support tickets, PDFs, conversational queries. Foundation models excel at variability.
3. Can the system tolerate probabilistic output? — if every response must be 100% accurate (think: tax calculations, medical dosages), you need a deterministic system underneath, with the LLM only as an orchestrator.
4. Is sufficient context obtainable? — either through prompts, retrieval, or fine-tuning. If the answer lives in a database the model cannot reach, no amount of prompting will help.

Common GenAI use case categories

The AIP-C01 exam organizes GenAI use cases into five categories. Memorize the canonical AWS service for each — questions often hide the use case in a verb (“summarize”, “classify”, “generate”) rather than name it directly.

1.2 · Functional & non-functional requirements

Once you have decided GenAI is appropriate, the requirements analysis you would do for any system splits into three buckets. The exam is unusually fond of latency / cost / compliance trade-offs, so each row in the table below is a likely question seam.

Functional requirements

What the solution must accomplish. For foundation-model workloads this includes: input modalities (text, images, audio, documents); expected output format and grounding requirements; required domain knowledge; integration points; and the interaction pattern (synchronous chat, streaming, batch). One requirement matters most: does the app need multi-turn conversational state? If yes, you need session management. If no, a stateless InvokeModel call works.

Non-functional requirements

Latency, throughput, cost, availability, security, and compliance. These usually determine the architecture rather than influence it.

1.3 · The five canonical AWS GenAI patterns

Almost every architecture the exam asks you to design is a composition of these five patterns. Memorize their trigger conditions; the exam phrases scenarios specifically so that exactly one pattern fits.

Pattern 1 · Direct API integration

The simplest pattern: your application calls InvokeModel or Converse on Amazon Bedrock, the foundation model returns a response, and your code post-processes it. Conversation state lives in your application layer (DynamoDB, ElastiCache, or memory). Compute is typically AWS Lambda or a container on Amazon ECS / EKS.

Use this pattern when the model’s training data is sufficient knowledge for the task — summarization, translation, brainstorming, generic Q&A, classification of free-text input. The moment you need your data in the response, you graduate to RAG.

InvokeModel vs. Converse — the same call, two eras. The older InvokeModel API requires a model-specific JSON body. Anthropic, Meta, and Cohere expect different shapes. Swapping models means rewriting the request. The newer Converse API normalizes that — one request shape, one response shape, across every Bedrock-hosted model. Use Converse for anything new; treat InvokeModel as legacy.

import boto3, json

bedrock = boto3.client("bedrock-runtime")

# Anthropic-specific body shape — different
# for Llama, Cohere, Titan, etc.
body = {
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 512,
    "messages": [
        {"role": "user",
         "content": "Summarize CRISPR in 3 lines."}
    ],
}

resp = bedrock.invoke_model(
    modelId="anthropic.claude-3-5-sonnet-20240620-v1:0",
    body=json.dumps(body),
    contentType="application/json",
)

# Parse model-specific response shape
data = json.loads(resp["body"].read())
print(data["content"][0]["text"])

import boto3

bedrock = boto3.client("bedrock-runtime")

# Same shape works for Claude, Llama, Nova,
# Cohere, Mistral — swap modelId only.
resp = bedrock.converse(
    modelId="anthropic.claude-3-5-sonnet-20240620-v1:0",
    messages=[
        {"role": "user",
         "content": [{"text": "Summarize CRISPR in 3 lines."}]}
    ],
    inferenceConfig={"maxTokens": 512},
)

# Uniform response shape
text = resp["output"]["message"]["content"][0]["text"]
print(text)
# resp["stopReason"] tells you why generation ended
# resp["usage"] gives input/output token counts

Pattern 2 · Retrieval-Augmented Generation (RAG)

RAG is the dominant enterprise pattern. The workflow: embed the user query, search a vector store for relevant chunks, splice the retrieved text into the prompt, then call the foundation model. The model now “knows” about your private data without ever being trained on it.

RAG is the right answer when the source-of-truth changes more frequently than you can retrain a model (most enterprise data), when you must cite sources, or when the corpus is too large to fit in any context window. Two implementation paths:

• Managed RAG — Amazon Bedrock Knowledge Bases handles ingestion, chunking, embedding, and retrieval. Lowest operational overhead. Choose this unless you need something it does not do.
• Custom RAG — you build the pipeline yourself using Amazon OpenSearch Service (or Aurora pgvector), Bedrock embedding models, and your own orchestration. Choose this when you need fine control over chunking, hybrid search, custom metadata filtering, or non-AWS vector databases.

Pattern 3 · Agents and tool use

An agent extends a foundation model with the ability to take actions. The model decides which function to call, supplies arguments, the function executes (a Lambda function, an API call, a database query), the result is fed back, and the agent decides what to do next. This loop continues until the agent has enough information to respond.

Amazon Bedrock Agents wraps this with managed orchestration: you define an instruction, register action groups (Lambda functions or OpenAPI schemas), optionally attach knowledge bases, and Bedrock handles the reasoning loop. For more flexibility, build a custom agent on top of the Bedrock Converse API’s tool-use feature.

Pattern 4 · Fine-tuning & custom models

Fine-tuning adapts a foundation model’s weights using your data. Reach for it when prompting and RAG cannot achieve the consistency you need — specialized output format, domain vocabulary, or brand voice. Bedrock supports continued pre-training and fine-tuning for select models; SageMaker JumpStart offers more model choice and full training control.

Pattern 5 · Multi-model & ensemble

A small classifier routes traffic to a large generation model only when needed; an embedding model handles search, while a generation model handles synthesis; multiple models propose answers and a judge selects the best. Bedrock’s unified API makes this trivial to compose — you can call Claude, Titan, and Stable Diffusion from one application without managing three SDKs.

1.4 · Cost optimization at design time

Cost is decided at the architecture stage, not at the bill stage. Three levers dominate.

1. Right-size the model. The largest model is rarely the right model. Try the smallest capable model first, measure quality, escalate only if needed. A factor-of-10 cost differential between Nova Micro and Claude Opus is typical.
2. Pick the right inference mode. On-demand pricing for variable workloads, provisioned throughput for predictable steady traffic, batch inference for offline workloads (up to 50% cheaper). Mismatched mode is the #1 cause of bill shock.
3. Cache aggressively. Bedrock prompt caching reuses repeated system prompts at a discount. Application-level caching of identical queries can eliminate 20–60% of inference calls. Semantic caching (vector-similarity match on prior queries) extends this further.

1.5 · The Well-Architected GenAI lens, in summary

AWS Well-Architected gains one dimension for GenAI: Responsible AI. It threads across the existing six pillars rather than replacing them.

Chapter summary

Designing GenAI is choosing the right tool, the right pattern, and the right model for the constraints in front of you.

• GenAI fit first — validate that GenAI is the right tool before designing. Not every problem needs a foundation model.
• NFRs → AWS levers — map latency, cost, and compliance onto specific services. Compliance usually eliminates options first.
• Five core patterns — Direct API, RAG, Agents, Fine-Tuning, Multi-Model. Almost every workload is one of these.
• Pattern triggers — RAG when knowledge is external or fresh; Agents when the system must take action; Fine-Tuning is the last resort, not the first.
• Cost is architectural — right-size the model, pick the right inference mode, cache. Decided at design time, not after launch.
• Well-Architected + Responsible AI — weave the Responsible AI thread across all six pillars.

The exam rewards architecture-time decisions; it punishes ‘biggest model on every problem’.

2.1 · The Bedrock model landscape

Amazon Bedrock is a managed surface for foundation models from Anthropic, Meta, Amazon Nova, Mistral, Cohere, AI21, DeepSeek, Writer, and Luma. You do not provision GPUs. You do not manage weights. You call an API. The exam expects you to know each family’s sweet spot — well enough to pick from four choices under time pressure.

2.2 · The selection trade-off — one mental model, four axes

Every model selection question collapses into four axes. The exam phrases scenarios so that one axis dominates — identify it, and the answer falls out.

2.3 · Inference parameters that actually matter

Bedrock’s Converse API exposes the same handful of inference parameters across every provider. Most candidates can name them. Few can predict what changes when you turn each one. The exam loves this gap.

Configuring inference with the Converse API

import boto3, json

bedrock = boto3.client("bedrock-runtime")

resp = bedrock.converse(
    modelId="anthropic.claude-3-5-haiku-20241022-v1:0",
    system=[{"text":
        "Extract entities as JSON. "
        "Output ONLY valid JSON, no prose."}],
    messages=[{
        "role": "user",
        "content": [{"text": ticket_text}],
    }],
    inferenceConfig={
        "temperature": 0.0,    # tight
        "topP": 0.1,          # narrow vocab
        "maxTokens": 512,     # hard ceiling
        "stopSequences": ["\n\n"],
    },
)
data = json.loads(resp["output"]["message"]
                  ["content"][0]["text"])

import boto3

bedrock = boto3.client("bedrock-runtime")

resp = bedrock.converse(
    modelId="anthropic.claude-3-5-sonnet-20240620-v1:0",
    system=[{"text":
        "You are a senior product marketer. "
        "Write in a direct, energetic voice."}],
    messages=[{
        "role": "user",
        "content": [{"text":
            "Draft 3 launch taglines for a "
            "developer-focused vector database."}],
    }],
    inferenceConfig={
        "temperature": 0.8,    # exploratory
        "topP": 0.95,
        "maxTokens": 800,
    },
)
print(resp["output"]["message"]
     ["content"][0]["text"])

2.4 · Inference modes — on-demand, provisioned, batch

Once you have picked a model, you pick how Bedrock serves it. The three modes map cleanly to three traffic shapes, and the exam will give you the traffic shape and ask which mode fits.

2.5 · Squeezing cost without losing capability

Once a model is in production, three levers move the needle far more than swapping providers: prompt caching, model cascading, and distillation.

Prompt caching

Bedrock can cache long, repeated prompt prefixes (system instructions, retrieved-context windows, few-shot examples). A cache hit bills those tokens at a steep discount. For most RAG workloads, that is 60–90% off input tokens at zero quality cost. Mark cache breakpoints explicitly via the cachePoint content block in Converse.

Model cascading (router pattern)

Send every request first to the cheapest model that might succeed. If a confidence check fails (low logprob, schema-validation error, explicit “I am not sure”), retry on a larger model. A common pattern: Haiku → Sonnet → Opus, with ~80% of traffic terminating at Haiku.

Distillation & fine-tuning for a smaller model

Frontier model meets quality, cost does not? Distill. Collect (input, frontier-output) pairs, then fine-tune a smaller model via Bedrock Custom Models or SageMaker. You trade one-time training cost for ongoing inference savings.

Chapter summary

Model selection on AWS is a two-axis choice: family from the workload, tier from the dominant constraint.

• Two-axis selection — family from workload type; tier from dominant constraint (latency, cost, capability, or context).
• Mid-tier default — Sonnet / Nova Pro / Llama 70B. Step down or up only when a measurable signal forces it.
• Platform — Bedrock for serverless API access; SageMaker JumpStart when you need full control over the endpoint.
• Inference parameters — set temperature, maxTokens, and system on every call. Tune top_p only when low temperature alone is not tight enough.
• Throughput modes — on-demand for spiky; provisioned for steady-and-large; batch for offline. Cross-region profiles lift the ceiling without re-architecting.
• Cost optimization order — prompt caching → model cascading → distillation. Stop at the first rung that meets your budget.

The exam rewards picking the smallest model that meets the bar; it punishes ‘always Opus’.

If the first two chapters earned the time you spent on them, the rest of the book is built the same way: decision-oriented, service-by-service, grounded in the exam’s twenty task statements. Below is what each format gets you and where to pick one up.

How the full edition continues

• Part I — Foundation Models (Chapters 1–6): you’ve seen 2 of 6. The remaining four cover Data Pipelines, Vector Stores, Retrieval (RAG), and Prompt Engineering.
• Part II — Implementation (Chapters 7–11): Bedrock vs SageMaker selection, Knowledge Bases, Agents, model evaluation, and deployment patterns.
• Part III — Security & Governance (Chapters 12–15): IAM scoping, Guardrails, PII redaction, and compliance.
• Part IV — Optimization (Chapters 16–18): cost, performance, monitoring.
• Part V — Evaluation & Troubleshooting (Chapters 19–20): metrics, drift, incident response.
• Back matter: 9-week study plan, glossary, exam-day cheat sheets.

Pick the format that fits

Was the demo useful?

If a service comparison felt thin, a decision table missed a corner case, or you spotted a fact that needs updating — write to press@minecloudcraftpress.com. Field reports from candidates studying for the exam are the only thing that keeps this guide honest. Replies usually land within 48 hours.

MineCloudCraft Press is the publishing arm of MineCloudCraft — an independent practice covering consultancy, training, and mentoring for teams building production AI on AWS. Back to MineCloudCraft Press →