A few days ago, I passed the AWS Certified Generative AI Developer – Professional (AIP-C01) exam. I want to share what I actually learned during preparation — not just a list of topics, but the reasoning patterns that this exam really tests.
I am a Technical Architect and an AWS Community Builder. I also teach cloud topics at universities in Colombia. So I came into this exam with both practical experience and teaching experience. But this exam still surprised me several times. That is exactly why I am writing this article.
What Kind of Exam Is This?
This is not a memorization exam. You will not pass by listing Amazon Bedrock services. The exam tests whether you can reason about trade-offs in real architectures.
Almost every question has a specific constraint that eliminates most of the options. Your job is to find that constraint first.
The question types I encountered most often:
- «Which solution meets these requirements with the LEAST operational overhead?»
- «Which solution will meet these requirements?» (with a hidden technical trap in the wrong answers)
- «Which combination of steps will meet these requirements? (Choose two.)»
What the Exam Actually Covers
Before you build a study plan, it helps to know where the exam actually spends its questions.
Traditional Machine Learning: Almost Zero
If you have experience with classic ML, you might expect questions about confusion matrices, precision and recall, training pipelines, or feature engineering. I did not see any of that. Other candidates report the same thing. The exam is about building AI applications with AWS services, not about training ML models from scratch.
Do not spend significant time reviewing traditional ML metrics or SageMaker training workflows. That time is better spent elsewhere.
RAG and Vector Search: Heavily Featured
This is the core of the exam. Almost every scenario involves Retrieval-Augmented Generation in some form. The exam tests:
- Chunking strategies — fixed-size vs. semantic vs. hierarchical, and when each one is appropriate
- Vector database selection — when to use OpenSearch, pgvector on Aurora, or MemoryDB, and why scale matters for this decision
- Document ingestion — how to sync S3 content with Amazon Bedrock Knowledge Bases, and what happens when data changes frequently
- Embedding model choice — Amazon Titan Embeddings vs. other options and the operational trade-offs
If you understand RAG deeply, you will recognize the right answer in a large portion of the exam questions.
Orchestration and Observability: Always Present
The «glue» services appear in nearly every architecture:
- AWS Step Functions — how to orchestrate multi-step AI workflows, when to use Standard vs. Express, and how to build retry and fallback logic
- AWS Lambda — as a resolver, a pre-processing filter, or a bridge between services
- Amazon OpenSearch Service — for hybrid search (vector + keyword) and log analytics
- Amazon CloudWatch — for invocation metrics, custom metrics, anomaly detection, and alarms
These are not standalone questions. They appear inside complex scenarios where you must choose the right combination.
The Four Patterns That Repeat Constantly
After working through dozens of practice questions, I noticed that most of them test the same four ideas in different contexts.
1. Proactive vs. Reactive
This pattern appeared more than any other. The question gives you a system that needs to prevent something from happening, and the wrong answers only detect or react after it already happened.
For example: a token management system that must «proactively alert when applications approach model-specific token limits.» The correct answer estimates token usage before sending the request to Amazon Bedrock. Three of the four options fire only after a failure already occurred — after a request was rejected, after a call failed, or after a limit was exceeded.
The rule: If the requirement says «proactively,» eliminate every option that reacts to failures.
2. Sequential vs. Parallel
When a question asks for performance under latency constraints, check whether the options process things one after another or at the same time.
A real example: a system that processes 50 GB of call recordings and must finish within 4 hours. The correct solution uses AWS Step Functions with a Distributed Map state, which can run up to 10,000 parallel workflows over S3 objects. A Lambda-only solution would hit the 15-minute timeout. A sequential workflow would miss the 4-hour window.
The rule: Tight latency or throughput requirements almost always require parallelism, not just faster sequential processing.
3. The Right Tool for the Right Data Type
This one eliminated me on a few questions early in my preparation.
- Amazon Bedrock Knowledge Bases is for unstructured documents (PDFs, text, HTML). It is not for relational data.
- Text-to-SQL is the right approach for structured data in Amazon RDS. You do not embed relational tables into a vector store.
- IVFFlat works for medium-to-large datasets. It cannot meaningfully partition a small dataset into clusters.
- Flat algorithm (exact brute-force search) is correct for small datasets where 100% recall matters more than search speed.
- HNSW is for large datasets where approximate search is acceptable.
I was selecting OpenSearch for everything because I associated it with «vector search.» But the exam cares about scale. For fewer than a million records, Aurora Serverless with pgvector is often the right answer because of lower operational overhead.
4. Least Operational Overhead — What It Actually Means
This phrase appears in nearly half the questions. I learned to read it as: «Which solution adds the fewest services that you need to manage yourself?»
The exam consistently penalizes options that:
- Require provisioning a cluster (OpenSearch, EMR, SageMaker endpoints)
- Need Lambda functions to do something a managed service already does natively
- Use EventBridge + custom code when Step Functions can orchestrate declaratively
- Build a custom pipeline when Bedrock’s RetrieveAndGenerate API already handles retrieval, generation, and citation in one call
When I saw «least operational overhead,» I immediately looked for fully managed, serverless options. That eliminated most wrong answers before I even read them carefully.
Where I Made Mistakes
Confusing Audit Tools with Safety Tools
AWS CloudTrail records who called which API and when. It does NOT capture what content was blocked by a guardrail or why. If a question asks for «audit trails of all safety interventions,» the answer is Amazon CloudWatch with custom metrics, not CloudTrail.
I missed this distinction twice before it became obvious.
Thinking Step Functions Express Was Better for «Performance»
Express Workflows handle higher throughput than Standard Workflows. So when a question mentioned «thousands of concurrent users,» I chose Express.
But one question required a Wait for Callback pattern — the system pauses execution waiting for a human response, which could take minutes. Express Workflows have a 5-minute maximum duration. They cannot durably pause.
Standard Workflows support exactly-once execution, long durations, and Wait for Callback. The performance advantage of Express Workflows is irrelevant if the workflow needs to wait.
Selecting Architectures with Fabricated Features
Some wrong answers describe AWS features that do not exist.
I found these in real practice questions:
- «S3 action nodes in Amazon Bedrock Flows» — Bedrock Flows has no native S3 nodes
- «Amazon Bedrock Guardrails with token quota policies» — Guardrails enforces content safety, not token budgets
- «Cross-Region guardrail replication» — not a real Bedrock feature
- «CloudTrail distributed tracing» — CloudTrail is an audit log, not a tracing tool (AWS X-Ray is)
The rule: If an option describes a service doing something that sounds slightly off, take a moment to verify whether that feature actually exists. The exam includes distractors that combine real services with invented capabilities.
The Service Boundaries You Must Know
Several questions came down to knowing what a service cannot do, not what it can do.
Memorizing this table saved me at least five questions.
One Thing That Changed During Preparation
In November 2025, AWS announced that Amazon API Gateway REST APIs now support Lambda response streaming. Before this, streaming responses required Lambda Function URLs or other approaches.
This matters because the exam now has questions where REST API is the correct answer specifically because of streaming support — and HTTP API is not supported for this.
The lesson: Check the announcement date of features if something in the answers seems inconsistent with what you learned before. The exam reflects the current state of AWS services.
How I Prepared
I combined several approaches, and the order in which I used them mattered.
Start with a Course for Breadth
Courses by Stéphane Maarek and Frank Kane on Udemy are commonly recommended in the AWS certification community, and for good reason. They give you a clear map of the service landscape and help you understand how the pieces connect.
But candidates who rely only on a course tend to struggle with the harder scenario questions. The courses show you what services exist. The exam tests whether you know which one to use when two options both seem reasonable. For that, you need the documentation.
My recommendation: Use a course to build your mental model, then go deeper on the services that appear most frequently — Bedrock, Step Functions, OpenSearch, and Lambda.
Use AWS Skill Builder for Patterns, Not Just Practice
The official practice exams from AWS Skill Builder are worth doing, but not just to check your score. They are valuable because they show you the style of question the exam uses and the level of specificity the wrong answers have.
The hands-on builder labs are also useful. Working with the Bedrock API directly — even simple calls — helps you understand what the service actually does vs. what sounds plausible in an answer option.
Use AI to Break Down Question Logic
Many candidates, including myself, used tools like Claude or Gemini to study more effectively. Not to get answers, but to understand reasoning.
My approach was to paste a practice question and ask: «Why is this option wrong? What specific AWS limitation eliminates it?» This helped me identify service boundaries faster than reading documentation alone. When I got a question wrong, I used this to build a clear explanation that I could actually remember — not just the correct letter, but the technical reason.
This matters more than it sounds. The exam has 75 questions in roughly three hours. You do not have time to reason from scratch on every one. You need internalized patterns.
Final Advice
If I had to summarize the exam preparation in three sentences:
Find the decisive constraint in each question before you evaluate the options. Most questions have one requirement that eliminates two or three options immediately. The real comparison is between the one or two options that survive.
Know what each AWS service cannot do. The wrong answers are wrong because they use a real service for something it was not built for.
«Least operational overhead» is not about simplicity — it is about how many things you have to manage yourself. A solution with two fully managed services beats a solution with four services where one requires cluster management.
The exam is not easy. But it is fair. If you understand the trade-offs, you will recognize the right answer even in a question you have never seen before.
If you found this useful or have questions about specific topics, feel free to connect with me. I am always happy to discuss AWS architecture. LinkedIn
Related Post How I Passed the AWS Machine Learning Associate Exam: Real Questions, Real Lessons – Analisys.co
