dojo.md 0.2.0 → 0.2.2

package/courses/aws-lambda-debugging/scenarios/level-5/ma-serverless-integration.yaml

@@ -0,0 +1,75 @@
+meta:
+  id: ma-serverless-integration
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "M&A serverless integration — design the technical integration plan for merging two companies' serverless platforms during an acquisition"
+  tags: [AWS, Lambda, M&A, integration, acquisition, multi-account, master]
+
+state: {}
+
+trigger: |
+  Your company (acquirer, 200 Lambda functions on AWS) is acquiring
+  a competitor (target, 150 Lambda functions on AWS). Both companies
+  run serverless platforms but with different practices:
+
+  Acquirer (your company):
+  - AWS Organization with 5 accounts (dev, staging, prod, shared, security)
+  - CDK for IaC, standardized templates
+  - Powertools for observability
+  - SOC2 Type II compliant
+  - Monthly AWS bill: $80K
+
+  Target company:
+  - Single AWS account (everything in one account!)
+  - Serverless Framework for some, console deployments for others
+  - Mixed logging (console.log, Winston, no standard)
+  - No compliance certifications
+  - Monthly AWS bill: $45K
+  - Different AWS region (eu-west-1 vs your us-east-1)
+
+  Integration challenges:
+
+  1. Account structure: target's single-account needs separation
+     into your multi-account Organization structure.
+
+  2. IaC migration: 60% of target's functions deployed via console
+     need to be captured in CDK.
+
+  3. Observability: no structured logging means you can't monitor
+     target's services through your unified dashboard.
+
+  4. Data: target uses RDS PostgreSQL, you use DynamoDB. Customer
+     data must be merged without downtime.
+
+  5. Compliance: target must achieve SOC2 compliance within 12 months
+     of acquisition (contractual requirement).
+
+  6. Team integration: target's 30 engineers need onboarding to
+     your platform, tools, and processes.
+
+  7. Domain overlap: both companies have "user-service" and
+     "payment-service" Lambda functions that need consolidation.
+
+  Timeline: 18 months for full integration, 6 months for critical
+  path items.
+
+  Task: Design the M&A integration plan for serverless. Write:
+  account consolidation strategy, IaC migration approach, data
+  merge strategy, compliance remediation, team onboarding, service
+  consolidation (which services to keep from each company), timeline,
+  and risk mitigation.
+
+assertions:
+  - type: llm_judge
+    criteria: "Account and IaC migration are planned — phase 1 (month 1-3): invite target's account into your AWS Organization, apply SCPs for governance. Create dedicated accounts for target's workloads (dev/staging/prod). Phase 2 (month 3-6): use aws lambda get-function to export all console-deployed functions, convert to CDK constructs. Prioritize by business criticality. Use CloudFormation import to bring existing resources under IaC management. Don't migrate everything at once — target's services keep running in their original account while migration happens"
+    weight: 0.35
+    description: "Account and IaC"
+  - type: llm_judge
+    criteria: "Data merge and compliance are covered — data strategy: don't merge databases immediately. Use API layer to abstract data location. Phase 1: cross-account access (Lambda in acquirer account reads target's RDS via VPC peering). Phase 2: gradual data migration with dual-write period. Customer identity merge: create a unified identity service that maps both systems. Compliance: apply acquirer's SOC2 controls to target's infrastructure incrementally. Start with critical controls (access management, encryption, logging) in month 1-3. Full SOC2 audit readiness by month 12. Cross-region: use DynamoDB Global Tables or Aurora Global for data replication between us-east-1 and eu-west-1"
+    weight: 0.35
+    description: "Data and compliance"
+  - type: llm_judge
+    criteria: "Team and service integration are practical — team onboarding: 2-week bootcamp on acquirer's platform (CDK, Powertools, CI/CD pipeline). Pair target engineers with acquirer engineers for 3 months. Don't force immediate tool changes — let teams migrate at their pace with deadlines. Service consolidation: evaluate each overlapping service (user-service, payment-service) — keep the one with better architecture/test coverage, migrate the other's unique features. Don't rewrite — adapt and extend. Risk mitigation: keep target's original services running for 6+ months as fallback. Integration manager role: dedicated person coordinates across teams. Track: integration milestones, service migration completion %, team satisfaction"
+    weight: 0.30
+    description: "Team and service"

package/courses/aws-lambda-debugging/scenarios/level-5/master-debugging-shift.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: master-debugging-shift
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "Combined master debugging shift — serve as fractional CTO advising on a complete serverless platform strategy encompassing technology, people, process, and business alignment"
+  tags: [AWS, Lambda, troubleshooting, combined, shift-simulation, CTO, master]
+
+state: {}
+
+trigger: |
+  You're engaged as a fractional CTO for a Series C healthtech
+  startup ($75M raised, 150 engineers). They've been all-in on
+  serverless for 3 years with 500+ Lambda functions. Growing pains
+  are threatening their Series D fundraising.
+
+  Technical challenges:
+  - 500+ Lambda functions with no naming convention or catalog
+  - Step Functions workflows with 30+ states, no error handling
+  - Monthly AWS bill: $120K, growing 20% month-over-month
+  - Cold start complaints from enterprise customers (healthcare
+    portals require sub-second response for clinical workflows)
+  - Last month: 3 incidents with MTTR > 2 hours each
+  - No multi-region: single us-east-1 deployment (enterprise
+    customers require 99.99% availability)
+  - HIPAA compliance gaps found during customer audit
+
+  People challenges:
+  - 3-person platform team supporting 150 engineers (understaffed)
+  - No on-call rotation — CTO handles all production incidents
+  - Engineers deployed to production via console (no IaC for 30%
+    of functions)
+  - No security engineer — HIPAA compliance is "everyone's job"
+    (meaning nobody's job)
+
+  Business context:
+  - Series D fundraising in 6 months
+  - 5 enterprise prospects (each $2M+ ARR) requiring SOC2 + HIPAA
+  - Board concerned about infrastructure maturity
+  - Competing with well-funded rivals who have production-grade platforms
+  - CEO: "Fix the platform. We can't lose these enterprise deals."
+
+  Task: Design the comprehensive 6-month roadmap for Series D
+  readiness. Write: phased approach (stabilize → secure → scale →
+  optimize), technology decisions, hiring plan (who and when), HIPAA
+  compliance sprint, cost optimization targets, enterprise readiness
+  metrics, and the board presentation talking points.
+
+assertions:
+  - type: llm_judge
+    criteria: "Phased roadmap is realistic — Month 1-2 (Stabilize): hire security engineer, implement on-call rotation, migrate console-deployed functions to IaC, add error handling to critical Step Functions, implement Powertools logging across all functions. Month 2-3 (Secure): HIPAA gap remediation (encryption, access logging, data classification, BAA verification), SOC2 Type I preparation, fix IAM overpermission. Month 3-5 (Scale): multi-region for enterprise customers (active-passive initially), provisioned concurrency for clinical endpoints, expand platform team. Month 5-6 (Optimize): cost optimization (right-size, ARM, reduce CloudWatch costs), enterprise customer readiness demos, Series D preparation materials"
+    weight: 0.35
+    description: "Phased roadmap"
+  - type: llm_judge
+    criteria: "Hiring and compliance are justified — immediate hires: (1) security engineer (HIPAA/SOC2 — critical for enterprise deals), (2) senior platform engineer (IaC migration, multi-region), (3) SRE (on-call, incident management, observability). Within 3 months: (4) developer experience engineer (templates, tooling). HIPAA compliance sprint: data flow mapping (where does PHI go?), encrypt all PHI at rest and transit (KMS), implement access logging (CloudTrail), set CloudWatch Logs retention and encryption, mask PII in application logs, document BAA for all AWS services used. Target: audit-ready in 4 months"
+    weight: 0.35
+    description: "Hiring and compliance"
+  - type: llm_judge
+    criteria: "Enterprise readiness and board communication are practical — enterprise requirements: 99.99% availability (multi-region), SOC2 Type II (need 6 months of evidence — start Type I immediately), HIPAA compliance documentation, incident response plan, SLA definitions. Cost optimization: target $90K/month (25% reduction) through right-sizing, ARM, log optimization. Board talking points: infrastructure is a competitive advantage (enterprise customers pay 3-5x more), platform investment enables $10M+ in enterprise pipeline, MTTR improvement from 2+ hours to < 30 minutes demonstrates operational maturity. Series D narrative: 'We're building enterprise-grade infrastructure to capture the enterprise healthcare market.'"
+    weight: 0.30
+    description: "Enterprise readiness"

package/courses/aws-lambda-debugging/scenarios/level-5/organizational-serverless-transformation.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: organizational-serverless-transformation
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "Lead organizational serverless transformation — manage cultural change, team restructuring, and skill development for enterprise serverless adoption"
+  tags: [AWS, Lambda, organizational, transformation, culture, leadership, master]
+
+state: {}
+
+trigger: |
+  You're leading serverless transformation at a 3,000-person
+  enterprise. After 18 months, adoption is at 20% — the goal was 60%.
+
+  Resistance patterns:
+
+  Operations team (40 people):
+  "Serverless means we can't SSH into servers to debug. How do we
+  do our jobs?" Fear: job obsolescence.
+  Reality: ops role transforms from "manage servers" to "manage
+  platforms and developer experience."
+
+  Backend developers (200 people):
+  "Lambda forces us to break our monolith into hundreds of functions.
+  That's more complex, not less." Fear: loss of control, added complexity.
+  Reality: serverless doesn't require microservices — start with
+  Lambda-lith (monolith in Lambda) and decompose gradually.
+
+  Architecture team (15 people):
+  "Vendor lock-in! If AWS changes Lambda pricing or discontinues
+  it, we're stuck." Fear: loss of portability.
+  Reality: business logic is portable; infrastructure integration
+  code (~15%) is AWS-specific. The risk of slow innovation
+  (not adopting) exceeds the risk of lock-in.
+
+  Middle management:
+  "This wasn't in our roadmap. We're already behind on feature
+  delivery." No incentive to invest in serverless migration.
+  Reality: OKRs need to include modernization goals.
+
+  Early adopters (5 teams):
+  Enthusiastic but frustrated. "We adopted serverless but got no
+  platform support. We're reinventing everything."
+  Reality: without a platform team, each team builds its own
+  infrastructure, wasting engineering time.
+
+  Task: Design the organizational transformation strategy. Write:
+  the change management framework, addressing each group's concerns
+  with empathy and data, training program design, incentive
+  alignment, platform team investment, measuring cultural change,
+  and lessons from successful serverless transformations.
+
+assertions:
+  - type: llm_judge
+    criteria: "Change management is structured — start with the 'why': quantify cost of status quo (server management time, deployment friction, incident frequency). Build coalition: executive sponsor + early adopter teams + willing ops engineers. Quick wins: migrate a visible, successful project in 4-6 weeks (demonstrate value). Enable: platform team provides self-service tools so adoption is easier than the old way. Incentivize: include modernization metrics in OKRs. Celebrate: publicize wins (deployment frequency improvement, cost savings). Sustain: embed serverless in hiring criteria, onboarding, and promotion ladders"
+    weight: 0.35
+    description: "Change management"
+  - type: llm_judge
+    criteria: "Stakeholder concerns are addressed with empathy — operations: 'your role is evolving, not disappearing. Platform engineering is more impactful than server management.' Provide retraining budget. Backend developers: 'you don't have to rewrite everything. Start by deploying your existing app on Lambda (Lambda-lith), then decompose as it makes sense.' Architecture: 'the risk of not modernizing (losing competitive advantage, talent) exceeds lock-in risk. We'll keep business logic portable.' Management: 'serverless is a force multiplier — your team ships features faster, which helps your roadmap.' Early adopters: 'we hear you — platform team investment starts now'"
+    weight: 0.35
+    description: "Stakeholder concerns"
+  - type: llm_judge
+    criteria: "Training and measurement are practical — training program: Level 1 (all engineers): Lambda fundamentals + hands-on workshop (2 days). Level 2 (adopting teams): event-driven design + serverless patterns (1 week). Level 3 (platform team): deep AWS + architecture + operations (ongoing). Training should be hands-on, not lecture-based. Pair experienced serverless developers with migrating teams. Measure transformation: adoption rate (% serverless), deployment velocity per team, developer satisfaction (quarterly survey), incidents related to serverless vs traditional, team autonomy (can they deploy without help?). Target: 60% adoption in 12 months with platform support"
+    weight: 0.30
+    description: "Training and measurement"

package/courses/aws-lambda-debugging/scenarios/level-5/regulatory-serverless.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: regulatory-serverless
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "Design regulatory compliance for serverless — implement controls for SOC2, PCI-DSS, HIPAA, and GDPR in Lambda-based architectures"
+  tags: [AWS, Lambda, compliance, SOC2, PCI-DSS, HIPAA, GDPR, master]
+
+state: {}
+
+trigger: |
+  Your serverless application processes payment card data and
+  personal health information. You need compliance with PCI-DSS,
+  HIPAA, and GDPR simultaneously.
+
+  Auditor challenges:
+
+  1. "Where does the code run? Show me the server."
+  Lambda: there IS no server to inspect. Compliance frameworks
+  designed for servers need adaptation for serverless.
+  Answer: AWS manages the infrastructure (shared responsibility).
+  You control: code, configuration, data, access.
+
+  2. "How do you ensure data encryption at rest?"
+  Lambda environment variables: encrypted with AWS-managed or
+  customer-managed KMS key. DynamoDB: encryption at rest default.
+  S3: SSE-S3 or SSE-KMS. All data in transit: TLS 1.2+.
+
+  3. "Show me access logs for the last 90 days."
+  CloudTrail: every API call logged (Lambda invocations, config
+  changes, IAM actions). CloudWatch Logs: function execution logs.
+  API Gateway: access logs with source IP, user agent, response code.
+
+  4. "How do you handle right to erasure (GDPR Article 17)?"
+  Serverless challenge: data may exist in DynamoDB, S3, CloudWatch
+  Logs, X-Ray traces, DLQ messages, Step Functions execution history.
+  Must identify and delete from ALL locations.
+
+  5. "Demonstrate vulnerability management."
+  No OS to patch (AWS responsibility). But: application dependencies,
+  Lambda runtime versions, third-party layers. Must scan and update.
+
+  Task: Design regulatory compliance for serverless. Write: shared
+  responsibility model for Lambda, control mappings for PCI-DSS
+  and HIPAA, GDPR data handling (right to erasure, data portability),
+  audit evidence collection, vulnerability management without
+  servers, and compliance automation with AWS Config.
+
+assertions:
+  - type: llm_judge
+    criteria: "Shared responsibility for serverless is explained — AWS responsibility: physical security, hypervisor, OS patching, runtime patching, network infrastructure. Customer responsibility: function code, dependencies, IAM configuration, data encryption configuration, application logging, input validation. This is MORE favorable than EC2 (where customer patches OS). Compliance advantage: smaller attack surface, no server hardening needed. Compliance challenge: less visibility into infrastructure, new tooling needed for serverless-specific controls"
+    weight: 0.35
+    description: "Shared responsibility"
+  - type: llm_judge
+    criteria: "Control mappings and GDPR are covered — PCI-DSS: Req 2 (secure config) → Lambda function settings, no default passwords. Req 3 (protect stored data) → KMS encryption. Req 6 (secure development) → code scanning, dependency management. Req 10 (logging) → CloudTrail + CloudWatch. HIPAA: BAA with AWS, encrypt PHI (KMS), restrict access (IAM), audit all PHI access (CloudTrail). GDPR right to erasure: identify all data stores (DynamoDB, S3, CloudWatch Logs, X-Ray, SQS DLQ), implement deletion workflow across all stores, set log retention to minimum required, mask PII in logs"
+    weight: 0.35
+    description: "Controls and GDPR"
+  - type: llm_judge
+    criteria: "Compliance automation is practical — AWS Config rules: monitor Lambda configuration compliance (encryption enabled, VPC configured, timeout < max, memory within policy). Custom Config rules via Lambda for organization-specific checks. AWS Security Hub: aggregate findings from GuardDuty, Inspector, Config. Automated evidence collection: CloudTrail logs (access audit), Config snapshots (configuration audit), CloudWatch (operational audit). Vulnerability management: scan dependencies in CI (Snyk/npm audit), update Lambda runtimes before EOL, monitor AWS security bulletins. SOC2 continuous compliance: automated control testing, evidence generation, dashboard for auditors"
+    weight: 0.30
+    description: "Compliance automation"

package/courses/aws-lambda-debugging/scenarios/level-5/serverless-economics.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: serverless-economics
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "Analyze serverless economics — evaluate total cost of ownership, break-even analysis, and financial models for Lambda vs containers vs EC2"
+  tags: [AWS, Lambda, economics, TCO, break-even, serverless-vs-containers, master]
+
+state: {}
+
+trigger: |
+  The CFO requests a comprehensive comparison: "Lambda vs containers
+  vs EC2 — which is actually cheaper?" The answer depends on workload
+  characteristics.
+
+  Workload profiles analyzed:
+
+  Workload A — Spiky API (e-commerce):
+  Traffic: 0 at night, 1000 req/s during day, 5000 req/s during sales
+  Average duration: 200ms, Memory: 512MB
+
+  Lambda: ~$12,000/month (pay per invocation, scales to zero)
+  ECS Fargate: ~$8,000/month (must keep minimum containers running)
+  EC2: ~$5,000/month (cheapest compute but 24/7 running + ops cost)
+  + Ops cost: EC2 needs $15K/month in ops engineering time
+
+  Total: Lambda $12K, Fargate $8K, EC2 $20K (including ops)
+
+  Workload B — Steady-state API (SaaS):
+  Traffic: constant 500 req/s, 24/7
+  Average duration: 500ms, Memory: 1GB
+
+  Lambda: ~$45,000/month (expensive at constant high volume)
+  ECS Fargate: ~$6,000/month (right-sized containers)
+  EC2 Reserved: ~$3,000/month (1-year reserved instances)
+  + Ops cost: distributed across many services
+
+  Total: Lambda $45K, Fargate $6K, EC2 $8K
+
+  Workload C — Event processing (IoT):
+  Volume: 10M events/day, sporadic timing
+  Average duration: 50ms, Memory: 256MB
+
+  Lambda: ~$800/month (low duration, low memory, efficient)
+  ECS Fargate: ~$2,500/month (needs containers running for events)
+  EC2: ~$1,500/month (over-provisioned for sporadic workload)
+
+  Task: Analyze serverless economics. Write: the cost model for
+  each compute option, break-even analysis (when Lambda becomes
+  more expensive), hidden costs (CloudWatch, API Gateway, data
+  transfer, engineering time), and strategic decision framework.
+
+assertions:
+  - type: llm_judge
+    criteria: "Cost models are comprehensive — Lambda: per-invocation ($0.20/million) + per-GB-second ($0.0000166667) + API Gateway ($3.50/million REST, $1.00/million HTTP). No cost at zero traffic. ECS Fargate: per-vCPU-hour ($0.04048) + per-GB-hour ($0.004445). Minimum: 1 task always running. EC2: per-hour pricing, reserved instances 30-60% cheaper. Hidden costs: CloudWatch Logs ($0.50/GB), data transfer ($0.09/GB), NAT Gateway ($0.045/GB), VPC endpoints. Lambda break-even: typically at 1-10M invocations/month steady-state, Lambda becomes more expensive than right-sized containers"
+    weight: 0.35
+    description: "Cost models"
+  - type: llm_judge
+    criteria: "Break-even and decision factors are covered — Lambda is cheaper when: traffic is spiky (scales to zero), volume is low-medium, functions are short duration (< 1s). Containers are cheaper when: traffic is steady, volume is high, long-running processes. EC2 is cheaper when: compute is constant, can use reserved instances, need specialized hardware (GPU). Decision factors beyond cost: operational complexity (Lambda < Fargate < EC2), time to market (Lambda fastest), team skills, vendor lock-in, compliance requirements. Total cost includes: engineering time (Lambda needs less ops), opportunity cost (faster deployment = faster revenue)"
+    weight: 0.35
+    description: "Break-even analysis"
+  - type: llm_judge
+    criteria: "Strategic framework is practical — hybrid approach: Lambda for APIs + event processing + glue, Fargate for steady workloads + long-running jobs, EC2 for specialized compute. Evaluate per-workload, not per-organization. Present to CFO in business terms: cost per transaction, cost per user, infrastructure cost as % of revenue. Compare trends: Lambda getting cheaper (price reductions), containers getting easier (Fargate). Savings Plans: apply to Lambda AND Fargate (17% additional savings). Track and report: monthly cost per service, cost anomaly detection, cost per business metric (cost per order processed)"
+    weight: 0.30
+    description: "Strategic framework"

package/courses/aws-lambda-debugging/scenarios/level-5/serverless-future-technology.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: serverless-future-technology
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "Analyze serverless technology evolution — evaluate emerging technologies like WebAssembly runtimes, edge computing, and AI-integrated serverless patterns"
+  tags: [AWS, Lambda, future, WebAssembly, edge, AI, evolution, master]
+
+state: {}
+
+trigger: |
+  Your company's technology radar review: "What's next for serverless?
+  Where should we invest in the next 3-5 years?"
+
+  Emerging technologies to evaluate:
+
+  1. Lambda SnapStart Evolution:
+  Currently Java 11+ and .NET 8. Expected to expand to more runtimes.
+  CRaC (Coordinated Restore at Checkpoint) becoming standard.
+  Future: sub-50ms cold starts for all runtimes.
+
+  2. WebAssembly (Wasm) on Lambda:
+  AWS is investing in Wasm runtimes. Potential: near-instant cold
+  starts (~1ms), polyglot support (Rust, C++, Go → Wasm), sandboxed
+  execution, smaller binaries. Currently experimental but Docker
+  already supports Wasm containers.
+
+  3. AI/ML on Lambda:
+  Lambda now supports up to 10GB memory and 6 vCPUs. Inference
+  workloads becoming viable. Bedrock integration for managed LLM
+  access. Pattern: Lambda → Bedrock API → response (no GPU needed).
+  Edge AI: Lambda@Edge for low-latency inference.
+
+  4. Edge-native serverless:
+  CloudFront Functions (sub-millisecond). Lambda@Edge expanding.
+  IoT Greengrass for device-level Lambda. Multi-region by default.
+  Future: compute at every CDN edge location with state.
+
+  5. Serverless databases:
+  Aurora Serverless v2 (scales to zero), DynamoDB on-demand,
+  ElastiCache Serverless. Future: fully serverless data tier
+  that scales with Lambda.
+
+  6. Event-driven architecture maturation:
+  EventBridge Pipes (connect sources to targets without Lambda),
+  Step Functions Distributed Map (massive parallel processing),
+  Lambda response streaming for real-time UX.
+
+  Task: Evaluate serverless technology evolution. Write: assessment
+  of each technology (maturity, use cases), impact on current Lambda
+  architecture, migration considerations, timeline predictions, and
+  strategic recommendations for technology investment.
+
+assertions:
+  - type: llm_judge
+    criteria: "Technology assessments are balanced — SnapStart/CRaC: production-ready, adopt now for Java/.NET. Wasm: experimental, watch for 2-3 years, pilot for edge/embedded use cases. AI/ML on Lambda: production-ready for inference (Bedrock integration), adopt now. Edge serverless: production-ready (CloudFront Functions), adopt for latency-sensitive features. Serverless databases: production-ready (Aurora Serverless v2, DynamoDB), adopt. Event-driven maturation: production-ready (EventBridge Pipes, Step Functions), adopt to reduce Lambda glue code"
+    weight: 0.35
+    description: "Technology assessments"
+  - type: llm_judge
+    criteria: "Strategic impact is explained — key trend: serverless is becoming the default, not the exception. Impact on architecture: fewer Lambda functions needed as services become more capable (EventBridge Pipes eliminates simple Lambda integrations, Step Functions handles more logic without custom code). Lambda's role shifts from 'all compute' to 'custom business logic only.' AI integration: every Lambda function can leverage AI via Bedrock without managing infrastructure. Edge: latency-sensitive logic moves to edge, Lambda handles heavy processing. Serverless databases complete the 'fully serverless stack' vision"
+    weight: 0.35
+    description: "Strategic impact"
+  - type: llm_judge
+    criteria: "Investment recommendations are actionable — invest now: AI/ML integration (Bedrock), edge computing (CloudFront Functions), serverless databases (Aurora Serverless v2). Pilot: Wasm runtimes, Lambda response streaming. Watch: serverless containers (Fargate convergence with Lambda), multi-cloud serverless (Google Cloud Run, Azure Container Apps). Don't invest in: building custom serverless platforms (use AWS), multi-cloud abstractions (added complexity, limited benefit). Architecture principle: keep business logic portable, let infrastructure integration be AWS-specific. Re-evaluate every 12 months as the landscape evolves rapidly"
+    weight: 0.30
+    description: "Investment recommendations"

package/courses/aws-lambda-debugging/scenarios/level-5/serverless-platform-design.yaml

@@ -0,0 +1,71 @@
+meta:
+  id: serverless-platform-design
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "Design enterprise serverless platform — build an internal developer platform with self-service Lambda deployment, governance, and operational excellence"
+  tags: [AWS, Lambda, platform, IDP, self-service, governance, enterprise, master]
+
+state: {}
+
+trigger: |
+  Your organization (500 engineers, 200+ Lambda functions) needs
+  an Internal Developer Platform (IDP) for serverless. Currently:
+
+  - Each team deploys Lambda functions differently (SAM, CDK,
+    Serverless Framework, console)
+  - No standard for logging, metrics, or error handling
+  - Security reviews take 2 weeks per function deployment
+  - New developers take 3 weeks to deploy their first function
+  - 40% of production incidents stem from misconfiguration
+
+  Platform requirements:
+
+  Developer experience: "I want to create and deploy a new Lambda
+  function in under 30 minutes with zero infrastructure knowledge."
+
+  Security team: "Every function must pass security checks
+  automatically. No manual reviews needed for standard deployments."
+
+  Operations: "We need unified observability across all functions,
+  automated incident detection, and self-healing capabilities."
+
+  Finance: "Cost attribution per team, per service, per feature."
+
+  Proposed platform layers:
+
+  Layer 1 — Templates and Standards:
+  CDK constructs for approved patterns (API + Lambda, SQS + Lambda,
+  EventBridge + Lambda). Pre-configured: logging, tracing, error
+  handling, security, cost tagging.
+
+  Layer 2 — CI/CD Pipeline:
+  Standardized pipeline: build → test → scan → deploy staging →
+  integration test → deploy production (canary). Automatic rollback.
+
+  Layer 3 — Governance:
+  AWS Config rules for compliance, IAM permission boundaries,
+  cost alerts per team, deployment policies (no console deployments).
+
+  Layer 4 — Observability:
+  Centralized logging (Powertools), unified dashboards, automated
+  alerting, incident detection.
+
+  Task: Design the serverless platform. Write: template library
+  design (CDK constructs), developer onboarding experience, automated
+  governance (security, cost, compliance), observability standard,
+  platform team structure, and success metrics.
+
+assertions:
+  - type: llm_judge
+    criteria: "Template library is well-designed — CDK construct library: pre-built, opinionated patterns for common Lambda use cases. Each construct includes: Lambda function with Powertools (logging, metrics, tracing), IAM role with least privilege, CloudWatch alarms, X-Ray tracing, cost tags. Patterns: API endpoint (API Gateway + Lambda + DynamoDB), event processor (SQS + Lambda), scheduled task (EventBridge + Lambda), stream processor (Kinesis + Lambda). Templates enforce standards without restricting developers. Escape hatch for non-standard use cases with security review"
+    weight: 0.35
+    description: "Template library"
+  - type: llm_judge
+    criteria: "Developer experience and governance are covered — onboarding: developer runs 'create-service' CLI command, selects template, gets deployed service in 30 minutes with full observability. Self-service: no tickets for standard deployments. Governance: IAM permission boundaries (prevent privilege escalation), AWS Config rules (detect non-compliant resources), SCPs (prevent dangerous actions), automated security scanning in CI (no manual review needed for standard patterns). Cost: tagging enforced by CDK constructs, budget alerts per team, cost dashboards in platform portal"
+    weight: 0.35
+    description: "Developer experience"
+  - type: llm_judge
+    criteria: "Platform team and metrics are practical — team structure: 4-6 engineers (2 platform/IaC, 1 security, 1 observability, 1-2 developer experience). Platform as a product: treat internal developers as customers, measure NPS, iterate based on feedback. Success metrics: time to first deployment (target: < 1 hour), deployment frequency per team, security findings per deployment (target: 0 for template-based), MTTR (target: < 15 min), developer satisfaction (NPS > 50), platform adoption (% of functions on platform). Cost efficiency: platform team cost / number of functions managed = cost per function decreasing over time"
+    weight: 0.30
+    description: "Team and metrics"

package/courses/docker-container-debugging/course.yaml

@@ -0,0 +1,11 @@
+id: docker-container-debugging
+name: "Docker Container Debugging"
+description: >
+  Master Docker container debugging from basic container inspection to
+  enterprise container platform operations. Learn to diagnose build failures,
+  runtime crashes, networking issues, storage problems, image optimization,
+  multi-stage builds, Docker Compose troubleshooting, security scanning,
+  and production container operations at scale.
+levels: 5
+scenarios_per_level: 10
+tags: [development, Docker, containers, debugging, DevOps, troubleshooting, images, networking]

package/courses/docker-container-debugging/scenarios/level-1/container-exit-codes.yaml

@@ -0,0 +1,59 @@
+meta:
+  id: container-exit-codes
+  level: 1
+  course: docker-container-debugging
+  type: output
+  description: "Debug container exit codes — understand what different exit codes mean and how to diagnose why a container stopped"
+  tags: [Docker, exit-codes, container-lifecycle, debugging, beginner]
+
+state: {}
+
+trigger: |
+  You're running several containers and some keep stopping unexpectedly:
+
+  $ docker ps -a
+  CONTAINER ID   IMAGE          STATUS                      NAMES
+  a1b2c3d4e5f6   myapp:v1.2     Exited (1) 5 minutes ago    api-server
+  b2c3d4e5f6g7   worker:latest  Exited (137) 2 minutes ago  background-worker
+  c3d4e5f6g7h8   nginx:1.25     Exited (0) 10 minutes ago   web-proxy
+  d4e5f6g7h8i9   mydb:v3        Exited (139) 1 minute ago   database
+
+  Four containers, four different exit codes:
+  - Exit code 0: Completed successfully (normal termination)
+  - Exit code 1: General application error
+  - Exit code 137: Killed by SIGKILL (128 + 9) — OOM kill or docker kill
+  - Exit code 139: Segmentation fault (128 + 11)
+
+  $ docker logs api-server
+  Error: Cannot connect to database at localhost:5432
+  Error: Configuration validation failed
+  Process exited with code 1
+
+  $ docker inspect background-worker --format='{{.State.OOMKilled}}'
+  true
+
+  The background-worker was OOM killed — it exceeded its memory limit.
+  The api-server had an application error (database connection failure).
+  The web-proxy exited cleanly (exit code 0 means success).
+  The database had a segfault (exit code 139, likely corrupted data or
+  incompatible library).
+
+  Task: Explain Docker container exit codes. Write: the common exit
+  codes and what they mean (0, 1, 126, 127, 137, 139, 143), how to
+  investigate why a container stopped (docker logs, docker inspect),
+  the difference between SIGKILL (137) and SIGTERM (143), how to check
+  if OOM killed, and the container lifecycle states.
+
+assertions:
+  - type: llm_judge
+    criteria: "Common exit codes are explained — 0: success, 1: general error (application crash), 126: command not executable (permission denied), 127: command not found (wrong CMD/ENTRYPOINT), 137: SIGKILL (128+9, OOM kill or docker kill), 139: SIGSEGV segfault (128+11), 143: SIGTERM (128+15, graceful shutdown via docker stop). Codes > 128 indicate the process was killed by a signal (code = 128 + signal number)"
+    weight: 0.35
+    description: "Exit codes explained"
+  - type: llm_judge
+    criteria: "Investigation commands are shown — docker logs <container> for stdout/stderr output, docker inspect <container> for full state including OOMKilled flag and exit code, docker inspect --format='{{.State.ExitCode}}' for just the exit code, docker events for real-time container events. docker inspect also shows StartedAt/FinishedAt timestamps and RestartCount"
+    weight: 0.35
+    description: "Investigation commands"
+  - type: llm_judge
+    criteria: "Container lifecycle states are explained — created (container exists but never started), running (process active), paused (process frozen via cgroups), exited (process terminated, exit code available), dead (failed to remove, needs manual cleanup). docker ps shows running containers, docker ps -a shows all including stopped. SIGTERM vs SIGKILL: docker stop sends SIGTERM, waits grace period (default 10s), then SIGKILL"
+    weight: 0.30
+    description: "Lifecycle states"

package/courses/docker-container-debugging/scenarios/level-1/container-networking-basics.yaml

@@ -0,0 +1,69 @@
+meta:
+  id: container-networking-basics
+  level: 1
+  course: docker-container-debugging
+  type: output
+  description: "Debug basic Docker networking — diagnose container-to-container communication failures and DNS resolution issues"
+  tags: [Docker, networking, bridge, DNS, container-communication, beginner]
+
+state: {}
+
+trigger: |
+  You have two containers that need to communicate but can't reach
+  each other:
+
+  $ docker run -d --name database postgres:16
+  $ docker run -d --name api -e DATABASE_HOST=database myapp:v1
+
+  $ docker logs api
+  Error: getaddrinfo ENOTFOUND database
+  Error: Cannot resolve hostname 'database'
+
+  The api container can't resolve the hostname "database". Why?
+
+  $ docker network ls
+  NETWORK ID     NAME      DRIVER    SCOPE
+  abc123def456   bridge    bridge    local
+  ...
+
+  Both containers are on the default bridge network, but the default
+  bridge network does NOT support automatic DNS resolution. Container
+  names can't be used as hostnames on the default bridge.
+
+  Fix: Create a custom network:
+  $ docker network create myapp-network
+  $ docker run -d --name database --network myapp-network postgres:16
+  $ docker run -d --name api --network myapp-network -e DATABASE_HOST=database myapp:v1
+
+  $ docker logs api
+  Connected to database at database:5432
+
+  Custom bridge networks provide:
+  - Automatic DNS resolution (container names as hostnames)
+  - Network isolation (containers on different networks can't communicate)
+  - Better security than the default bridge
+
+  Additional test:
+  $ docker exec api ping database
+  PING database (172.18.0.2): 56 data bytes
+  64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.089 ms
+
+  Task: Explain Docker networking basics. Write: the network drivers
+  (bridge, host, none, overlay), why the default bridge doesn't support
+  DNS, how custom networks enable service discovery, how to connect
+  containers across networks, common networking mistakes, and how to
+  inspect network configuration.
+
+assertions:
+  - type: llm_judge
+    criteria: "Docker network drivers are explained — bridge (default, isolated network on single host), host (shares host network namespace, no isolation), none (no networking), overlay (multi-host networking for Swarm). Default bridge does NOT support automatic DNS resolution between containers — only custom bridge networks do. This is the most common networking mistake for beginners"
+    weight: 0.35
+    description: "Network drivers"
+  - type: llm_judge
+    criteria: "DNS and service discovery are covered — on custom bridge networks, Docker runs an embedded DNS server (127.0.0.11). Containers can resolve each other by name. Network aliases (--network-alias) provide additional DNS names. Containers on different networks are isolated by default. Use docker network connect to add a container to a second network for cross-network communication"
+    weight: 0.35
+    description: "DNS and discovery"
+  - type: llm_judge
+    criteria: "Debugging and inspection are practical — docker network inspect <network> shows connected containers and their IPs, docker exec <container> ping <target> tests connectivity, docker exec <container> nslookup <hostname> tests DNS. Common mistakes: using default bridge (no DNS), hardcoding IPs (change on restart), forgetting to put containers on the same network, port conflicts when using host network"
+    weight: 0.30
+    description: "Debugging and inspection"