dojo.md 0.2.0 → 0.2.2

package/courses/aws-lambda-debugging/scenarios/level-4/observability-platform-design.yaml

@@ -0,0 +1,71 @@
+meta:
+  id: observability-platform-design
+  level: 4
+  course: aws-lambda-debugging
+  type: output
+  description: "Design serverless observability platform — implement comprehensive monitoring, alerting, and debugging infrastructure for Lambda applications at enterprise scale"
+  tags: [AWS, Lambda, observability, monitoring, alerting, platform, expert]
+
+state: {}
+
+trigger: |
+  Your organization runs 200+ Lambda functions across 5 AWS accounts.
+  Current monitoring is fragmented:
+
+  - Each team uses different tools (some CloudWatch, some Datadog,
+    some New Relic, some nothing)
+  - No standard for structured logging or metrics
+  - Debugging cross-function issues requires checking logs in
+    multiple accounts and regions manually
+  - Last month's incident took 2 hours to diagnose because nobody
+    could trace the request across 6 Lambda functions
+
+  Management asks: "Build a unified observability platform that
+  lets any engineer debug any issue in under 15 minutes."
+
+  Architecture proposal:
+
+  Logging Layer:
+  All functions → Powertools Logger (structured JSON) →
+  CloudWatch Logs → Subscription Filter → Kinesis Firehose →
+  OpenSearch (centralized) + S3 (archive)
+
+  Metrics Layer:
+  Lambda system metrics + Custom EMF metrics →
+  CloudWatch Metrics (cross-account aggregation) →
+  Grafana dashboards (unified view)
+
+  Tracing Layer:
+  All functions → X-Ray Active Tracing →
+  X-Ray Groups (per-service views) →
+  Cross-account trace access
+
+  Alerting Layer:
+  CloudWatch Alarms → SNS → PagerDuty/Slack
+  Business metric alarms alongside technical alarms
+
+  Cost considerations:
+  - CloudWatch Logs: $0.50/GB ingested (at 200+ functions, this adds up)
+  - OpenSearch cluster: $500-2000/month
+  - Datadog alternative: $5 per host/month but Lambda is per-invocation
+  - X-Ray: $5/million traces
+
+  Task: Design the observability platform. Write: standardized
+  logging (format, correlation), centralized log aggregation,
+  custom metrics and dashboards, distributed tracing across accounts,
+  alert strategy (technical + business), and cost management for
+  observability at scale.
+
+assertions:
+  - type: llm_judge
+    criteria: "Standardized logging is explained — mandatory standard: all functions use Powertools Logger with JSON format. Required fields: service name, function name, request ID, trace ID, log level, timestamp. Business context: order ID, customer ID, etc. Log levels: ERROR and WARN in all environments, INFO in staging/production, DEBUG only in development. Structured logging enables: CloudWatch Logs Insights queries across all functions, automated parsing in OpenSearch, correlation via trace ID and business IDs"
+    weight: 0.35
+    description: "Standardized logging"
+  - type: llm_judge
+    criteria: "Centralized aggregation and tracing are covered — log aggregation: CloudWatch Subscription Filters → Kinesis Firehose → OpenSearch for searchable logs. Cross-account: CloudWatch Logs destination in a central observability account. X-Ray cross-account: centralized trace viewing via X-Ray groups and sampling rules. Alternative: Grafana Loki for logs (cheaper than OpenSearch), Grafana Tempo for traces. Service map: X-Ray service map shows all service dependencies and latency. Correlation: trace ID links logs and traces for any request across all services"
+    weight: 0.35
+    description: "Aggregation and tracing"
+  - type: llm_judge
+    criteria: "Alerting and cost management are practical — alert tiers: P1 (customer-impacting, page immediately), P2 (degraded performance, page during business hours), P3 (warning, ticket). Technical alerts: error rate, duration p99, throttles, OOM, cold start rate. Business alerts: order completion rate, payment success rate, user signup rate. Cost management: log sampling for high-volume functions, log retention policy (7 days hot, 30 days warm, 1 year cold S3), X-Ray sampling rules (reduce trace volume), eliminate unused metrics. Budget: observability should be 5-10% of total infrastructure cost. Track: MTTD (time to detect) and MTTR as key observability success metrics"
+    weight: 0.30
+    description: "Alerting and cost"

package/courses/aws-lambda-debugging/scenarios/level-4/serverless-architecture-design.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: serverless-architecture-design
+  level: 4
+  course: aws-lambda-debugging
+  type: output
+  description: "Design serverless architecture — evaluate event-driven patterns, service boundaries, and Lambda-based system design for enterprise applications"
+  tags: [AWS, Lambda, architecture, serverless, event-driven, design, expert]
+
+state: {}
+
+trigger: |
+  Your company is building a new order management system. The CTO
+  wants "serverless-first" but the team has concerns about Lambda
+  for complex business logic. You need to design the architecture.
+
+  Requirements:
+  - Process 1,000 orders/minute at peak
+  - Sub-second API response time
+  - Complex order workflow: validate → inventory check → payment →
+    fulfillment → notification (5-15 minute total processing)
+  - ACID transactions for payment processing
+  - Real-time dashboard showing order status
+  - 99.95% availability SLA
+
+  Architecture options debated:
+
+  Option A — Pure Lambda:
+  API Gateway → Lambda for every operation. Each step is a Lambda
+  function. State managed in DynamoDB.
+  Concern: complex state management, cold start latency, debugging
+  distributed transactions.
+
+  Option B — Lambda + Step Functions:
+  API Gateway → Lambda (sync response) → Step Functions (async workflow).
+  Step Functions orchestrates the multi-step process with built-in
+  error handling, retries, and state tracking.
+  Concern: Step Functions cost at volume ($25/million state transitions),
+  15-minute standard execution history limit for Express workflows.
+
+  Option C — Hybrid (Lambda + ECS):
+  Lambda for API endpoints and event processing.
+  ECS Fargate for the payment processing service (needs persistent
+  database connections, complex business logic).
+  Concern: operational complexity of managing two compute platforms.
+
+  Task: Design the serverless architecture. Write: when Lambda is
+  the right choice vs containers/EC2, event-driven design patterns
+  (choreography vs orchestration), state management strategies
+  (DynamoDB, Step Functions), handling distributed transactions
+  (saga pattern), and the architecture decision record with trade-offs.
+
+assertions:
+  - type: llm_judge
+    criteria: "Architecture decision is justified — Lambda best for: event-driven processing, API endpoints, data transformation, scheduled tasks, glue logic. Not ideal for: long-running processes (> 15 min), persistent connections, heavy computation, real-time bidirectional communication. Recommended: hybrid — Lambda for APIs + event handlers, Step Functions for workflow orchestration, DynamoDB for state. Payment service: Lambda with idempotency (not ECS) unless complex persistent connection requirements. Step Functions Express for high-volume (cheaper, synchronous), Standard for long-running workflows"
+    weight: 0.35
+    description: "Architecture decision"
+  - type: llm_judge
+    criteria: "Event-driven patterns are covered — choreography: services emit events, other services react independently (EventBridge). Pros: loosely coupled, scalable. Cons: hard to trace, no central workflow view. Orchestration: central coordinator (Step Functions) manages the workflow. Pros: visible state, built-in retry/error handling. Cons: central point of control. Recommendation: orchestration for critical business workflows (orders), choreography for cross-domain events (analytics, notifications). Saga pattern for distributed transactions: each step has a compensating action for rollback"
+    weight: 0.35
+    description: "Event-driven patterns"
+  - type: llm_judge
+    criteria: "Scalability and reliability are practical — 1,000 orders/minute: Lambda handles easily (configure concurrency appropriately). Sub-second API: provisioned concurrency for user-facing endpoints. DynamoDB: on-demand capacity for variable load, or provisioned with auto-scaling. 99.95% SLA: multi-region active-passive with Route53 failover. Real-time dashboard: DynamoDB Streams → Lambda → WebSocket API (API Gateway). Cost estimate at 1,000 orders/min: Lambda (~$50/month), Step Functions (~$75/month), DynamoDB (~$200/month). Total significantly less than ECS/EC2 equivalent"
+    weight: 0.30
+    description: "Scalability and reliability"

package/courses/aws-lambda-debugging/scenarios/level-4/serverless-data-architecture.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: serverless-data-architecture
+  level: 4
+  course: aws-lambda-debugging
+  type: output
+  description: "Design serverless data architecture — implement data storage, processing, and analytics patterns using Lambda with DynamoDB, S3, and streaming services"
+  tags: [AWS, Lambda, data-architecture, DynamoDB, analytics, ETL, expert]
+
+state: {}
+
+trigger: |
+  Your serverless application needs a data architecture that handles:
+  - Transactional data (orders, users, payments)
+  - Analytical queries (daily reports, trend analysis)
+  - Real-time processing (event streams, notifications)
+  - Data lake integration (historical data for ML)
+
+  Current mess:
+  - Everything in DynamoDB (including analytical queries)
+  - Full table scans costing $2K/month in read capacity
+  - No data lake — analytics team exports CSV files manually
+  - Lambda functions with embedded SQL-like logic for reporting
+
+  Proposed architecture:
+
+  Transactional layer:
+  DynamoDB for OLTP (key-value, high throughput, low latency).
+  Design: single-table design with GSIs for access patterns.
+  Lambda reads/writes with DynamoDB SDK.
+
+  Change data capture:
+  DynamoDB Streams → Lambda → Kinesis Firehose → S3 (data lake).
+  All changes replicated to S3 in near-real-time for analytics.
+
+  Analytics layer:
+  S3 (Parquet format) → Athena for SQL queries.
+  QuickSight for dashboards. No separate analytics database needed.
+  Lambda for ETL transformations between formats.
+
+  Real-time:
+  Kinesis Data Streams → Lambda → processed events →
+  EventBridge → downstream consumers.
+
+  ML pipeline:
+  S3 data lake → SageMaker for model training →
+  Lambda for inference (or Bedrock for LLM).
+
+  Task: Design the serverless data architecture. Write: DynamoDB
+  design patterns for Lambda (single-table, access patterns),
+  change data capture pipeline, analytics with Athena/S3, ETL
+  with Lambda (and its limitations for large datasets), real-time
+  processing patterns, and cost optimization for data workloads.
+
+assertions:
+  - type: llm_judge
+    criteria: "DynamoDB design for Lambda is explained — single-table design: model multiple entity types in one table, access patterns drive GSI design. Lambda + DynamoDB: use DocumentClient, batch operations for efficiency, handle ProvisionedThroughputExceededException with exponential backoff. On-demand capacity for unpredictable workloads, provisioned with auto-scaling for steady patterns. Connection reuse: keep SDK client outside handler. TTL for automatic data expiration. Transactions for multi-item atomicity. Avoid: full table scans (use query with partition key), storing large items (max 400KB)"
+    weight: 0.35
+    description: "DynamoDB design"
+  - type: llm_judge
+    criteria: "Data pipeline and analytics are covered — CDC: DynamoDB Streams → Lambda → transform → Kinesis Firehose → S3 (Parquet). Firehose handles batching and compression automatically. S3 data lake: partition by date for efficient Athena queries (year=2024/month=12/day=01/). Athena: serverless SQL on S3, pay per query ($5/TB scanned). Reduce cost: use Parquet (columnar, compressed), partition pruning. Lambda for ETL limitations: 15-minute timeout, 10GB memory max. For large ETL: use AWS Glue or Step Functions with distributed map"
+    weight: 0.35
+    description: "Pipeline and analytics"
+  - type: llm_judge
+    criteria: "Cost optimization is practical — DynamoDB: right-size read/write capacity, use on-demand for variable workloads (avoid over-provisioning). S3: use lifecycle policies (Standard → IA → Glacier). Athena: partition data and use columnar formats to reduce scan cost. Lambda ETL: cost-effective for small transformations but expensive for large datasets (use Glue instead). Data architecture principle: OLTP in DynamoDB, OLAP in Athena/S3, don't mix (DynamoDB scans are expensive). Monitor: DynamoDB consumed capacity, Athena query costs, S3 storage growth. Set budgets per data pipeline"
+    weight: 0.30
+    description: "Cost optimization"

package/courses/aws-lambda-debugging/scenarios/level-4/serverless-migration-strategy.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: serverless-migration-strategy
+  level: 4
+  course: aws-lambda-debugging
+  type: output
+  description: "Design serverless migration strategy — plan migration from monolithic/container applications to Lambda with risk mitigation and team enablement"
+  tags: [AWS, Lambda, migration, monolith, strangler-fig, modernization, expert]
+
+state: {}
+
+trigger: |
+  Your company runs a monolithic Node.js API on EC2 Auto Scaling
+  Groups. The infrastructure costs $25K/month with 3 ops engineers
+  managing servers, patching, and scaling. The CTO wants to migrate
+  to serverless to reduce costs and operational burden.
+
+  Current state:
+  - Monolith: 150K lines of code, Express.js, PostgreSQL
+  - 45 API endpoints, 12 background jobs
+  - 2M requests/day, peak at 500 req/s
+  - Average response time: 200ms
+  - EC2: 8 c5.xlarge instances + RDS Multi-AZ
+  - Team: 15 developers, 3 ops engineers
+
+  Migration approaches:
+
+  Option A — Lift and shift (Lambda Web Adapter):
+  Wrap the existing Express.js app in Lambda using Lambda Web Adapter.
+  Minimal code changes. But: cold starts with 150K LOC = 10+ seconds,
+  15-minute timeout limit for background jobs, connection pooling
+  issues with RDS.
+
+  Option B — Strangler Fig pattern:
+  Migrate one endpoint at a time. New Lambda function per endpoint,
+  API Gateway routes traffic. Old and new run simultaneously.
+  Timeline: 6-12 months for full migration.
+
+  Option C — Rewrite:
+  Rebuild from scratch as serverless-native. Best architecture
+  but highest risk and longest timeline (12-18 months).
+
+  Recommended: Option B with selective rewrites. Start with:
+  1. Background jobs → Lambda + EventBridge (quick win, no user impact)
+  2. Read-heavy endpoints → Lambda + DynamoDB (low risk)
+  3. Write-heavy endpoints → Lambda + RDS Proxy (medium risk)
+  4. Complex business logic → last (highest risk)
+
+  Task: Design the serverless migration strategy. Write: assessment
+  criteria (what migrates well vs poorly), strangler fig approach,
+  database strategy (RDS to DynamoDB vs RDS Proxy), team enablement,
+  risk mitigation, and success metrics.
+
+assertions:
+  - type: llm_judge
+    criteria: "Migration assessment is structured — good Lambda candidates: stateless API endpoints, event-driven processing, scheduled tasks, data transformation, webhooks. Poor candidates: long-running processes (> 15 min), WebSocket connections (use API Gateway WebSocket), heavy computation (consider Fargate), tight database coupling (needs refactoring). Assessment matrix: score each component on statelessness, execution time, dependencies, business criticality, and team readiness. Start with low-risk, high-value candidates"
+    weight: 0.35
+    description: "Migration assessment"
+  - type: llm_judge
+    criteria: "Strangler fig and database strategy are covered — strangler fig: API Gateway routes specific paths to new Lambda functions, everything else to existing monolith via HTTP proxy. Gradually migrate endpoints until monolith is empty. Database: keep RDS initially (Lambda + RDS Proxy for connection pooling), migrate to DynamoDB only for tables that benefit from it (high read, key-value access patterns). Don't force DynamoDB for relational data. Keep PostgreSQL for complex queries. Dual-write period during migration for validation"
+    weight: 0.35
+    description: "Strangler fig"
+  - type: llm_judge
+    criteria: "Team and risk management are practical — team enablement: training program (Lambda basics → event-driven design → testing → operations). Pair experienced serverless developers with migration teams. Start with a pilot team of 3-4 developers. Risk mitigation: keep monolith running until migration is validated (6+ months), implement feature flags for switching between old and new, comprehensive testing at each migration step. Success metrics: infrastructure cost reduction (target: 40-60%), deployment frequency (target: 10x), MTTR (target: 50% reduction), developer velocity (features shipped per sprint)"
+    weight: 0.30
+    description: "Team and risk"

package/courses/aws-lambda-debugging/scenarios/level-4/serverless-security-design.yaml

@@ -0,0 +1,60 @@
+meta:
+  id: serverless-security-design
+  level: 4
+  course: aws-lambda-debugging
+  type: output
+  description: "Design serverless security architecture — implement defense-in-depth for Lambda applications including IAM, API authentication, data protection, and compliance"
+  tags: [AWS, Lambda, security, IAM, authentication, compliance, expert]
+
+state: {}
+
+trigger: |
+  A penetration test on your serverless application found several
+  vulnerabilities:
+
+  Finding 1 — Overly permissive IAM:
+  Lambda execution role has AdministratorAccess. The tester could
+  use the function to access ANY resource in the account.
+  "From inside the Lambda, I called sts:AssumeRole to escalate to
+  any role in the account."
+
+  Finding 2 — Injection through event data:
+  The function constructs a DynamoDB query using unsanitized input:
+  const result = await dynamo.query({
+    KeyConditionExpression: `userId = ${event.userId}`
+  });
+  NoSQL injection: userId = "1 OR 1=1" returns all records.
+
+  Finding 3 — Sensitive data in logs:
+  console.log(JSON.stringify(event));
+  Logs contain: credit card numbers, SSN, passwords from the
+  API request body. CloudWatch Logs retained for 30 days.
+
+  Finding 4 — No API authentication:
+  API Gateway endpoints have no authorizer. Anyone can invoke
+  any endpoint with any data.
+
+  Finding 5 — Dependencies with known CVEs:
+  24 npm packages with known vulnerabilities, including a CRITICAL
+  RCE in a JSON parsing library.
+
+  Task: Design serverless security architecture. Write: IAM least
+  privilege for Lambda (per-function roles), API authentication
+  (Cognito, custom authorizers), input validation and injection
+  prevention, sensitive data handling (no logging PII, encryption),
+  dependency security scanning, and compliance frameworks for
+  serverless (SOC2, HIPAA).
+
+assertions:
+  - type: llm_judge
+    criteria: "IAM and authentication are explained — per-function IAM roles: each Lambda gets its own role with only the permissions it needs. Never use AdministratorAccess or AmazonDynamoDBFullAccess. Specify exact resources (not Resource: *). API authentication: Cognito user pools (managed auth), Lambda authorizers (custom logic), IAM authorization (for service-to-service). API keys for rate limiting (not security). Use AWS WAF on API Gateway for common attack protection (SQL injection, XSS)"
+    weight: 0.35
+    description: "IAM and authentication"
+  - type: llm_judge
+    criteria: "Data protection and input validation are covered — input validation: validate all event data at the function entry point. Use schema validation (Zod, Joi, JSON Schema). Never construct queries with string concatenation — use parameterized queries. Sensitive data: never log PII (use Powertools Logger with data masking). Encrypt sensitive data at rest (KMS). Use Secrets Manager for credentials (not environment variables). CloudWatch Logs: set retention policy, encrypt with KMS. Use AWS Macie to detect PII in logs/S3"
+    weight: 0.35
+    description: "Data protection"
+  - type: llm_judge
+    criteria: "Dependency security and compliance are practical — dependency scanning: npm audit, Snyk, or GitHub Dependabot in CI/CD. Block deployments with CRITICAL CVEs. Keep dependencies updated (automated PRs for patches). Compliance: SOC2 requires audit logging (CloudTrail), access control (IAM), encryption (KMS). HIPAA: BAA with AWS, encrypt PHI, restrict access, audit all data access. PCI-DSS: network segmentation (VPC), encryption, logging, vulnerability management. Serverless advantage: no server patching, no OS hardening. Serverless risk: larger attack surface through event sources, more IAM complexity"
+    weight: 0.30
+    description: "Dependencies and compliance"

package/courses/aws-lambda-debugging/scenarios/level-4/serverless-testing-strategy.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: serverless-testing-strategy
+  level: 4
+  course: aws-lambda-debugging
+  type: output
+  description: "Design serverless testing strategy — implement unit, integration, and end-to-end testing for Lambda applications with mock services and contract testing"
+  tags: [AWS, Lambda, testing, unit-test, integration, mocking, expert]
+
+state: {}
+
+trigger: |
+  Your serverless application has 50 Lambda functions but only 15%
+  test coverage. Bugs frequently reach production because:
+
+  1. Developers don't know how to test Lambda functions locally
+  2. Integration tests require deploying to AWS (slow, expensive)
+  3. No testing strategy for event-driven flows (events are "fire
+     and forget" — how do you verify the chain worked?)
+  4. Mocking AWS services is complex (DynamoDB, SQS, S3)
+
+  Last week, a DynamoDB schema change broke 3 downstream functions.
+  No tests caught it because each function was tested in isolation.
+
+  Testing pyramid for serverless:
+
+  Layer 1 — Unit Tests (70% of tests):
+  Test business logic in isolation. Mock AWS SDK calls.
+  $ npm test  # runs in milliseconds, no AWS needed
+
+  Layer 2 — Integration Tests (20% of tests):
+  Test Lambda handler with real AWS services (or local emulation).
+  $ sam local invoke -e event.json  # local Lambda + local DynamoDB
+  Or: deploy to a test account and run against real services.
+
+  Layer 3 — End-to-End Tests (10% of tests):
+  Deploy full stack to a test environment, send real HTTP requests,
+  verify the complete flow works including async processing.
+  $ sam deploy --stack-name test-stack && npm run e2e
+
+  Contract testing: when Function A writes to DynamoDB and Function B
+  reads from it, test that A's output matches B's expected input
+  schema (using shared TypeScript types or JSON Schema).
+
+  Task: Design the serverless testing strategy. Write: the testing
+  pyramid for serverless, unit testing Lambda (mocking AWS SDK),
+  integration testing (SAM local, LocalStack, real AWS), end-to-end
+  testing for event-driven flows, contract testing between services,
+  and CI/CD test automation.
+
+assertions:
+  - type: llm_judge
+    criteria: "Testing pyramid is adapted for serverless — unit tests: test pure business logic functions (no Lambda handler), mock AWS SDK calls (aws-sdk-client-mock for v3), test input validation, error handling. Integration tests: test Lambda handler with event payloads, use SAM local or deploy to test account. E2E tests: deploy full stack, trigger real events, verify end-to-end flow including async processing (poll for results). Ratio: 70% unit, 20% integration, 10% E2E. Key difference from traditional: more integration tests needed because serverless glue code interacts heavily with AWS services"
+    weight: 0.35
+    description: "Testing pyramid"
+  - type: llm_judge
+    criteria: "Mocking and integration testing are covered — unit test mocking: aws-sdk-client-mock (TypeScript/JavaScript), moto (Python), use dependency injection for testability. Integration: SAM local invoke for Lambda, DynamoDB Local for database, LocalStack for full AWS emulation. Real AWS testing: deploy to dedicated test account with ephemeral stacks (create stack → test → delete). Event testing: generate sample events (sam local generate-event), test with real SQS/EventBridge events. Contract testing: share TypeScript types between producer and consumer, validate schemas in CI"
+    weight: 0.35
+    description: "Mocking and integration"
+  - type: llm_judge
+    criteria: "CI/CD automation is practical — CI pipeline stages: (1) unit tests (fast, every commit), (2) sam build + deploy to test account, (3) integration tests against deployed stack, (4) e2e tests, (5) deploy to staging, (6) smoke tests, (7) deploy to production with canary. Testing async flows: after triggering event, poll DynamoDB/S3 for expected result with timeout. Contract testing in CI: validate shared schemas haven't changed incompatibly. Cost: unit tests are free, integration tests cost a few cents per run. Clean up: delete test stacks after tests to avoid cost. Flaky test mitigation: retry async assertions, use eventually-consistent assertions with polling"
+    weight: 0.30
+    description: "CI/CD automation"

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

@@ -0,0 +1,63 @@
+meta:
+  id: board-serverless-strategy
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "Board-level serverless strategy — present Lambda technology investment to the board with business outcomes, competitive advantage, and risk analysis"
+  tags: [AWS, Lambda, board, strategy, business-outcomes, executive, master]
+
+state: {}
+
+trigger: |
+  The board of directors wants to understand the company's serverless
+  investment. You (VP Engineering) present at the quarterly board
+  meeting. Board members include: a former Fortune 100 CEO, a
+  venture capitalist, an industry domain expert, and the company
+  founder.
+
+  Business outcomes since serverless adoption (18 months):
+
+  Engineering velocity:
+  - Deployment frequency: 2/week → 15/day (7.5x increase)
+  - Lead time for changes: 3 weeks → 2 days (10x faster)
+  - Mean time to recovery: 4 hours → 25 minutes (10x faster)
+  - Change failure rate: 15% → 3%
+
+  Financial impact:
+  - Infrastructure cost: $300K/year → $180K/year (40% reduction)
+  - Operations team: 8 people → 3 (5 redeployed to product dev)
+  - Time to launch new product features: 8 weeks → 2 weeks
+  - Estimated revenue from faster feature delivery: +$2M/year
+
+  Competitive advantage:
+  - Launched a real-time pricing feature in 2 weeks that competitors
+    took 3 months to match
+  - Auto-scaling during Black Friday handled 10x normal traffic
+    with zero manual intervention (competitors had outages)
+  - Developer satisfaction survey: 8.2/10 (was 5.5/10)
+
+  Board questions expected:
+  1. "What's the risk of being dependent on AWS?"
+  2. "What if AWS raises Lambda prices significantly?"
+  3. "How does this compare to what our competitors are doing?"
+  4. "What's the next big investment needed?"
+
+  Task: Prepare the board presentation. Write: the executive
+  narrative (business outcomes, not technology), DORA metrics
+  translation for the board, risk analysis (vendor lock-in,
+  pricing), competitive positioning, and the investment roadmap
+  for the next 2 years.
+
+assertions:
+  - type: llm_judge
+    criteria: "Executive narrative is non-technical — frame serverless as 'on-demand computing that automatically scales and only charges for actual usage.' Focus on business outcomes: faster feature delivery → revenue growth, lower infrastructure costs → margin improvement, automatic scaling → reliability during peak events, smaller ops team → more engineers building product. Avoid: Lambda, API Gateway, DynamoDB, CloudWatch. Instead: 'automated infrastructure,' 'usage-based pricing,' 'self-healing systems.' Use analogies: 'like electricity — pay for what you use, don't maintain a generator'"
+    weight: 0.35
+    description: "Executive narrative"
+  - type: llm_judge
+    criteria: "Risk analysis and competitive positioning are balanced — vendor lock-in: mitigate with clean architecture (business logic is portable, only infrastructure integration code is AWS-specific, ~15% of codebase). AWS pricing risk: historical trend is price reductions, Compute Savings Plans provide price stability. Multi-cloud: not recommended (complexity outweighs benefit) but maintain the ability to migrate if needed. Competitive: serverless is mainstream (60% of AWS customers use Lambda). Competitors on older infrastructure are slower to market. First-mover advantage in serverless competency is a hiring advantage for top talent"
+    weight: 0.35
+    description: "Risk and competitive"
+  - type: llm_judge
+    criteria: "Investment roadmap is forward-looking — next 2 years: (1) AI/ML integration: Lambda for inference endpoints, SageMaker for model training. (2) Edge computing: Lambda@Edge for latency-sensitive features. (3) Real-time processing: Kinesis + Lambda for streaming analytics. (4) Global expansion: multi-region active-active for international markets. Investment ask: maintain current platform team (3 engineers, $540K/year), add $100K/year for tooling, $50K for training. Expected return: additional $3M revenue from faster feature delivery, $50K infrastructure savings from continued optimization. Present as competitive moat, not just cost savings"
+    weight: 0.30
+    description: "Investment roadmap"

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

@@ -0,0 +1,57 @@
+meta:
+  id: consulting-serverless-adoption
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "Consulting engagement — design a serverless adoption strategy for an enterprise transitioning from traditional infrastructure to event-driven Lambda architecture"
+  tags: [AWS, Lambda, consulting, adoption, enterprise, strategy, master]
+
+state: {}
+
+trigger: |
+  A Fortune 500 insurance company wants to modernize their claims
+  processing system. Currently running on on-premise WebSphere
+  application servers with Oracle databases. They've chosen AWS
+  and want to evaluate serverless.
+
+  Current state:
+  - 2,000 claims processed daily (peak: 10,000 during natural disasters)
+  - Average claim processing: 15 steps over 5-7 business days
+  - 200 business rules for claim validation
+  - 50+ integrations with external systems (hospitals, repair shops)
+  - Regulated: state insurance regulations, NAIC guidelines
+  - Team: 80 Java developers, 20 infrastructure ops, 0 cloud experience
+
+  Stakeholder concerns:
+  - CTO: "Can Lambda handle our volume and complexity?"
+  - VP Claims: "We can't have ANY downtime during claims season."
+  - CISO: "Our data can never leave these 3 regions."
+  - CFO: "What's the business case? WebSphere works fine."
+  - Dev team lead: "We're Java developers. How do we learn serverless?"
+
+  Key questions to address:
+  1. Is serverless appropriate for complex, long-running workflows?
+  2. How do regulated industries use Lambda safely?
+  3. What's the migration path from WebSphere + Oracle?
+  4. How do we upskill 80 Java developers?
+  5. What's the ROI vs maintaining current infrastructure?
+
+  Task: Design the consulting engagement deliverable. Write: the
+  serverless readiness assessment, architecture recommendation
+  (what goes to Lambda vs Fargate vs EC2), migration roadmap,
+  regulatory compliance approach, team transformation plan, ROI
+  model, and risk analysis.
+
+assertions:
+  - type: llm_judge
+    criteria: "Readiness assessment is thorough — evaluate each component: claims intake (Lambda — event-driven, good fit), claims processing workflow (Step Functions — multi-step, long-running), business rules engine (Lambda — stateless logic), document processing (Lambda with S3 triggers), external integrations (Lambda with SQS for buffering), reporting/analytics (Lambda + Athena or Fargate for heavy queries), database (Aurora Serverless or DynamoDB depending on access patterns). Not everything should be Lambda: batch reporting → Fargate, real-time dashboards → EC2/ECS"
+    weight: 0.35
+    description: "Readiness assessment"
+  - type: llm_judge
+    criteria: "Migration and compliance are covered — migration: strangler fig pattern, 18-24 month timeline. Phase 1 (6 months): new features as serverless, integrate with existing WebSphere. Phase 2 (6 months): migrate high-value workflows. Phase 3 (6-12 months): migrate remaining, decommission WebSphere. Database: Oracle to Aurora PostgreSQL (compatible, managed), or DynamoDB for appropriate workloads. Compliance: data residency via region selection, encryption (KMS), audit logging (CloudTrail), access control (IAM + Cognito). SOC2/HIPAA: Lambda is compliant, but your implementation must be configured correctly"
+    weight: 0.35
+    description: "Migration and compliance"
+  - type: llm_judge
+    criteria: "Team transformation and ROI are practical — Java developers: Lambda supports Java (SnapStart for cold starts), Quarkus/Micronaut for Lambda-optimized frameworks. Training: 3-month program (AWS fundamentals → Lambda → event-driven design → operations). Pilot team of 10 developers leads, then train-the-trainer. ROI: infrastructure savings (40-60%), operational savings (reduce 20 ops staff to 5 platform engineers), developer productivity (faster deployments). Total 3-year ROI: $3-5M net savings. Risk: timeline slippage (mitigate with phased approach), skill gaps (mitigate with training + hiring 3-5 cloud architects), vendor lock-in (mitigate with clean architecture patterns)"
+    weight: 0.30
+    description: "Team and ROI"

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

@@ -0,0 +1,62 @@
+meta:
+  id: industry-serverless-patterns
+  level: 5
+  course: aws-lambda-debugging
+  type: output
+  description: "Analyze industry serverless patterns — evaluate serverless adoption across fintech, healthcare, e-commerce, and IoT with maturity models and benchmarks"
+  tags: [AWS, Lambda, industry, patterns, maturity, benchmarks, master]
+
+state: {}
+
+trigger: |
+  You're writing a whitepaper: "Serverless in Production: Patterns
+  Across Industries." Research from 200+ serverless deployments reveals:
+
+  Industry-specific patterns:
+
+  Fintech:
+  - Lambda for transaction processing (payment events, fraud detection)
+  - Step Functions for compliance workflows (KYC, AML checks)
+  - Challenge: strict latency requirements (p99 < 100ms for payment APIs)
+  - Solution: provisioned concurrency for payment endpoints
+  - Regulatory: audit trail via CloudTrail, data encryption mandatory
+
+  Healthcare:
+  - Lambda for HL7/FHIR message processing
+  - S3 → Lambda for medical image analysis (with Bedrock/SageMaker)
+  - Challenge: HIPAA compliance (BAA, encryption, access control)
+  - Solution: VPC Lambda with private endpoints, no PII in logs
+  - Data residency: region-locked deployments
+
+  E-commerce:
+  - Lambda for product catalog APIs, recommendation engines
+  - EventBridge for order events across microservices
+  - Challenge: 10-100x traffic spikes during sales (Black Friday)
+  - Solution: pre-scaled provisioned concurrency, DynamoDB on-demand
+  - Cost: Lambda is cheaper than EC2 for spiky traffic patterns
+
+  IoT:
+  - Lambda for device event processing (millions of events/day)
+  - Kinesis → Lambda for real-time telemetry
+  - Challenge: high volume at low cost per event
+  - Solution: batch processing (Kinesis batch window), ARM architecture
+  - Edge: Greengrass Lambda for on-device processing
+
+  Task: Analyze industry serverless patterns. Write: industry-specific
+  use cases and constraints, maturity model for serverless adoption,
+  common pitfalls by industry, performance benchmarks, and strategic
+  guidance for each vertical.
+
+assertions:
+  - type: llm_judge
+    criteria: "Industry patterns are specific — fintech: Lambda ideal for event-driven payment processing, Step Functions for multi-step compliance. Key requirement: sub-100ms latency for synchronous APIs, complete audit trail. Healthcare: HIPAA compliance drives architecture (encryption, access logging, data residency). Lambda for processing, not for storing PHI. E-commerce: spiky traffic patterns make Lambda cost-effective (scales to zero between events). IoT: massive volume at low cost — optimize for efficiency (batch, ARM, minimal memory). Each industry has unique regulatory and performance constraints that shape the Lambda architecture"
+    weight: 0.35
+    description: "Industry patterns"
+  - type: llm_judge
+    criteria: "Maturity model is actionable — Stage 1 (Experiment): single Lambda function, manual deployment, basic logging. Stage 2 (Foundation): IaC, CI/CD, structured logging, event-driven design. Stage 3 (Scale): multi-function architectures, Step Functions, cross-account, observability platform. Stage 4 (Optimize): cost optimization, security hardening, multi-region, automated remediation. Stage 5 (Transform): serverless-first organization, platform team, self-service, industry-leading practices. Most organizations are at Stage 2-3. Advancing requires investment in people and process, not just technology"
+    weight: 0.35
+    description: "Maturity model"
+  - type: llm_judge
+    criteria: "Benchmarks and guidance are data-driven — performance benchmarks: median cold start across industries (Node.js: 200ms, Python: 300ms, Java: 3s, Java+SnapStart: 200ms). Cost benchmarks: $0.001-0.01 per transaction is typical for well-optimized Lambda. Availability: 99.95% with single-region, 99.99% with multi-region. Common pitfalls by industry: fintech (ignoring cold starts for payment APIs), healthcare (PII in CloudWatch Logs), e-commerce (not pre-scaling for known events), IoT (not batching events). Strategic guidance: start with event-driven use cases, expand to APIs, consider containers for steady-state compute"
+    weight: 0.30
+    description: "Benchmarks and guidance"