PS Product SecurityKnowledge Base

Essential AWS DevSecOps Self-Study Path

Intro: This page translates a compact public AWS DevSecOps training syllabus into a practical self-study route that fits this KB. The goal is not to mirror a course. The goal is to turn the strongest themes into a repeatable learning path.

What this page includes

  • a staged AWS DevSecOps learning route;
  • mapping from syllabus themes to KB pages and labs;
  • guidance on where to practice, where to automate, and where to document evidence;
  • a portfolio-oriented output list for engineers who want visible learning results.

Why this page exists

A lot of AWS security learning material either stops at certifications or jumps straight to tool demos.

The more useful path for Product Security and cloud security engineers is:

  1. understand AWS security foundations;
  2. understand attacks and defenses in the same environment;
  3. automate guardrails and evidence collection;
  4. practice in labs;
  5. turn what you learned into reusable review patterns and portfolio artifacts.

High-level learning sequence

Stage 1 - AWS foundations with security context

Cover the basics first:

  • core AWS services and account structure;
  • IAM and role assumption patterns;
  • networking and segmentation concepts;
  • audit and monitoring primitives.

Use these KB pages first:

Stage 2 - AWS security principles

Do not learn AWS only as a service catalog. Learn it as an attack-path and control-design environment.

Focus on:

  • trusted relationships and role abuse;
  • metadata and credential exposure paths;
  • logging and audit blind spots;
  • identity design mistakes that become escalation paths;
  • the relationship between infrastructure choices and incident visibility.

Pair this with:

Stage 3 - Automation and infrastructure as code

The public course outline explicitly includes scripting, SDKs, CloudFormation, and Terraform. In this KB, the most practical bridge is infrastructure as code plus evidence-driven CI.

Priority topics:

  • policy-as-code and static guardrails;
  • Terraform scanning and test strategy;
  • reusable CI security gates;
  • release evidence and provenance.

Use:

Stage 4 - Practice through labs

This is where the learning path stops being theoretical.

Recommended lab sequence:

  1. AWSGoat - AWS Cloud Lab
  2. CloudGoat - Cloud Scenarios Lab
  3. OWASP EKS Goat - AWS EKS Lab
  4. Terragoat - IaC Misconfiguration Lab
  5. Cloud Compliance Scan Lab - Scan -> Triage -> Fix -> Codify
  6. Containment and Eradication Automation Lab

Stage 5 - Build a visible portfolio

The public training repo emphasizes helping learners build a portfolio of DevSecOps projects. That is the right instinct.

Useful portfolio outputs:

  • an IAM review checklist for one sample AWS service stack;
  • a Terraform policy pack or small Checkov / OPA rule bundle;
  • a CloudTrail or audit-review cheat sheet;
  • a worked attack-path diagram for one AWS trust relationship problem;
  • a small CI example that blocks on security findings and records evidence;
  • a mini write-up of one lab: what failed, how it was detected, how it was fixed.

Suggested 8-week route

Weeks 1-2

  • AWS IAM and trust basics;
  • audit and monitoring basics;
  • baseline misconfigurations.

Weeks 3-4

  • attack paths and cloud review thinking;
  • logging and telemetry design;
  • initial threat-model notes for one AWS-hosted service.

Weeks 5-6

  • Terraform scanning and policy-as-code;
  • CI quality gates;
  • signing, attestations, and release evidence.

Weeks 7-8

  • AWSGoat / CloudGoat / EKS Goat practice;
  • one cloud compliance lab;
  • one short portfolio artifact published in your own notes or repo.

What to write down as you learn

Keep a running log with:

  • AWS services you actually touched;
  • common attack-path mistakes you now recognize faster;
  • controls you would enforce in CI rather than manually;
  • controls that belong in architecture review instead of scanner policy;
  • evidence you would preserve during a cloud incident.

That log will make later incident-response, architecture-review, and leadership material much easier to absorb.

Common mistakes in AWS DevSecOps learning

  • learning services without learning trust boundaries;
  • spending all practice time in one scanner or one tool;
  • treating Terraform policy as the whole cloud-security story;
  • ignoring logging and response design until after deployment;
  • building no reusable output from the labs.

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.