The learning path

Stage 1: Know the territory

What the MLA-C02 exam is, how ML runs on AWS, and the services every scenario assumes.

  • The MLA Exam: Blueprint, Logistics, Strategy — What the AWS Certified Machine Learning Engineer – Associate credential is, how the MLA-C02 revision changed it, and exactly how the exam is structured, scored, and scheduled.
  • The ML Lifecycle on AWS — The lifecycle every exam question lives on — collect, prepare, train, deploy, operate — and the two engines that power it: SageMaker AI and Amazon Bedrock.
  • The Supporting Cast: Data, Compute, and Pipes — The non-ML services the exam assumes you know cold: the storage family, the analytics yard, compute and containers, and the integration pipes that connect them.

Stage 2: Prepare the data

Domain 1 — the heaviest stretch of track at 28%: ingest, transform, trust.

  • Ingesting and Storing Training Data — Formats that make or break training, batch extraction from S3 and databases, streaming ingestion with Kinesis and Flink, SageMaker Feature Store, and where vectors live for AI apps.
  • Transforming Data and Engineering Features — Picking the right transform tool — Glue, DataBrew, EMR, Data Wrangler — classic feature engineering, streaming transforms, and preparing text for GenAI: tokens, embeddings, chunking.
  • Data Quality, Labeling, and Bias — Quality gates with Glue Data Quality and DataBrew, labeling pipelines, train/validation/test splits and the leakage trap, class imbalance, bias mitigation, and GenAI data integrity.
  • Data Architecture for ML: Lakes, Warehouses, Catalogs — The architecture questions behind Domain 1: lake versus warehouse, Glue Data Catalog and Lake Formation, partitioning and storage-cost strategy, and moving data in at scale.

Stage 3: Build the model

Domain 2 — choosing approaches, training on SageMaker AI, customizing FMs, evaluating both.

  • Choosing a Modeling Approach — The decision the exam tests over and over: frame the problem, then pick between built-in algorithms, custom training, pre-trained AI services, and foundation models on Bedrock.
  • Training and Tuning on SageMaker AI — What actually happens inside a training job — containers, channels, checkpoints — plus hyperparameter tuning with AMT, distributed training, Spot economics, and fixing fit problems.
  • Customizing Foundation Models — The GenAI heart of MLA-C02: prompt engineering as a customization layer, fine-tuning without catastrophic forgetting, continued pre-training, distillation, and retrieval optimization.
  • Evaluating Models — Classic and GenAI — Confusion matrices and the classic metric family, baselines and reproducible experiments with MLflow, GenAI evaluation from BLEU to LLM-as-a-judge, and shadow testing before launch.

Stage 4: Ship it

Domain 3 — endpoints and batch, FMs and agents, infrastructure as code, MLOps pipelines.

  • Serving Predictions: Endpoints and Batch — The first fork every deployment question takes — real-time or batch — then endpoint anatomy, multi-model and multi-container serving, auto scaling, and instance selection.
  • Deploying FMs, RAG, and Agents — Hosting foundation models — Bedrock, Custom Model Import, SageMaker — configuring Knowledge Bases and retrieval pipelines, and running agents with tools, state, and GPU scale.
  • Provisioning ML Infrastructure as Code — CloudFormation and the CDK for ML stacks, containers for ML workloads on ECR/ECS/EKS, endpoints inside VPCs, and programmatic deployment with the SDK, CLI, and Boto3.
  • MLOps Pipelines: CI/CD for Models — The Code* family building model pipelines, deployment strategies with rollback, Model Registry and MLflow versioning, prompt management, retraining triggers, and KB refresh.

Stage 5: Run it in production

Domain 4 — monitoring, cost and performance engineering, and security end to end.

  • Monitoring Models and Agents in Production — Drift in its three flavors and the pipelines that catch it, CloudWatch generative-AI observability, agent failure modes worth paging on, and A/B tests that settle arguments.
  • Cost and Performance Engineering — Inference economics — instance families, purchasing options, right-sizing — the troubleshooting stack from X-Ray to AgentCore Observability, budgets and quotas, and GenAI cost levers.
  • Securing ML and AI Workloads — Least privilege for models and data, VPC isolation and KMS, audit trails with CloudTrail and Config, vulnerability scanning in CI/CD, Bedrock API keys versus IAM, and Guardrails.

Stage 6: Walk in ready

Question anatomy, keyword reflexes, the classic traps — then the full mock in the Exam Hall.

Stage 7: Know the professional bar

What the AIP-C01 exam is, its five-domain blueprint, and how a Professional exam asks questions.

  • The AIP Exam: Blueprint, Logistics, Strategy — What the AWS Certified Generative AI Developer – Professional credential is, its five-domain blueprint, how the professional bar differs from associate exams, and how to ride this path to a 750.

Stage 8: Design the foundation

Domain 1 — the heaviest stretch at 31%: architecture, model selection, data pipelines, vectors, retrieval, prompts.

  • Designing GenAI Solutions and Selecting Models — Requirements to architecture: proofs of concept on Bedrock, the Well-Architected Generative AI Lens, model selection by benchmark and capability, provider-switch and cross-Region resilience, and the customization lifecycle.
  • Data Pipelines for FM Consumption — Validating and processing data on its way into foundation models: Glue Data Quality and Data Wrangler gates, multimodal pipelines for text, image, audio and tabular data, and model-specific input formatting.
  • Vector Stores at Professional Scale — Choosing and operating the vector layer: Bedrock Knowledge Bases, OpenSearch neural search, Aurora and S3 options, metadata frameworks, sharding and hierarchical indexing, and the sync pipelines that keep indexes honest.
  • Retrieval Engineering — The retrieval half of RAG at professional depth: chunking strategies including hierarchical, embedding model selection, hybrid search with rerankers, query expansion and decomposition, and function-calling retrieval through MCP.
  • Prompt Engineering and Governance — Prompts as governed artifacts: Bedrock Prompt Management templates and approval workflows, parameterized role definitions, conversation history design, prompt regression testing, chain-of-thought patterns, and Prompt Flows.

Stage 9: Build and integrate

Domain 2 — agentic systems on AgentCore and MCP, deployment and throughput, enterprise wiring, streaming APIs.

  • Agentic Systems on AWS — Building agents the professional way: Strands Agents and multi-agent orchestration, MCP tool integration (stateless servers on Lambda, complex ones on ECS), AgentCore runtime services, stopping conditions, IAM boundaries, and human-in-the-loop gates.
  • Model Deployment and Throughput Strategies — Where the model runs and how much it can take: Bedrock on-demand versus provisioned throughput versus SageMaker endpoints, LLM-specific container sizing, model cascading, and task-specific small models.
  • Enterprise Integration Architectures — Dropping GenAI into organizations that already exist: legacy API integration, event-driven architectures on EventBridge, identity federation and least-privilege access to FMs, jurisdiction constraints, and CI/CD with GenAI gateway patterns.
  • FM APIs, Streaming, and Application Wiring — The request path end to end: Converse and InvokeModel, async patterns with SQS, streaming over WebSockets and SSE, backoff and fallbacks, intelligent model routing, and the application layer from Amplify to prompt chaining.

Stage 10: Make it safe

Domain 3 — guardrails in both directions, data security and privacy, governance and responsible AI.

  • Guarding Inputs and Outputs — Safety as an engineered layer: Bedrock Guardrails in both directions, custom moderation workflows, hallucination reduction with grounding and structured outputs, prompt-injection and jailbreak defense, and adversarial testing.
  • Data Security and Privacy for GenAI — Keeping the data honest while the model uses it: VPC endpoints and IAM for private model access, Lake Formation permissions, PII detection with Comprehend and Macie, masking and anonymization, and retention design.
  • Governance and Responsible AI — Proving the system behaves: model cards and lineage, CloudTrail audit trails, drift and misuse detection, transparency through reasoning displays and agent tracing, fairness evaluation with LLM-as-a-judge, and policy-aligned guardrails.

Stage 11: Make it efficient

Domain 4 — token economics, caching, latency engineering, and GenAI-aware observability.

  • GenAI Cost Engineering — The token is the unit of spend: estimation and tracking, context-window optimization and prompt compression, tiered model usage, batching, provisioned-throughput planning, and semantic plus prompt caching.
  • Performance and Monitoring for GenAI — Fast and observed: latency-optimized inference, parallelism and streaming, retrieval-index tuning, sampling-parameter effects, GenAI-aware auto scaling, and monitoring from token usage and hallucination rates to multi-agent coordination.

Stage 12: Prove it — then prove yourself

Domain 5 — evaluation pipelines and quality gates, troubleshooting, and the exam-readiness capstone.

  • Evaluating GenAI Systems — Evaluation as infrastructure: Bedrock Model Evaluations, LLM-as-a-judge and RAG evaluation, golden datasets and regression gates, A/B and canary validation, agent performance frameworks, and feedback loops that feed annotation.
  • Troubleshooting GenAI — and Exam Readiness — The capstone: diagnosing context-window overflow, retrieval degradation and embedding drift, prompt regressions and API failures — then AIP question anatomy, the professional-level traps, and the final-week plan.

Stage 13: Learn the ground you defend

What SCS-C03 is, its four question formats (including the new ordering and matching items), shared responsibility, and the security service map every scenario assumes.

  • The SCS-C03 Exam — What SCS-C03 actually is: six domains and their weights, 50 scored questions inside a 65-question form, the four response formats — including the new ordering and matching items — and how a security scenario question is engineered to make several wrong answers look right.
  • Shared Responsibility and the Security Map — Where the AWS line sits and what stands behind it: shared responsibility service by service (EC2, Lambda, Fargate, RDS, S3), every in-scope security service placed on one board by the job it does, and the layered, blast-radius thinking the exam rewards.

Stage 14: See everything

Domain 1 at 16% — monitoring and alerting, the logging architecture, log analysis at scale, and why logs go missing.

  • Monitoring and Alerting — Turning a workload into monitoring requirements: the four shapes a security signal takes, EventBridge as the spine, GuardDuty end to end, Security Hub as the aggregator, and Macie, Config and State Manager running continuous assessment.
  • The Logging Architecture — The evidence layer: CloudTrail management, data and Insights events with organization trails and CloudTrail Lake, CloudWatch Logs from agent to subscription filter, choosing network and service logs by threat, and making the record tamper-resistant.
  • Log Analysis at Scale — Reading terabytes without drowning: Security Lake and the OCSF normalization that makes a common query possible, picking between Logs Insights, Athena, OpenSearch and Managed Grafana on cost and latency, and correlating sources into one incident timeline.
  • Troubleshooting Detection — The lesson every exam asks and no course teaches: an ordered checklist for missing logs, the per-service logging gaps in Lambda, API Gateway, CloudFront and Route 53, and the remediation patterns that keep a fix from drifting back.

Stage 15: Respond without making it worse

Domain 2 at 14% — response plans and prepared access, automated remediation and forensics, then the containment ladder and root-cause analysis.

  • Designing the Response — The plan you write before the pager goes off: the incident response lifecycle, runbooks versus playbooks, severity and escalation, OpsCenter and Incident Manager, pre-provisioned responder roles and a forensics account, and Shield Advanced protections configured ahead of the DDoS you expect.
  • Automated Response and Forensics — Machinery that responds faster than a human can log in: finding to EventBridge to target, choosing between Lambda, Systems Manager Automation and Step Functions, Application Recovery Controller for recovery orchestration, the Automated Forensics Orchestrator for Amazon EC2, and Fault Injection Service game days that prove the whole thing works.
  • Responding to Security Events — The live response, in the order that preserves your options: validate the finding and scope it, capture evidence before you change anything, climb the containment ladder (including revoking sessions that a detached policy would not touch), eradicate persistence, recover without reinfection, and prove root cause with Amazon Detective.

Stage 16: Harden the perimeter and the host

Domain 3 at 18% — edge protection with CloudFront, WAF and Shield; compute hardening and vulnerability management; network controls and hybrid connectivity.

  • Protecting the Edge — The first hit lands here: choosing edge controls from the threat you actually expect, CloudFront as a security boundary with Origin Access Control and signed URLs, WAF web ACLs engineered rule by rule with priority and labels, and Shield Standard versus Shield Advanced for DDoS resilience.
  • Securing Compute Workloads — Everything that runs your code: golden AMIs and hardened container images built by pipeline, the three role shapes that authorize a workload, IMDSv2, Inspector versus GuardDuty Runtime Monitoring, Patch Manager against immutable rebuilds, Session Manager instead of SSH keys, and guardrails for pipelines and generative-AI applications.
  • Network Security Controls — The most-tested network facts on the exam: stateful security groups against stateless NACLs and their ephemeral ports, AWS Network Firewall with stateless, stateful and Suricata rules, segmentation for north/south and east/west traffic, and the tools that prove nobody needs the access you granted.
  • Hybrid and Private Connectivity — Stitching AWS to everything else without losing the encryption argument: Site-to-Site VPN tunnels, Direct Connect virtual interfaces and MACsec, Client VPN against Verified Access for user access, and Route 53 Resolver DNS Firewall for the attack surface everyone forgets.

Stage 17: Decide who may do what

Domain 4 at 20%, the heaviest on the exam — authentication, temporary credentials, the full policy-evaluation chain, and reviewing access you already granted.

  • Authentication Strategies — Establishing who the caller is: IAM Identity Center and permission sets as the answer for human access at scale, SAML 2.0 and OIDC federation mechanics, Cognito user pools versus identity pools, the Directory Service options, MFA enforcement that actually fails closed, root user credential management — and a diagnostic method for when sign-in breaks.
  • Temporary Credentials — Short-lived credentials end to end: the five AWS STS operations and when each applies, the two-policy role model, session duration and the one-hour role-chaining cap, cross-account trust and the confused-deputy defences, IAM Roles Anywhere for workloads off AWS, S3 presigned URLs, and the narrowing-only power of session policies and session tags.
  • Policy Evaluation — The chain that decides every single request: an explicit deny anywhere wins, and then every applicable layer — organization policies, resource policy, permissions boundary, session policy, identity policy — must allow it. Reading policy documents precisely, the condition keys the exam leans on, cross-account authorization service by service, and the four capping policy types compared.
  • Designing and Reviewing Access — Designing access you can defend, then proving it is not too wide: ABAC with principal and resource tags against RBAC with permission sets, evidence-driven least privilege from last-accessed data and generated policies, application authorization with Amazon Verified Permissions and Cedar, and finding and fixing over-permission with IAM Access Analyzer.

Stage 18: Protect the data itself

Domain 5 at 18% — KMS and envelope encryption, enforcing encryption in transit, immutability and encryption at rest, secrets and ransomware resilience.

  • KMS, Keys, and Certificates — The cryptographic foundation: envelope encryption and encryption context, the three key types and the key policy that is the root of a key’s authority, grants and kms:ViaService, multi-Region keys, CloudHSM and external key stores, imported key material, and certificates from ACM and Private CA.
  • Protecting Data in Transit — Making encryption on the wire non-optional: ELB security policies and TLS termination choices, explicit denies on aws:SecureTransport, PrivateLink and VPC endpoints as private paths you can require, and inter-node encryption for EMR, EKS, SageMaker AI, and the Nitro System.
  • Protecting Data at Rest — Every S3 encryption option and the requirement each one satisfies, the four-layer S3 access decision and how to troubleshoot it, Object Lock and Vault Lock for WORM and integrity, and encryption for EBS volumes, file systems, and databases — including the snapshot-sharing rules.
  • Secrets, Masking, and Resilience — Credentials that rotate themselves, sensitive data masked in logs and messages before an operator can read it, backups that survive a compromised administrator, and lifecycle rules that retain data exactly as long as the obligation lasts — no longer.

Stage 19: Govern the whole organization

Domain 6 at 14% — Organizations and Control Tower, SCPs and the newer RCPs, consistent deployment, and proving compliance to an auditor.

  • The Multi-Account Foundation — The organization as the security boundary: Organizations structure, trusted access and delegated administrators, Control Tower landing zones and the three kinds of control, SCPs and the newer RCPs, and root credentials at organization scale.
  • Consistent, Secure Deployment — Making every account and every new resource inherit the control: StackSets across accounts and Regions, CloudFormation Guard and cfn-lint shifting policy left, Firewall Manager and Config organization rules enforcing from a central source, tags as the organizing device, and safe sharing with RAM and Service Catalog.
  • Compliance and Audit Evidence — Proving it: Config rules with automatic remediation and aggregated compliance, Audit Manager assessments and automated evidence collection, Artifact for AWS’s own reports, and the Well-Architected Tool, Trusted Advisor and Security Hub as three different instruments for measuring an architecture.

Stage 20: Walk in ready

Question anatomy, the keyword reflexes, the traps that sink strong engineers, and a final-week plan — then the full mock in the Exam Hall.

  • Exam Readiness — The capstone: dissecting a security stem down to the clause that decides it, a dense phrase-to-service reflex table across all six domains, the traps that sink engineers who actually know AWS, and a day-by-day final week that ends in the Exam Hall.

Stage 21: Orient on the blueprint

What DEA-C01 actually asks, the four domains and their weights, and the service map a data engineer is expected to navigate without hesitating.

  • The DEA-C01 Exam: Blueprint, Logistics, Strategy — What the exam is actually testing and how it is built: the four content domains and what each one weighs, the kinds of judgement an associate-level data engineering question rewards, and the 50-scored-of-65 question split that changes how you pace yourself.
  • The Data Service Map — The whole in-scope estate laid out as one pipeline so later lessons have somewhere to land: what ingests, what transforms, what stores, what catalogs, what queries, what orchestrates, and what governs — and the handful of services that appear in all four domains.

Stage 22: Get the data in

Streaming and batch ingestion, the throughput and ordering decisions behind each, and the replay story when a consumer falls behind.

  • Ingestion Patterns — The first decision in any pipeline: streaming or batch, and what each commits you to. Throughput and latency targets, bounded versus unbounded data, replayability, the cost of getting it wrong in both directions, and the AWS service that matches each shape.
  • Streaming at Scale — Kinesis Data Streams, Managed Service for Apache Kafka, and Firehose as three different bargains: who owns the shard or partition, how ordering is guaranteed and at what granularity, what happens when a consumer falls behind, and when a fully managed delivery stream is the right answer instead.

Stage 23: Shape it and orchestrate it

Glue, Spark and EMR for transformation; Step Functions, MWAA and EventBridge for the schedule; and the programming idioms the exam puts on screen.

  • Transformation Engines — Glue, EMR, and the Spark underneath both: where a Glue job beats a cluster and where it does not, DPUs and executors as the same idea priced differently, the file-size and partition problems that dominate real pipeline cost, and why a slow job is usually a shuffle rather than a CPU.
  • Orchestrating the Pipeline — Turning a set of jobs into a dependable line: Step Functions, Managed Workflows for Apache Airflow, EventBridge and Glue workflows compared on the axes that actually decide between them — dependency complexity, failure semantics, retry and idempotency, cost at idle, and who maintains the DAG.
  • Programming Concepts on the Exam — Task statement 1.4, which readers under-prepare because it looks like a coding question and is not. SQL that the exam expects you to read, infrastructure as code, Git flow and CI/CD for pipelines, the SDK patterns that appear in stems, and optimising a query by reading its plan.

Stage 24: Decide where it lives

Choosing the store against the access pattern, cataloging it so it can be found, moving it through its lifecycle, and evolving a schema without breaking readers.

  • Choosing a Data Store — The decision the exam asks most often. Access pattern before product: S3 and the lake, Redshift and the warehouse, DynamoDB for key-value at scale, RDS and Aurora for relational workloads, and the specialised stores — with the constraints (latency, query shape, cardinality, cost at rest) that eliminate the wrong three.
  • Cataloging and Discovery — Data nobody can find is data nobody uses. The Glue Data Catalog as the shared metadata layer, crawlers and classifiers and where they get schema wrong, partition indexes and why a query gets slower as the table grows, Lake Formation as the permissions layer over the catalog, and DataZone for discovery across teams.
  • Lifecycle and Tiering — Moving data through its useful life without a script: S3 storage classes and the retrieval bargain each one strikes, lifecycle configuration and the traps in transition rules, Intelligent-Tiering versus explicit policy, Redshift and DynamoDB retention mechanics, and backup and recovery as a design input rather than an afterthought.
  • Data Modeling and Schema Evolution — Designing a model that survives contact with change: star and snowflake schemas and when normalising costs more than it saves, DynamoDB single-table design driven by access patterns, the open table formats (Iceberg, Hudi, Delta Lake) and what they actually buy, and evolving a schema without breaking every reader downstream.

Stage 25: Run the line

Automating the pipeline, querying it with Athena and Redshift, watching it with CloudWatch and lineage, and proving the data is fit to use.

  • Automating Data Processing — Making the line run without a human in it: scheduling and event triggers, Lambda inside a data pipeline and the places it does not belong, Glue job bookmarks and incremental processing, concurrency and the quota ceilings you meet at scale, and the automation that handles its own failures.
  • Analyzing Data — Getting answers out: Athena over the lake and what makes a query cheap or ruinous, Redshift Spectrum and the federated query story, materialised views and result caching, OpenSearch for search and log analytics, and QuickSight as the consumer whose needs shape everything upstream.
  • Maintaining and Monitoring — Knowing the pipeline broke before the business tells you: CloudWatch metrics, logs and alarms for data services, the Glue and EMR observability surfaces, lineage and traceability, cost monitoring as an operational signal, and the troubleshooting order that finds a cause instead of a symptom.
  • Ensuring Data Quality — The task statement with the least obvious service answer, because quality is a design problem first. The failure modes that reach production, completeness and consistency and freshness as measurable things, Glue Data Quality and Deequ, where a quality gate belongs in the line, and what to do when bad data has already landed.

Stage 26: Govern it, then walk in ready

Authentication and authorization over data, encryption and masking, audit-ready logs and privacy duties — then question anatomy and the full mock in the Exam Hall.

  • Authentication and Authorization over Data — Who you are and what you may touch, at data granularity. IAM roles and role chaining for pipelines, IAM Identity Center for human access, Lake Formation permissions down to column and row, Redshift and Athena access models, and the resource policies that catch people out on cross-account reads.
  • Encryption and Masking — Protecting the data itself: encryption at rest across S3, Redshift, DynamoDB and RDS, encryption in transit and where it is not automatic, KMS keys and who can use them, and the masking and tokenisation choices — dynamic masking, column-level redaction, and detecting sensitive data before it spreads.
  • Audit Logs and Privacy — Proving it afterwards. CloudTrail management and data events over data stores, the service-native logs that answer questions CloudTrail cannot, centralising and querying logs for an audit, and the privacy duties — residency, retention, deletion requests, and lineage as evidence — that turn governance from a policy document into a pipeline requirement.
  • Walk In Ready — The capstone: reading a question for the constraint that actually decides it, the keyword reflexes that map a stem to a service, the traps that sink competent engineers, and a final-week plan that ends with the full mock.