Amazon AWS AIP-C01: Study Plan

AWS Certified Generative AI Developer – Professional requires a study plan that combines current exam objectives with production-style implementation. Amazon AWS AIP-C01 is a 180-minute, 75-question professional exam, and AWS expects significant application-development experience plus hands-on GenAI implementation. That makes a purely video-based plan too shallow.

The strongest sequence is assess → build foundations → implement one integrated GenAI system → deepen weak domains → practice diagnosis → finish with mixed exam-style review.

Week 0 — run a prerequisite audit

Before scheduling a long study plan, assess AWS architecture, software development, IAM/security, APIs, deployment/IaC, observability, data, and GenAI experience.

The AIP-C01 professional scope assumes working knowledge of AWS identity and API controls; a weak IAM or deployment baseline will undermine even a sound GenAI design.

If basic AWS networking, IAM, Python/SDK usage, or production debugging is weak, repair it before spending weeks memorizing GenAI services.

Rate each prerequisite by evidence: can explain, can build, can troubleshoot. AWS networking or IAM that is only familiar from diagrams may still be too weak for professional GenAI integration.

Choose a realistic study duration from the gaps. A professional exam should not be compressed into an arbitrary calendar if core software or cloud foundations are missing.

Set up the AWS account, budget alarms, source repository, and lab guardrails before the project begins.

Set a cost limit for the lab account and enable billing alerts before experimentation. GenAI services can create spend quickly when loops, large context, or repeated evaluations are uncontrolled.

Choose one programming language and one infrastructure/deployment approach for the plan so time is spent learning GenAI engineering rather than switching toolchains.

Choose a realistic weekly time budget that leaves room for work and rest; consistency over several weeks is more valuable than one intense study burst followed by burnout.

Weeks 1–2 — learn the five domains as one architecture

Read the official guide and map 31/26/20/12/11 weighting to a single conceptual GenAI application.

Identify where foundation-model selection, data/RAG, implementation, security, optimization, evaluation, and troubleshooting would appear in that system.

Create a glossary only for concepts you cannot already explain. Avoid turning the first two weeks into service-name memorization.

Create a domain-to-project matrix with one row per exam task and one column for where it appears in the capstone.

Read AWS docs selectively around the architecture rather than consuming entire service manuals without context.

At the end of week 2, explain the five domains from memory and identify which ones still feel abstract.

Create a one-page architecture and annotate which domain owns each concern. Data and model selection belong mainly to Domain 1; implementation to Domain 2; controls to Domain 3; cost/performance to Domain 4; evaluation and failure to Domain 5.

Review the diagram after each study week and update it as your understanding improves.

Weeks 3–4 — build foundation-model and RAG depth

Practice selecting models against quality, latency, cost, context, and modality requirements.

Build or diagram a RAG workflow with ingestion, chunking, embeddings, vector storage, retrieval, prompt construction, model invocation, and citations.

RAG implementation for AIP-C01 should be paired with a small build so the concepts are observable.

Evaluate at least two model choices against the same small test set so model selection becomes evidence-based.

Change chunk size or retrieval settings and observe how answer quality changes. This makes RAG tuning more concrete than reading best-practice lists.

Add document-level authorization early so security is built into retrieval rather than postponed.

Add metadata filtering and authorization to the retrieval design rather than testing only public documents.

Create a small labeled retrieval set and measure whether the correct evidence appears before optimizing the generated answer.

Change one variable at a time—chunking, embeddings, reranking, prompt—so you can tell which change improved the system.

Weeks 5–6 — implement APIs, prompts, agents, and integrations

Use SDK or API calls instead of relying only on console workflows. Manage prompts, structured outputs, retries, errors, and application state.

Add a simple tool or agent workflow. Define the tool schema, identity, permissions, validation, and recovery when one step fails.

Version code and configuration so changes can be compared and rolled back.

Add structured output and validate it in application code. Then introduce a malformed response and confirm the application fails safely.

Use a tool with low consequence first, then add an approval boundary before any higher-impact action.

Instrument requests so you can see model latency, tool latency, retries, and errors across the workflow.

Add application-side validation to every tool input and one transaction limit for any action that changes external state.

Practice retry and timeout behavior. A professional system should not hang indefinitely or repeat irreversible actions because one API call failed.

Add correlation IDs across model and tool calls so troubleshooting can reconstruct the request.

Week 7 — focus on AI safety, security, and governance

Threat-model the application. Include user input, retrieved documents, model, vector store, identities, logs, tools, external APIs, and sensitive data.

Review prompt injection, excessive agency, data leakage, least privilege, responsible AI, evaluation, guardrails, logging, and approval boundaries.

AIP-C01 security and governance should be converted into test cases, not policy flashcards.

Run prompt-injection and indirect-injection tests. Include malicious retrieved content, not only malicious user input.

Review IAM and secrets with least privilege. Remove broad development permissions that are not needed by the runtime.

Write a simple governance note covering model changes, prompt changes, evaluation, release approval, incident logging, and human oversight.

Create a simple abuse-case list with attacker goal, entry point, control, detection, and recovery.

Test data leakage through logs and prompts as well as model output. Sensitive information can escape through observability if logging is careless.

Review who can change safety policy and model access in the AWS account.

Week 8 — optimize cost and performance

Measure model latency, token usage, context size, retrieval overhead, output length, and request pattern.

Experiment with model choice, prompt size, caching, batching, or architecture where appropriate. Confirm that optimization does not reduce required quality or safety.

Record a simple unit-cost measure so you understand what actually drives spend.

Set a cost budget for a representative workload and identify the top cost drivers.

Compare context length, model choice, caching, and request pattern using the same evaluation set so optimization is not confused with quality loss.

Measure enough traffic to see variability rather than drawing conclusions from one request.

Load-test at small scale with representative prompt and context sizes rather than unrealistic tiny requests.

Compare cost per successful task, not only cost per model call, because retries or poor quality can make a cheaper model more expensive operationally.

Record optimization trade-offs in the architecture decision log.

Week 9 — build evaluation and troubleshooting discipline

Create representative evaluation cases, edge cases, unsafe cases, and known RAG questions. Track results by version.

Inject failures: permission error, empty retrieval, bad chunking, quota limit, tool failure, malformed output, unsafe prompt, or model change.

Use logs and metrics to prove the cause rather than guessing.

Create a known-good baseline before fault injection. Store expected retrieval sources, output criteria, latency range, and relevant logs.

Use layered troubleshooting: application, identity, data/retrieval, model, tool, quota, downstream dependency.

Write a brief incident note for each injected fault and add a prevention or early-detection idea.

Separate retrieval metrics, model-quality metrics, safety metrics, and application reliability metrics so one good average does not hide a weak subsystem.

Practice one rollback: restore an earlier prompt/model/configuration and verify that the known-good baseline returns.

Write a brief root-cause summary for each injected failure.

Weeks 10–11 — use practice questions diagnostically

Begin with targeted sets by weak domain, then shift toward mixed sets.

The AIP-C01 practice-question strategy should classify each miss by root cause and turn it into a corrective action.

Retest after a delay so you know the concept transferred rather than the answer being remembered.

Alternate targeted domain sets with mixed sets. Targeted sessions fix gaps; mixed sessions test integration.

Track confidence as well as correctness and prioritize high-confidence wrong answers.

Use official practice material late in the process when it can assess readiness rather than introduce the entire syllabus.

Build a shrinking weak-topic list and stop revisiting strong domains just because they are comfortable.

Use wrong-answer explanations to generate one new scenario in your own words so the learning is not tied to the original question.

Keep timed sessions shorter than full exam length until late preparation so fatigue practice does not replace actual learning.

Use answer explanations to trigger documentation review only when needed. A single disputed service detail should not turn into an hour of unrelated reading.

Keep the final practice phase focused on integration and error correction rather than increasing the raw number of questions completed.

Final week — narrow the plan

Return to the current AWS guide and verify every domain has practical evidence. Do not add another long course because one low practice score creates anxiety.

Review weak-topic notes, service boundaries, security controls, model/RAG trade-offs, evaluation, cost, and the mistakes you personally make under time pressure.

Confirm exam logistics and protect sleep and concentration.

Freeze the capstone unless a serious gap remains. Last-minute architecture changes create more cognitive load than learning value.

Review the official guide, domain weights, exam format, and your condensed error list.

Use short refresh sessions and preserve sleep; the 180-minute exam rewards sustained attention.

By the end of preparation, you should have more than notes. Keep a working application or architecture package with code, infrastructure, prompt/config versions, RAG design, threat model, evaluation results, monitoring, cost notes, and failure cases.

AWS Certified Generative AI Developer – Professional is designed for production responsibility. Your study plan should leave behind evidence that looks like engineering, not only exam preparation.

If the project can be explained, secured, evaluated, operated, optimized, and troubleshot, the five domains have become one coherent capability.

Review exam rules and testing logistics early in the week, not the night before.

Backfills and recovery decisions

Use one final mixed assessment several days before the exam so there is still time to repair a specific weakness.

Finish with architecture diagrams and condensed notes that reflect your own mistakes and projects.

Prepare one page of personal failure patterns: services confused, constraints often missed, security assumptions, RAG trade-offs, and pacing mistakes. Review that page instead of generic notes during the final days.

Do not change the study plan because of one late difficult question. Use the accumulated evidence from projects, domain reviews, and mixed practice.

Rehearse one 180-minute concentration block before exam week only if stamina has never been tested; otherwise preserve energy and focus on quality.

Use the last day for light review and logistics rather than a full simulation that creates fatigue or panic.

Preserve the final project as a portfolio artifact with sensitive details removed. Architecture, tests, evaluation, runbook, threat model, and cost notes provide evidence of engineering depth beyond the exam score.

The final goal is calm familiarity with the architecture and your own weak patterns, not one more wave of new material.

Keep the last review narrow and repeatable.

Keep the last review calm, current, and evidence-based.