dojo.md 0.1.0 → 0.2.1

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"

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

@@ -0,0 +1,67 @@
+meta:
+  id: docker-logs-debugging
+  level: 1
+  course: docker-container-debugging
+  type: output
+  description: "Debug with Docker logs — learn to use docker logs, docker inspect, and docker exec for systematic container troubleshooting"
+  tags: [Docker, logs, inspect, exec, debugging-commands, beginner]
+
+state: {}
+
+trigger: |
+  Your containerized web application is running but returning 500
+  errors. You need to figure out what's wrong.
+
+  $ docker ps
+  CONTAINER ID   IMAGE          STATUS         PORTS                  NAMES
+  a1b2c3d4e5f6   webapp:v2.1    Up 3 minutes   0.0.0.0:8080->3000/tcp api
+
+  $ curl http://localhost:8080/health
+  {"status":"error","message":"database connection failed"}
+
+  Step 1 — Check logs:
+  $ docker logs api
+  [2025-12-01T10:00:00] Starting server on port 3000
+  [2025-12-01T10:00:01] Error: connect ECONNREFUSED 172.17.0.5:5432
+  [2025-12-01T10:00:02] Retrying database connection (1/5)...
+  [2025-12-01T10:00:03] Error: connect ECONNREFUSED 172.17.0.5:5432
+  [2025-12-01T10:00:08] All retry attempts failed. Running in degraded mode.
+
+  Step 2 — Inspect the container:
+  $ docker inspect api --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'
+  172.17.0.3
+
+  $ docker inspect api --format='{{json .Config.Env}}' | jq
+  ["DATABASE_URL=postgres://user:pass@172.17.0.5:5432/mydb", "NODE_ENV=production"]
+
+  The DATABASE_URL points to 172.17.0.5 but is that IP still valid?
+
+  Step 3 — Exec into the container:
+  $ docker exec -it api sh
+  /app $ ping 172.17.0.5
+  PING 172.17.0.5: 56 data bytes
+  --- 172.17.0.5 ping statistics ---
+  3 packets transmitted, 0 received, 100% packet loss
+
+  The database container IP changed (it was restarted and got a new IP).
+  The hardcoded IP in DATABASE_URL is stale.
+
+  Task: Explain the Docker debugging toolkit. Write: how to use docker
+  logs (with --follow, --since, --tail), docker inspect for container
+  metadata, docker exec for interactive debugging, docker stats for
+  resource monitoring, docker events for real-time lifecycle events,
+  and the systematic approach to diagnosing container issues.
+
+assertions:
+  - type: llm_judge
+    criteria: "Docker logs usage is comprehensive — docker logs <container> shows stdout/stderr, --follow (-f) streams in real-time, --since '10m' shows last 10 minutes, --tail 100 shows last 100 lines, --timestamps adds timestamps. For containers that write logs to files instead of stdout, logs command shows nothing — must exec into container or mount log volume"
+    weight: 0.35
+    description: "Docker logs"
+  - type: llm_judge
+    criteria: "Docker inspect and exec are explained — docker inspect returns full JSON metadata (network settings, env vars, mounts, state, config). Use --format with Go templates to extract specific fields. docker exec -it <container> sh opens interactive shell for debugging (check files, environment, network). docker exec can also run one-off commands: docker exec api env, docker exec api cat /etc/hosts"
+    weight: 0.35
+    description: "Inspect and exec"
+  - type: llm_judge
+    criteria: "Systematic debugging approach is shown — (1) docker ps to check container status, (2) docker logs for application errors, (3) docker inspect for configuration and network info, (4) docker exec to investigate inside the container, (5) docker stats for resource usage. The IP issue demonstrates why you should use container names or Docker DNS instead of hardcoded IPs. Use Docker networks for reliable service discovery"
+    weight: 0.30
+    description: "Systematic approach"