dojo.md 0.2.0 → 0.2.2

package/courses/GENERATION_LOG.md

@@ -468,3 +468,48 @@ Tracks all auto-generated courses for dojo.md.
 - **Scenarios**: 50 (10 per level × 5 levels)
 - **Type**: output
 - **Sources**: RFC 7807 (Problem Details for HTTP APIs), RFC 9457, RFC 8594 (Sunset header), RFC 5322 (email format), HTTP status code specifications, Google SRE handbook (error budgets, SLOs), OpenTelemetry distributed tracing documentation, GDPR Articles 5/17/30/33/44, PCI DSS v4.0 Requirements 3.4/10.2/10.5/10.6, HIPAA Security Rule, SOC 2 trust service criteria, EU DORA (Digital Operational Resilience Act), India DPDP Act, EU AI Act, SEC cybersecurity disclosure rules, NIST 800-53, Stripe API error handling documentation, Sentry error tracking, Datadog monitoring, PagerDuty incident management, behavioral economics research (anchoring effect, learned helplessness, completion bias, loss aversion, social proof)
+
+### Course 48: Database Query Optimization — PostgreSQL (`postgresql-query-optimization`)
+- **Generated**: 2026-02-27
+- **Category**: Development & DevOps
+- **Directory**: `courses/postgresql-query-optimization/`
+- **Topics researched**: EXPLAIN ANALYZE (reading execution plans, cost estimates, actual vs estimated rows), index fundamentals (B-tree, index scan vs seq scan, selectivity), N+1 queries (detection with pg_stat_statements, batch loading), slow query diagnosis (pg_stat_statements, pg_stat_activity, auto_explain), WHERE clause optimization (SARGable expressions, function wrapping, implicit casts), SELECT * problems (I/O waste, covering index defeat), VACUUM and statistics (autovacuum, dead tuples, default_statistics_target), JOIN algorithms (nested loop, hash join, merge join), query rewriting (NOT IN → NOT EXISTS, UNION → UNION ALL), composite indexes (column ordering, equality-first), partial and expression indexes, covering indexes (INCLUDE columns, index-only scans), CTE optimization (MATERIALIZED/NOT MATERIALIZED, PG 12+ inlining), window functions, query planner settings (work_mem, effective_cache_size, random_page_cost), autovacuum tuning (per-table settings, wraparound prevention), subquery optimization (correlated subqueries to JOINs, EXISTS vs IN, LATERAL joins), partitioning (range/list/hash, partition pruning, partition-wise joins), parallel query execution, connection pooling (PgBouncer, transaction vs session mode), lock contention (advisory locks, deadlock detection), write optimization (COPY vs INSERT, bulk operations), specialized indexes (GIN, GiST, BRIN, SP-GiST, bloom), JSONB optimization (GIN indexing, jsonb_path_ops), full-text search (tsvector/tsquery, GIN indexes, ranking), materialized views (refresh strategies, concurrent refresh, hybrid patterns), optimizer internals (cost model, statistics histograms, MCVs, custom vs generic plans), database migration (logical replication, sequence sync, cutover choreography), high availability (Patroni, streaming replication, automatic failover), vendor evaluation (RDS vs Aurora vs self-managed vs Citus vs Neon, TCO), enterprise governance (configuration standards, automated query review CI/CD), performance SLAs (tiered latency targets, capacity planning, noisy neighbor isolation), executive communication (ROI, technical debt translation, 10x scaling), read replica optimization (workload routing, replication lag management), data architecture (OLTP/OLAP separation, CDC pipelines), expert shift simulation (Black Friday cascading failure), consulting engagements, benchmarks (pgbench methodology, realistic workload design), board strategy (modernization investment, IPO readiness), AI-powered database (autonomous tuning, pgvector, text-to-SQL safety), M&A integration (schema unification, overlapping customers), behavioral science (choice architecture, nudge systems, developer feedback loops), product development (PostgreSQL performance SaaS), comprehensive database platform (self-service provisioning, GitOps schema management), regulatory compliance (GDPR, HIPAA, PCI DSS, SOX, FedRAMP), master shift simulation (triple M&A + multi-framework compliance + IPO + 10x scaling)
+- **Scenarios**: 50 (10 per level × 5 levels)
+- **Type**: output
+- **Sources**: PostgreSQL documentation (EXPLAIN, indexes, partitioning, parallel query, VACUUM, pg_stat_statements, logical replication), pgbench, PgBouncer, Patroni, pgvector, pg_repack, pgAudit, TimescaleDB, Citus, AWS RDS/Aurora PostgreSQL documentation, Google SRE handbook, GDPR, HIPAA Security Rule, PCI DSS v4.0, SOX, FedRAMP/NIST 800-53, FIPS 140-2, behavioral economics (nudge theory, choice architecture)
+
+### Course 49: Database Query Optimization — MySQL (`mysql-query-optimization`)
+- **Generated**: 2026-02-27
+- **Category**: Development & DevOps
+- **Directory**: `courses/mysql-query-optimization/`
+- **Topics researched**: EXPLAIN output (access types, EXPLAIN FORMAT=JSON, EXPLAIN ANALYZE), InnoDB internals (clustered indexes, secondary indexes, UUID vs auto-increment), N+1 queries, slow query log (pt-query-digest, Performance Schema), WHERE clause optimization (SARGable), InnoDB buffer pool (sizing, LRU, hit ratio), JOIN algorithms (nested-loop, hash join 8.0.18+), composite indexes (leftmost prefix rule), covering/invisible indexes, subquery optimization (semi-join strategies, NOT IN NULL trap), optimizer hints, CTE and window functions, buffer pool tuning, Performance Schema analysis, write optimization (LOAD DATA INFILE, innodb_flush_log_at_trx_commit), partitioning (RANGE/LIST/HASH/KEY, partition pruning), ProxySQL connection management, lock contention (gap locks, deadlocks, isolation levels), JSON optimization (multi-valued indexes), full-text search (FULLTEXT, boolean mode), replication optimization (parallel replication), online schema changes (pt-osc, gh-ost), query profiling (EXPLAIN ANALYZE, optimizer trace, handler counters), monitoring (PMM), HA (InnoDB Cluster, Group Replication, Galera), Aurora vs RDS evaluation, enterprise governance, migration planning (5.7→8.0), performance SLAs, executive communication, optimizer internals, data architecture (sharding, Vitess), read replica scaling, consulting, benchmarks, board strategy, AI-powered database, M&A integration, behavioral science, product development, database platform, regulatory compliance
+- **Scenarios**: 50 (10 per level × 5 levels)
+- **Type**: output
+- **Sources**: MySQL documentation (EXPLAIN, InnoDB, Performance Schema, replication, Online DDL), pt-query-digest, pt-online-schema-change, gh-ost, ProxySQL, MySQL Router, InnoDB Cluster/Group Replication, Galera Cluster, Orchestrator, sysbench, AWS RDS/Aurora MySQL, Percona PMM
+
+### Course 50: Kubernetes Deployment Troubleshooting (`kubernetes-deployment-troubleshooting`)
+- **Generated**: 2026-02-27
+- **Category**: Development & DevOps
+- **Directory**: `courses/kubernetes-deployment-troubleshooting/`
+- **Topics researched**: CrashLoopBackOff (exponential backoff, exit codes, env var mismatches), ImagePullBackOff (registry auth, image tags, pull policies), OOMKilled (cgroup OOM killer, exit code 137, JVM container memory), Pending pods (insufficient resources, taints/tolerations, node affinity), Service connectivity (label selectors, endpoints, port vs targetPort, DNS), health probes (liveness/readiness/startup, timing parameters, slow-start protection), ConfigMaps/Secrets (env vars vs volumes, optional references, base64 encoding), deployment rollout (RollingUpdate, maxSurge/maxUnavailable, rollback, progressDeadlineSeconds), kubectl debugging (describe/logs/exec/port-forward/events/top), PersistentVolume issues (PVC binding, StorageClass, CSI drivers, volumeBindingMode), ResourceQuota/LimitRange (QoS classes, namespace limits), init containers (sequential execution, cross-namespace DNS), DNS resolution (CoreDNS, loop detection, ndots, headless services), NetworkPolicy (default-deny, DNS egress, CNI support), HPA scaling (metrics-server, thrashing, stabilization window), Ingress routing (path types, rewrite-target, TLS), RBAC (Role/ClusterRole, ServiceAccount, kubectl auth can-i), Helm deployment (release management, template debugging, stuck releases), node pressure/eviction (MemoryPressure/DiskPressure/PIDPressure, QoS eviction order), StatefulSet (ordered startup, PVC lifecycle, headless services), service mesh (Istio sidecar injection, mTLS, VirtualService/DestinationRule), monitoring gaps (Prometheus ServiceMonitor, Alertmanager, PrometheusRule), PodDisruptionBudgets (voluntary disruptions, node drain, maintenance), GitOps drift (ArgoCD sync/health, auto-sync, CRD dependencies), multi-container pods (sidecar patterns, shared volumes, native sidecars K8s 1.29+), cluster upgrades (API deprecation, version skew, Pod Security Standards), Job/CronJob (concurrencyPolicy, stuck jobs, history limits), multi-cluster operations (cross-cluster discovery, federated monitoring, failover), capacity planning (right-sizing, VPA, cost optimization, Karpenter), disaster recovery (Velero, etcd backup, RPO/RTO), multi-tenancy (namespace isolation, PCI-DSS compliance, GPU taints), incident management (severity classification, SLO/SLI, blameless postmortems), platform engineering (IDP, golden paths, Backstage, developer experience), security hardening (Pod Security Standards, supply chain security, image scanning), cost optimization (FinOps, spot instances, cost attribution), executive communication (ROI, serverless comparison, business case), consulting engagement (migration assessment, remediation roadmap), industry benchmarks (CNCF maturity model, DORA metrics), board strategy (infrastructure as competitive advantage), cloud-native future (WebAssembly, eBPF, AI/ML workloads, edge), M&A integration (cross-cloud connectivity, team onboarding), behavioral science (cognitive biases in incident response), product development (automated troubleshooting platform), comprehensive platform design, regulatory compliance (SOC2/PCI-DSS/HIPAA/GDPR)
+- **Scenarios**: 50 (10 per level × 5 levels)
+- **Type**: output
+- **Sources**: Kubernetes documentation (pod lifecycle, probes, RBAC, networking, storage, scheduling), Istio/Linkerd service mesh docs, Prometheus/Grafana/Alertmanager, ArgoCD/Flux, Velero backup, Helm, Cilium/eBPF, Karpenter, CNCF Cloud Native Maturity Model, DORA metrics research
+
+### Course 51: Docker Container Debugging (`docker-container-debugging`)
+- **Generated**: 2026-02-27
+- **Category**: Development & DevOps
+- **Directory**: `courses/docker-container-debugging/`
+- **Topics researched**: Container exit codes (0/1/137/139/143, OOMKilled, SIGTERM/SIGKILL), Dockerfile build failures (COPY context, multi-stage FROM, apt-get layers), docker logs debugging (--since, --follow, log drivers, json-file), port mapping (host:container, protocol, bridge network, port conflicts), volume mounts (bind mounts vs named volumes, permissions, :ro/:rw), environment variables (build-time ARG vs runtime ENV, variable expansion, .env files), image pull failures (authentication, manifest platform mismatch, rate limits), container networking (bridge/host/overlay, DNS 127.0.0.11, custom networks), resource limits and OOM (--memory, --cpus, cgroup enforcement), Docker Compose debugging (depends_on conditions, YAML anchors, docker compose config validation), multi-stage build debugging (COPY --from stage references, target builds, intermediate stages), container health checks (HEALTHCHECK CMD, intervals, retries, unhealthy actions), PID 1 signal handling (tini, dumb-init, SIGTERM forwarding, exec form vs shell form), image layer optimization (layer ordering, .dockerignore, multi-stage for size), logging and log rotation (json-file default no rotation, max-size/max-file, logging drivers, fluentd/syslog), security scanning (Trivy, Docker Scout, Snyk, CVE severity, SBOM, CI/CD integration), network debugging tools (netshoot container, tcpdump, nslookup, netcat, ndots DNS issues), docker exec debugging (distroless containers, namespace sharing, zombie processes, /proc inspection), Docker daemon issues (daemon.json validation, storage driver compatibility, journalctl, live-restore), Docker-in-Docker CI/CD (DinD vs socket mounting, TLS configuration, Kaniko/Buildah alternatives), BuildKit optimization (cache mounts, layer ordering, parallel stages, .dockerignore), container security hardening (non-root, capabilities, seccomp, read-only filesystem, no-new-privileges), overlay network debugging (VXLAN, Swarm ports, MTU issues, VIP vs DNSRR), disk space management (docker system df, selective prune, automated cleanup, prevention), container filesystem debugging (overlay2 mechanics, copy-on-write, whiteout files, docker diff), Docker API automation (REST over Unix socket, SDK versioning, race conditions, socket security), production container operations (zero-downtime deployment, graceful shutdown, image tagging, resource monitoring), advanced debugging shift, container orchestration strategy (Swarm vs Kubernetes evaluation, migration), enterprise image management (Harbor registry, golden images, cosign signing, admission control), container monitoring observability (Prometheus/cAdvisor/Grafana, ELK/Loki, OpenTelemetry/Jaeger), CI/CD pipeline design (BuildKit caching, security gates, canary deployment, DORA metrics), container security architecture (defense-in-depth, Docker socket risks, Falco, compliance), stateful service containers (database volumes, backup/restore, HA, version upgrades), multi-environment management (12-factor, Compose overrides, image promotion, dev-prod parity), container performance engineering (cgroup awareness, profiling, overlay2 I/O, right-sizing), incident response for containers (isolation, evidence preservation, forensics, blast radius), expert debugging shift, consulting container strategy (VM-to-container migration, portfolio assessment, ROI), container platform economics (TCO model, right-sizing, spot instances, financial communication), industry container patterns (maturity model, anti-patterns, industry-specific compliance), container platform architecture (IDP, Backstage, self-service, governance layers), regulatory compliance containers (SOC2/PCI-DSS/HIPAA/FedRAMP control mappings), container technology evolution (WebAssembly, eBPF, serverless containers, MicroVMs), board infrastructure strategy (executive narrative, ROI, competitive positioning), disaster recovery containers (tiered RPO/RTO, multi-region, chaos engineering), organizational transformation (change management, team restructuring, DevOps culture), master debugging shift
+- **Scenarios**: 50 (10 per level × 5 levels)
+- **Type**: output
+- **Sources**: Docker documentation (Dockerfile reference, CLI, daemon, networking, storage, security), BuildKit docs, Docker Compose specification, Trivy/Docker Scout/Snyk vulnerability scanners, nicolaka/netshoot, Prometheus/cAdvisor/Grafana, Fluentd/Fluent Bit, OpenTelemetry, Harbor registry, cosign/Sigstore, Falco runtime security, OPA/Kyverno policy engines, Backstage IDP
+
+### Course 52: AWS Lambda Function Debugging (`aws-lambda-debugging`)
+- **Generated**: 2026-02-27
+- **Category**: Development & DevOps
+- **Directory**: `courses/aws-lambda-debugging/`
+- **Topics researched**: Lambda timeout errors (default 3s, max 15min, REPORT line), IAM permission errors (execution role vs resource policy, AccessDenied diagnosis), cold start basics (INIT_START, Init Duration, warm reuse), handler and import errors (Runtime.ImportModuleError, Runtime.HandlerNotFound, packaging), memory and OOM (signal: killed, memory-CPU relationship, Lambda Power Tuning), CloudWatch Logs (log groups/streams, REPORT fields, structured logging, Logs Insights), environment variable issues (name mismatch, KMS encryption, 4KB limit, Secrets Manager), API Gateway integration (proxy response format, CORS, 502/504 errors), invocation errors (sync vs async, throttling, concurrency limits, retry behavior), VPC networking (ENI provisioning, NAT Gateway vs VPC endpoints, Hyperplane ENIs), SQS event source mapping (batch failures, ReportBatchItemFailures, visibility timeout, DLQ), X-Ray tracing (service map, subsegments, annotations, sampling, correlation), DynamoDB Streams (shard blocking, iterator exhaustion, BisectBatchOnFunctionError), cold start optimization (SnapStart, provisioned concurrency, package optimization, warm-up), Lambda Layers (directory structure, version compatibility, merge order, 250MB limit), async invocation failures (retry behavior, DLQ vs Lambda Destinations, MaximumEventAge), SAM local debugging (sam local invoke, start-api, generate-event, breakpoint debugging, RIE), concurrency management (account vs function limits, reserved vs provisioned, downstream protection), Step Functions debugging (Task states, Catch/Retry, error types, execution history), Lambda@Edge (vs CloudFront Functions, regional logs, edge limits, replication delay), cross-account invocation (resource policies, IAM policies, multi-account patterns), EventBridge patterns (event matching, content filtering, rule targets, cross-account), Powertools observability (Logger, Metrics EMF, Tracer, correlation, custom dashboards), container image Lambda (RIC, ECR, cold start impact, RIE local testing), Lambda extensions (lifecycle phases, resource sharing, performance impact), IaC deployment debugging (SAM/CDK/CloudFormation stack states, drift, rollback), Kinesis stream processing (shards, parallelization factor, enhanced fan-out), serverless architecture design (Lambda vs containers, choreography vs orchestration, saga pattern), serverless security (per-function IAM, injection prevention, OWASP), cost optimization (right-sizing, ARM/Graviton2, CloudWatch costs, FinOps), multi-region serverless (active-active, DynamoDB Global Tables, Route53 failover), testing strategy (testing pyramid, mocking AWS SDK, contract testing), observability platform (centralized logging, cross-account tracing, alert strategy), incident management (actionable alerts, runbooks, automated remediation, SLOs), serverless migration (strangler fig, monolith decomposition, RDS Proxy), serverless data architecture (DynamoDB patterns, CDC pipeline, Athena/S3 analytics), consulting engagement (readiness assessment, migration roadmap, ROI), serverless economics (TCO comparison, break-even analysis, decision framework), board strategy (executive narrative, DORA metrics, risk analysis), technology evolution (SnapStart, Wasm, AI/ML, edge computing), industry patterns (fintech, healthcare, e-commerce, IoT maturity), regulatory compliance (SOC2/PCI-DSS/HIPAA/GDPR shared responsibility), serverless platform design (CDK constructs, self-service, governance), organizational transformation (change management, training, culture), M&A integration (account consolidation, data merge, team onboarding)
+- **Scenarios**: 50 (10 per level × 5 levels)
+- **Type**: output
+- **Sources**: AWS Lambda documentation (lifecycle, invocation types, event sources, VPC, layers, extensions), AWS SAM/CDK documentation, API Gateway docs, CloudWatch/X-Ray monitoring, Step Functions workflow docs, DynamoDB Streams, SQS/SNS/EventBridge, Kinesis Data Streams, Lambda Powertools (Python/TypeScript/Java), AWS Well-Architected Serverless Lens, DORA metrics research

package/courses/aws-lambda-debugging/course.yaml

@@ -0,0 +1,11 @@
+id: aws-lambda-debugging
+name: "AWS Lambda Function Debugging"
+description: >
+  Master AWS Lambda function debugging from basic invocation errors to
+  enterprise serverless platform operations. Learn to diagnose cold starts,
+  timeout issues, permission failures, memory problems, event source mapping
+  errors, layer conflicts, VPC connectivity, Step Functions orchestration,
+  and production serverless operations at scale.
+levels: 5
+scenarios_per_level: 10
+tags: [development, AWS, Lambda, serverless, debugging, cloud, FaaS, event-driven]

package/courses/aws-lambda-debugging/scenarios/level-1/api-gateway-integration.yaml

@@ -0,0 +1,71 @@
+meta:
+  id: api-gateway-integration
+  level: 1
+  course: aws-lambda-debugging
+  type: output
+  description: "Debug Lambda and API Gateway integration — diagnose response format errors, CORS issues, and proxy integration mismatches"
+  tags: [AWS, Lambda, API-Gateway, CORS, proxy-integration, response-format, beginner]
+
+state: {}
+
+trigger: |
+  Your Lambda function works when invoked directly but returns 502
+  Bad Gateway when called through API Gateway:
+
+  $ curl https://api.example.com/orders
+  {"message": "Internal server error"}
+
+  API Gateway CloudWatch Logs show:
+  Execution failed due to configuration error:
+  Malformed Lambda proxy response
+
+  The Lambda function returns:
+  return { "statusCode": 200, "body": orders }
+
+  But API Gateway Lambda Proxy Integration requires a specific format:
+  {
+    "statusCode": 200,
+    "headers": { "Content-Type": "application/json" },
+    "body": "{\"orders\": [...]}"  // body MUST be a string!
+  }
+
+  The body must be a JSON string, not an object. And headers must
+  be included.
+
+  After fixing the response format, a CORS error appears:
+  Access to XMLHttpRequest at 'https://api.example.com/orders'
+  from origin 'https://myapp.com' has been blocked by CORS policy:
+  No 'Access-Control-Allow-Origin' header is present.
+
+  CORS headers must be returned by the Lambda function (not just
+  configured in API Gateway for proxy integration):
+  {
+    "statusCode": 200,
+    "headers": {
+      "Content-Type": "application/json",
+      "Access-Control-Allow-Origin": "https://myapp.com",
+      "Access-Control-Allow-Methods": "GET,POST,OPTIONS",
+      "Access-Control-Allow-Headers": "Content-Type,Authorization"
+    },
+    "body": JSON.stringify({ orders: [...] })
+  }
+
+  Task: Explain API Gateway + Lambda debugging. Write: the proxy
+  integration response format requirement, common response format
+  errors and fixes, CORS with Lambda proxy, API Gateway error codes
+  (502 = malformed response, 504 = Lambda timeout, 403 = auth),
+  and how to test API Gateway integrations.
+
+assertions:
+  - type: llm_judge
+    criteria: "Response format is explained — Lambda proxy integration requires: statusCode (integer), headers (object, optional but recommended), body (string — must JSON.stringify objects!), isBase64Encoded (boolean, for binary). Missing statusCode or non-string body = 502 Malformed Lambda proxy response. Common mistake: returning a raw object instead of JSON.stringify for body. Non-proxy integration allows mapping templates but is more complex to configure"
+    weight: 0.35
+    description: "Response format"
+  - type: llm_judge
+    criteria: "CORS and error codes are covered — CORS with proxy integration: Lambda must return Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers in response headers. API Gateway CORS configuration only handles the OPTIONS preflight — actual response headers come from Lambda. Error codes: 502 = malformed Lambda response or Lambda error, 504 = Lambda timeout (API GW has 29s hard limit), 403 = missing/invalid API key or authorizer rejection, 429 = throttled. Check API Gateway execution logs (enable in stage settings) for details"
+    weight: 0.35
+    description: "CORS and errors"
+  - type: llm_judge
+    criteria: "Testing approach is practical — test Lambda independently first: aws lambda invoke. Then test via API Gateway: use the API Gateway console's test feature (shows request/response transformation). Use curl -v to see full HTTP response headers. Enable API Gateway execution logging (detailed) for debugging. Check both Lambda CloudWatch Logs and API Gateway CloudWatch Logs. Use AWS SAM CLI (sam local start-api) for local testing of the full API Gateway → Lambda integration. Postman or httpie for systematic API testing"
+    weight: 0.30
+    description: "Testing approach"

package/courses/aws-lambda-debugging/scenarios/level-1/cloudwatch-logs-basics.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: cloudwatch-logs-basics
+  level: 1
+  course: aws-lambda-debugging
+  type: output
+  description: "Debug Lambda with CloudWatch Logs — read log streams, understand the REPORT line, and use structured logging for effective debugging"
+  tags: [AWS, Lambda, CloudWatch, logs, REPORT, structured-logging, beginner]
+
+state: {}
+
+trigger: |
+  Your Lambda function returns an error but you don't know why.
+  Time to check the logs:
+
+  $ aws logs filter-log-events \
+    --log-group-name /aws/lambda/process-order \
+    --start-time 1701432000000
+
+  Each invocation produces these log entries:
+
+  START RequestId: abc-123 Version: $LATEST
+  2024-12-01T10:00:00.123Z abc-123 INFO Processing order: ORD-456
+  2024-12-01T10:00:00.456Z abc-123 INFO Fetching customer: CUST-789
+  2024-12-01T10:00:01.789Z abc-123 ERROR Customer not found: CUST-789
+  2024-12-01T10:00:01.790Z abc-123 ERROR {
+    "errorType": "CustomerNotFoundError",
+    "errorMessage": "Customer CUST-789 does not exist",
+    "stackTrace": ["at getCustomer (/var/task/handler.js:25:11)"]
+  }
+  END RequestId: abc-123
+  REPORT RequestId: abc-123 Duration: 1667.45 ms
+  Billed Duration: 1668 ms Memory Size: 256 MB
+  Max Memory Used: 89 MB Init Duration: 423.12 ms
+
+  Understanding the REPORT line:
+  - Duration: actual execution time (1667.45ms)
+  - Billed Duration: rounded up for billing (1668ms)
+  - Memory Size: configured memory (256MB)
+  - Max Memory Used: peak memory during execution (89MB)
+  - Init Duration: cold start initialization time (only on cold starts)
+
+  Problem: The logs are unstructured text, making it hard to search
+  across thousands of invocations. Better approach: structured JSON
+  logging with correlation IDs.
+
+  Task: Explain CloudWatch Logs for Lambda debugging. Write: how
+  Lambda logs are organized (log groups, log streams), understanding
+  the REPORT line metrics, structured logging best practices (JSON
+  format, correlation IDs), searching logs (filter patterns, Logs
+  Insights queries), and common logging mistakes to avoid.
+
+assertions:
+  - type: llm_judge
+    criteria: "Log organization is explained — log group: /aws/lambda/<function-name> (one per function). Log streams: one per execution environment (not per invocation — multiple warm invocations share a stream). Each invocation has START, your logs, END, and REPORT markers. RequestId links all entries for one invocation. CloudWatch Logs Insights: SQL-like query language to search across streams. Example: filter @message like /ERROR/ | stats count() by bin(1h)"
+    weight: 0.35
+    description: "Log organization"
+  - type: llm_judge
+    criteria: "REPORT line and structured logging are covered — REPORT fields: Duration (actual), Billed Duration (billing), Memory Size (configured), Max Memory Used (peak, for right-sizing), Init Duration (cold start only, absent on warm). XRAY TraceId appears if tracing enabled. Structured logging: use JSON format with consistent fields (requestId, level, message, timestamp). Libraries: Powertools for AWS Lambda (Python/TypeScript/Java) provides structured logging, tracing, metrics. Include correlation IDs (orderId, customerId) for tracing business transactions"
+    weight: 0.35
+    description: "REPORT and structured logging"
+  - type: llm_judge
+    criteria: "Practical tips are included — common mistakes: logging sensitive data (PII, credentials), excessive logging (increases costs and CloudWatch charges), not setting log retention (logs stored forever by default = growing costs). Set retention policy: 7/14/30 days based on needs. Use log levels (DEBUG in dev, INFO/WARN in prod). CloudWatch Logs Insights queries are powerful: parse, filter, stats, sort. Cost awareness: CloudWatch Logs charged per GB ingested — structured logging with appropriate levels controls costs"
+    weight: 0.30
+    description: "Practical tips"

package/courses/aws-lambda-debugging/scenarios/level-1/cold-start-basics.yaml

@@ -0,0 +1,70 @@
+meta:
+  id: cold-start-basics
+  level: 1
+  course: aws-lambda-debugging
+  type: output
+  description: "Debug Lambda cold start issues — understand cold vs warm invocations, identify cold start impact, and apply basic optimization techniques"
+  tags: [AWS, Lambda, cold-start, performance, initialization, beginner]
+
+state: {}
+
+trigger: |
+  Users complain that your API is "sometimes slow." CloudWatch metrics
+  show the Lambda function behind API Gateway has inconsistent latency:
+
+  Most requests: 50-100ms
+  Some requests: 2,000-5,000ms (40x slower!)
+
+  CloudWatch Logs reveal the pattern:
+
+  Slow invocation (cold start):
+  INIT_START Runtime Version: nodejs20.x
+  START RequestId: abc-123
+  2024-12-01T10:00:00.000Z Connecting to database...
+  2024-12-01T10:00:01.500Z Database connected
+  2024-12-01T10:00:02.000Z Processing request...
+  END RequestId: abc-123
+  REPORT RequestId: abc-123 Duration: 2100.00 ms
+  Billed Duration: 2100 ms Init Duration: 1850.00 ms
+
+  Fast invocation (warm):
+  START RequestId: def-456
+  2024-12-01T10:01:00.000Z Processing request...
+  END RequestId: def-456
+  REPORT RequestId: def-456 Duration: 55.00 ms
+  Billed Duration: 56 ms
+
+  The key difference: "Init Duration" appears only on cold starts.
+  This is the time Lambda takes to:
+  1. Download your code package
+  2. Start the runtime (Node.js/Python/Java)
+  3. Run initialization code (imports, DB connections, SDK setup)
+
+  After a cold start, the execution environment is reused for
+  subsequent invocations (warm starts) — no Init Duration.
+
+  Cold starts happen when:
+  - First invocation after deployment
+  - Scaling up (new concurrent executions)
+  - After ~15 minutes of inactivity (environment recycled)
+
+  Task: Explain Lambda cold starts. Write: what causes cold starts,
+  how to identify them in logs (INIT_START, Init Duration in REPORT),
+  factors affecting cold start duration (package size, runtime,
+  memory, VPC), basic optimizations (minimize dependencies, increase
+  memory, init code outside handler), and when cold starts matter
+  vs when they don't.
+
+assertions:
+  - type: llm_judge
+    criteria: "Cold start mechanics are explained — cold start = Lambda creates new execution environment (download code, start runtime, run init). Identified by: INIT_START in logs, Init Duration in REPORT line. Warm start reuses existing environment — no init overhead. Cold starts happen: first invocation, scaling up new instances, after idle timeout (~15 min). Factors: package size (larger = slower download), runtime (Java/C# slowest, Python/Node fastest), memory setting (more memory = more CPU = faster init), VPC adds ENI attachment time"
+    weight: 0.35
+    description: "Cold start mechanics"
+  - type: llm_judge
+    criteria: "Basic optimizations are covered — minimize package size: remove unused dependencies, use tree shaking, use Lambda layers for shared code. Increase memory: Lambda allocates CPU proportional to memory — 1769MB = 1 vCPU. Higher memory = faster initialization. Init code outside handler: database connections, SDK clients created at module level are reused across warm invocations. Avoid importing unused modules. For critical latency: provisioned concurrency keeps environments warm (eliminates cold starts entirely)"
+    weight: 0.35
+    description: "Basic optimizations"
+  - type: llm_judge
+    criteria: "When cold starts matter is explained — matters: synchronous APIs (user-facing latency), real-time processing. Doesn't matter: async processing (SQS consumers, S3 events), batch jobs, scheduled tasks. Cold start frequency: at steady traffic with consistent load, most invocations are warm. Spiky traffic causes more cold starts. Monitor: CloudWatch metric ConcurrentExecutions shows scaling events. p99 latency includes cold starts, p50 typically doesn't. Evaluate whether cold start optimization is worth the effort based on actual user impact"
+    weight: 0.30
+    description: "When it matters"

package/courses/aws-lambda-debugging/scenarios/level-1/environment-variable-issues.yaml

@@ -0,0 +1,72 @@
+meta:
+  id: environment-variable-issues
+  level: 1
+  course: aws-lambda-debugging
+  type: output
+  description: "Debug Lambda environment variable issues — diagnose missing, incorrect, or encrypted environment variables and configuration problems"
+  tags: [AWS, Lambda, environment-variables, configuration, KMS, beginner]
+
+state: {}
+
+trigger: |
+  Your Lambda function fails with a connection error:
+
+  {
+    "errorType": "Error",
+    "errorMessage": "connect ECONNREFUSED 127.0.0.1:5432"
+  }
+
+  The function tries to connect to a database but the connection
+  string is wrong. Checking the code:
+
+  const dbHost = process.env.DATABASE_URL;
+  // dbHost is undefined!
+
+  The environment variable is named DB_URL in the Lambda configuration
+  but the code expects DATABASE_URL. Classic mismatch.
+
+  $ aws lambda get-function-configuration --function-name my-func \
+    --query "Environment.Variables"
+  {
+    "DB_URL": "postgresql://prod-db.example.com:5432/mydb",
+    "API_KEY": "sk-prod-abc123..."
+  }
+
+  Issues found:
+
+  1. Variable name mismatch — DB_URL vs DATABASE_URL. Case-sensitive.
+
+  2. API_KEY is stored as plain text in the Lambda configuration.
+     Anyone with lambda:GetFunctionConfiguration permission can see
+     it. Should use AWS Secrets Manager or encrypted env vars.
+
+  3. After fixing the name, the function still fails in a new
+     deployment. The developer tested with staging env vars but
+     deployed to production without updating them. No environment-
+     specific configuration management.
+
+  4. Environment variables have a 4KB total size limit. A function
+     with many config values hits this limit:
+     "InvalidParameterValueException: Lambda was unable to configure
+     your environment variables because the environment variables you
+     have provided exceeded the 4KB limit."
+
+  Task: Explain Lambda environment variable debugging. Write: how to
+  check and set environment variables (CLI, console, IaC), common
+  mistakes (name mismatches, case sensitivity), encryption with KMS,
+  the 4KB limit and alternatives (Secrets Manager, Parameter Store,
+  S3), and environment management across stages.
+
+assertions:
+  - type: llm_judge
+    criteria: "Environment variable basics are explained — env vars set via console, CLI (aws lambda update-function-configuration --environment), or IaC (SAM/CDK/Terraform). Variables are key-value strings, case-sensitive. Available via process.env (Node.js), os.environ (Python), System.getenv (Java). Common errors: name mismatch between code and config, forgetting to set in new deployments, using wrong values for the environment (staging vs production). Variables are set at deploy time, not runtime"
+    weight: 0.35
+    description: "Environment variable basics"
+  - type: llm_judge
+    criteria: "Security and limits are covered — env vars visible to anyone with lambda:GetFunctionConfiguration permission. Sensitive values: use AWS Secrets Manager (automatic rotation, cross-account access) or SSM Parameter Store (simpler, cheaper). KMS encryption: Lambda can encrypt env vars with custom KMS key — decrypted at runtime. 4KB total limit for all env vars combined. For large config: use Parameter Store (up to 8KB standard, 64KB advanced) or S3 for config files. Never put secrets in plain text env vars — use Secrets Manager"
+    weight: 0.35
+    description: "Security and limits"
+  - type: llm_judge
+    criteria: "Environment management is practical — use IaC (SAM, CDK) with environment-specific parameter files. SAM: --parameter-overrides for stage-specific values. CDK: separate stacks or context variables per environment. Never hardcode environment-specific values in code. Pattern: store environment name as env var (STAGE=prod), look up other config from Parameter Store using STAGE prefix. Validate required env vars at function initialization (fail fast if missing). Use .env files for local development (SAM local supports --env-vars)"
+    weight: 0.30
+    description: "Environment management"

package/courses/aws-lambda-debugging/scenarios/level-1/first-debugging-shift.yaml

@@ -0,0 +1,73 @@
+meta:
+  id: first-debugging-shift
+  level: 1
+  course: aws-lambda-debugging
+  type: output
+  description: "Combined first debugging shift — diagnose a Lambda-based API with timeout, permission, memory, and configuration issues simultaneously"
+  tags: [AWS, Lambda, troubleshooting, combined, shift-simulation, beginner]
+
+state: {}
+
+trigger: |
+  You've joined a team that has a serverless API with 4 Lambda
+  functions behind API Gateway. "The API is broken" — users report
+  various errors. You need to triage everything:
+
+  $ curl https://api.example.com/orders
+  → 502 Bad Gateway
+
+  $ curl https://api.example.com/users
+  → 504 Gateway Timeout (after 29 seconds)
+
+  $ curl https://api.example.com/products
+  → 403 {"message": "Forbidden"}
+
+  $ curl https://api.example.com/payments
+  → 200 but returns empty data instead of payment records
+
+  Investigation:
+
+  1. /orders → 502: Lambda returns malformed response.
+     CloudWatch Logs: function returns {body: orders} without
+     statusCode and body is not a string. Fix: proper proxy
+     integration response format.
+
+  2. /users → 504: Lambda times out.
+     REPORT: Duration 29001ms, timeout is 30s. Function connects
+     to RDS in VPC but has no NAT Gateway for the Secrets Manager
+     call that retrieves the DB password. The Secrets Manager call
+     hangs because there's no internet access from the private subnet.
+     Fix: add VPC endpoint for Secrets Manager, or add NAT Gateway.
+
+  3. /products → 403: API key required but not sent.
+     API Gateway has "API Key Required: true" on this method but
+     documentation doesn't mention it. The API key is correct in
+     the x-api-key header. Fix: send the API key header, or remove
+     the API key requirement if it's unintended.
+
+  4. /payments → 200 but empty: Lambda runs successfully but
+     DynamoDB query returns no items. The function reads from
+     table "Payments" but the actual table is "payments-prod"
+     (different name). The IAM role has permission on "payments-prod"
+     but the code hardcodes "Payments". Fix: use environment variable
+     for table name, update code to match actual table.
+
+  Task: Walk through diagnosing all four issues. Write: the triage
+  approach (check HTTP status codes, then CloudWatch Logs), how
+  to debug each error type, the VPC Lambda networking gotcha,
+  API Gateway configuration checks, and lessons learned for
+  preventing these issues.
+
+assertions:
+  - type: llm_judge
+    criteria: "All four issues are diagnosed — (1) 502 malformed response: fix Lambda proxy response format (statusCode, string body). (2) 504 timeout: VPC Lambda needs NAT Gateway or VPC endpoints for AWS service access. (3) 403 API key: check API Gateway method settings for required API key, send x-api-key header. (4) 200 empty data: code references wrong DynamoDB table name — use environment variables for resource names, not hardcoded strings"
+    weight: 0.35
+    description: "All issues diagnosed"
+  - type: llm_judge
+    criteria: "Triage methodology is systematic — start with HTTP status code (tells error category: 4xx client, 5xx server). Check API Gateway logs first (shows if error is in API GW config or Lambda). Then check Lambda CloudWatch Logs for each function. Read the REPORT line for timeout/memory issues. Check IAM for permission issues. Check VPC configuration for networking issues. Work through issues by severity: 502/504 first (service down), then 403 (auth), then data issues"
+    weight: 0.35
+    description: "Triage methodology"
+  - type: llm_judge
+    criteria: "Prevention lessons are practical — use IaC (SAM/CDK) for consistent configuration. Use environment variables for all resource names (table names, queue URLs, bucket names). Test Lambda responses match API Gateway proxy format before deploying. For VPC Lambda: always plan networking (NAT Gateway or VPC endpoints for AWS services). Document API requirements (API keys, auth). Use local testing (SAM CLI) to catch errors before deployment. Set up CloudWatch alarms for Errors, Throttles, Duration"
+    weight: 0.30
+    description: "Prevention lessons"

package/courses/aws-lambda-debugging/scenarios/level-1/handler-import-errors.yaml

@@ -0,0 +1,71 @@
+meta:
+  id: handler-import-errors
+  level: 1
+  course: aws-lambda-debugging
+  type: output
+  description: "Debug Lambda handler and import errors — diagnose module not found, handler not found, and dependency packaging issues"
+  tags: [AWS, Lambda, handler, import, module-not-found, packaging, beginner]
+
+state: {}
+
+trigger: |
+  Your Lambda function fails immediately on invocation:
+
+  {
+    "errorType": "Runtime.ImportModuleError",
+    "errorMessage": "Unable to import module 'handler': No module named 'requests'"
+  }
+
+  The function works locally but fails in Lambda. The issue: the
+  'requests' library isn't included in the deployment package.
+
+  Lambda runtimes only include standard library modules. Third-party
+  dependencies must be packaged with your code:
+
+  # Python — create deployment package with dependencies:
+  pip install requests -t ./package/
+  cd package && zip -r ../deployment.zip . && cd ..
+  zip deployment.zip handler.py
+
+  Another common error:
+  {
+    "errorType": "Runtime.HandlerNotFound",
+    "errorMessage": "Handler 'app.handler' missing on module 'app'"
+  }
+
+  Causes:
+  1. Wrong handler configuration — Lambda handler format is file.function
+     (Python: handler.lambda_handler, Node: index.handler)
+  2. File is in a subdirectory but handler doesn't include the path
+     (src/handler.lambda_handler won't work — zip must have handler.py
+     at the root)
+  3. Typo in function name
+
+  Node.js variant:
+  {
+    "errorType": "Runtime.UserCodeSyntaxError",
+    "errorMessage": "SyntaxError: Cannot use import statement outside a module"
+  }
+
+  Using ES modules (import/export) requires either:
+  - File extension .mjs, or
+  - "type": "module" in package.json
+
+  Task: Explain Lambda handler and import debugging. Write: the handler
+  format for each runtime (Python, Node.js, Java), common import/module
+  errors and their causes, how to package dependencies correctly (zip,
+  layers, container images), and the deployment package structure.
+
+assertions:
+  - type: llm_judge
+    criteria: "Handler format is explained — Python: file_name.function_name (e.g., handler.lambda_handler). Node.js: file_name.export_name (e.g., index.handler). Java: package.Class::method. The handler file must be at the root of the zip or in the path specified. Runtime.HandlerNotFound: file or function doesn't exist at the expected location. Runtime.ImportModuleError: dependency not included in package. Always test with lambda invoke locally (SAM CLI) before deploying"
+    weight: 0.35
+    description: "Handler format"
+  - type: llm_judge
+    criteria: "Dependency packaging is covered — Python: pip install -t ./package/, include in zip. Use requirements.txt. Node.js: npm install in project, zip node_modules with code. Lambda Layers: shared dependencies across functions (up to 5 layers, 250MB unzipped total). Container images: full control over runtime and dependencies (up to 10GB). Common mistakes: installing for wrong OS (Lambda runs Amazon Linux — build on Linux or use Docker), missing native modules (needs compilation for Lambda architecture: x86_64 or arm64)"
+    weight: 0.35
+    description: "Dependency packaging"
+  - type: llm_judge
+    criteria: "Debugging workflow is practical — check CloudWatch Logs first (error type tells you the category). Runtime.ImportModuleError: dependency missing from package or layer. Runtime.HandlerNotFound: wrong handler config or file structure. Runtime.UserCodeSyntaxError: code syntax issue (ESM vs CJS for Node.js). Test locally: AWS SAM CLI (sam local invoke) simulates Lambda environment. Check package structure: unzip -l deployment.zip to verify file locations. Verify architecture: Lambda ARM (Graviton2) needs arm64 native dependencies"
+    weight: 0.30
+    description: "Debugging workflow"

package/courses/aws-lambda-debugging/scenarios/level-1/iam-permission-errors.yaml

@@ -0,0 +1,68 @@
+meta:
+  id: iam-permission-errors
+  level: 1
+  course: aws-lambda-debugging
+  type: output
+  description: "Debug Lambda IAM permission errors — diagnose AccessDenied errors from missing or incorrect IAM policies"
+  tags: [AWS, Lambda, IAM, permissions, AccessDenied, beginner]
+
+state: {}
+
+trigger: |
+  Your Lambda function fails when trying to read from S3:
+
+  {
+    "errorType": "AccessDeniedException",
+    "errorMessage": "User: arn:aws:sts::123456789012:assumed-role/
+    process-order-role/process-order is not authorized to perform:
+    s3:GetObject on resource: arn:aws:s3:::my-bucket/orders/*"
+  }
+
+  The error clearly states what's missing: s3:GetObject permission on
+  the specific S3 bucket and path.
+
+  Checking the Lambda's execution role:
+  $ aws iam get-role --role-name process-order-role
+  $ aws iam list-attached-role-policies --role-name process-order-role
+
+  The role only has AWSLambdaBasicExecutionRole (CloudWatch Logs).
+  It needs an additional policy for S3 access.
+
+  Fix:
+  $ aws iam put-role-policy --role-name process-order-role \
+    --policy-name S3ReadAccess \
+    --policy-document '{
+      "Version": "2012-10-17",
+      "Statement": [{
+        "Effect": "Allow",
+        "Action": "s3:GetObject",
+        "Resource": "arn:aws:s3:::my-bucket/orders/*"
+      }]
+    }'
+
+  Common IAM mistakes with Lambda:
+  1. Using s3:* instead of specific actions (security risk)
+  2. Using Resource: "*" instead of specific ARNs
+  3. Forgetting that Lambda needs TWO types of permissions:
+     - Execution role: what the function CAN DO (call S3, DynamoDB)
+     - Resource policy: who can INVOKE the function (API GW, S3 events)
+  4. Policy changes take a few seconds to propagate
+
+  Task: Explain Lambda IAM debugging. Write: how to read AccessDenied
+  errors (they tell you exactly what's missing), the execution role
+  vs resource policy distinction, principle of least privilege for
+  Lambda, common IAM mistakes, and how to test permissions.
+
+assertions:
+  - type: llm_judge
+    criteria: "IAM error reading is explained — AccessDenied errors include: the principal (Lambda execution role ARN), the action attempted (s3:GetObject), and the resource ARN. This tells you exactly what permission to add. Two permission types: execution role (attached IAM role — what Lambda can do: read S3, write DynamoDB, publish SNS) and resource-based policy (who can invoke Lambda: API Gateway, S3 event notifications, CloudWatch Events). Both must be correct"
+    weight: 0.35
+    description: "IAM error reading"
+  - type: llm_judge
+    criteria: "Common mistakes and fixes are covered — overly broad permissions (s3:* on Resource: * is dangerous). Always specify exact actions and resource ARNs. Forgetting to add AWSLambdaBasicExecutionRole (needed for CloudWatch Logs). VPC Lambda needs AWSLambdaVPCAccessExecutionRole. Policy propagation delay (wait a few seconds after policy changes). KMS permissions needed when using encrypted resources. Cross-account access requires both resource policy and execution role permissions"
+    weight: 0.35
+    description: "Common mistakes"
+  - type: llm_judge
+    criteria: "Testing and best practices are practical — test permissions: aws iam simulate-principal-policy. Use AWS IAM Access Analyzer to identify overly permissive policies. Start with no permissions, add as needed (least privilege). Use managed policies for common patterns (AmazonDynamoDBReadOnlyAccess). CloudTrail logs every API call — search for AccessDenied events. Use IAM policy conditions for additional security (restrict by source IP, time, VPC). Tag Lambda roles for identification"
+    weight: 0.30
+    description: "Testing and practices"