dojo.md 0.1.0 → 0.2.0

package/courses/github-actions-cicd/scenarios/level-2/dependency-caching.yaml

@@ -0,0 +1,58 @@
+meta:
+  id: dependency-caching
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Optimize dependency caching — configure actions/cache and built-in caching to dramatically reduce CI build times"
+  tags: [github, actions, caching, dependencies, optimization, intermediate]
+
+state: {}
+
+trigger: |
+  Your team's CI workflow takes 12 minutes per run, and 8 of those
+  minutes are spent installing dependencies. With 80 CI runs per day,
+  that's over 10 hours wasted on dependency installation daily. You
+  need to implement an effective caching strategy.
+
+  Project details:
+  - Monorepo with 3 packages (frontend, backend, shared)
+  - Frontend: npm (package-lock.json)
+  - Backend: pip (requirements.txt + requirements-dev.txt)
+  - Shared: Go modules (go.sum)
+  - Docker builds: multi-stage Dockerfile for backend
+
+  Current (no caching) timing:
+  - npm ci: 3 minutes
+  - pip install: 2 minutes
+  - go mod download: 1.5 minutes
+  - Docker build: 1.5 minutes (downloads base images each time)
+
+  Caching scenarios to solve:
+  1. Basic npm caching using actions/setup-node's built-in cache
+  2. Advanced npm caching using actions/cache with fallback keys
+  3. pip caching with multiple requirements files as cache key
+  4. Go module caching
+  5. Docker layer caching (using actions/cache or buildx cache)
+  6. Cross-branch cache sharing (feature branch uses main's cache)
+
+  Task: Implement caching for all 5 dependency types. For each, write:
+  the cache configuration (key, restore-keys, path), the explanation
+  of the cache key strategy (why hash this file, what happens on
+  cache miss), the expected time savings, and common caching pitfalls
+  to avoid. Include a comparison of built-in caching (setup-node,
+  setup-python) vs explicit actions/cache, and explain when each is
+  preferred.
+
+assertions:
+  - type: llm_judge
+    criteria: "Cache keys are correctly designed — npm uses hashFiles('**/package-lock.json'), pip uses hashFiles of requirements files, Go uses hashFiles('**/go.sum'), restore-keys provide fallback for partial matches, and the cross-branch sharing strategy is explained"
+    weight: 0.35
+    description: "Correctly designed cache keys"
+  - type: llm_judge
+    criteria: "All 5 dependency types are cached — npm, pip, Go modules, and Docker layers all have correct cache configurations with appropriate paths (node_modules or ~/.npm, ~/.cache/pip, ~/go/pkg/mod) and the Docker caching uses buildx with cache-from/cache-to or actions/cache"
+    weight: 0.35
+    description: "Complete caching for all types"
+  - type: llm_judge
+    criteria: "Pitfalls and trade-offs are addressed — explains cache size limits (10GB per repo), cache eviction policy (LRU, 7-day expiry), the danger of caching node_modules vs ~/.npm, and when built-in caching (setup-node cache: npm) is simpler than explicit actions/cache"
+    weight: 0.30
+    description: "Pitfalls and trade-offs addressed"

package/courses/github-actions-cicd/scenarios/level-2/deployment-workflows.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: deployment-workflows
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Build deployment workflows — create staging and production deployment pipelines with approval gates and rollback"
+  tags: [github, actions, deployment, staging, production, rollback, intermediate]
+
+state: {}
+
+trigger: |
+  You're building deployment workflows for a web application that needs
+  to deploy to staging automatically and to production with manual
+  approval. The application runs on AWS (ECS for the API, S3 + CloudFront
+  for the frontend).
+
+  Deployment requirements:
+  1. Staging deployment:
+     - Automatically deploy when PR is merged to main
+     - Deploy both frontend (S3) and backend (ECS)
+     - Run smoke tests after deployment
+     - Notify #staging Slack channel with deployment URL
+
+  2. Production deployment:
+     - Requires manual approval from a team lead
+     - Uses GitHub Environments with protection rules
+     - Deploy frontend first, then backend (ordered)
+     - Run health checks between each deployment step
+     - If health check fails, automatically rollback
+     - Notify #production Slack channel
+
+  3. Rollback workflow:
+     - Manual trigger (workflow_dispatch) with version input
+     - Rolls back to the specified previous version
+     - Can also be triggered automatically from deployment failure
+
+  4. Environment configuration:
+     - Staging: auto-deploy, no approval, 5-minute timeout
+     - Production: manual approval (2 required reviewers), deployment
+       window (weekdays 9AM-4PM ET only)
+
+  Task: Write all 3 workflow files (deploy-staging.yml, deploy-
+  production.yml, rollback.yml). Include: the GitHub Environment
+  configuration (protection rules, secrets per environment), the
+  deployment steps with health checks, the rollback mechanism, and
+  the Slack notification integration. Explain the deployment strategy
+  (blue-green, rolling, or canary) and why you chose it.
+
+assertions:
+  - type: llm_judge
+    criteria: "GitHub Environments are correctly used — staging environment has no protection rules (auto-deploy), production has required reviewers and deployment branch restriction (main only), and environment-specific secrets are referenced correctly"
+    weight: 0.35
+    description: "Correct GitHub Environment usage"
+  - type: llm_judge
+    criteria: "Deployment and rollback are properly orchestrated — staging deploys automatically on merge, production requires approval, health checks run between steps, failures trigger automatic rollback, and the manual rollback workflow accepts a version input"
+    weight: 0.35
+    description: "Proper deployment orchestration"
+  - type: llm_judge
+    criteria: "Deployment strategy is explained and implemented — the chosen strategy (blue-green, rolling, or canary) is justified for the architecture (ECS + S3), the implementation matches the strategy, and the rollback mechanism is consistent with the deployment approach"
+    weight: 0.30
+    description: "Explained deployment strategy"

package/courses/github-actions-cicd/scenarios/level-2/github-packages-publishing.yaml

@@ -0,0 +1,59 @@
+meta:
+  id: github-packages-publishing
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Publish to GitHub Packages — automate npm, Docker, and container registry publishing with versioning and access control"
+  tags: [github, actions, packages, npm, Docker, registry, intermediate]
+
+state: {}
+
+trigger: |
+  Your organization has internal libraries and Docker images that need
+  to be published to GitHub Packages. You need to set up automated
+  publishing workflows for 3 different package types.
+
+  Package 1 — npm library (@myorg/shared-utils):
+  - Publish to GitHub Packages npm registry (not npmjs.com)
+  - Version from package.json
+  - Publish on GitHub Release creation
+  - Include provenance attestation
+  - Scoped to the organization (@myorg/*)
+
+  Package 2 — Docker image (myorg/api-server):
+  - Build and push to GitHub Container Registry (ghcr.io)
+  - Tag with: git SHA, branch name, semver from git tag, and "latest"
+  - Multi-architecture build (amd64 + arm64)
+  - Push on merge to main (tagged as latest + SHA)
+  - Push on release (tagged with version)
+
+  Package 3 — Python package (myorg-sdk):
+  - Build wheel and sdist
+  - Publish to GitHub Packages (not PyPI)
+  - Include in the same workflow as tests
+
+  Access control requirements:
+  - Internal packages: readable by all org members
+  - Docker images: public (for open-source project)
+  - npm packages: scoped to org, installable with GITHUB_TOKEN
+
+  Task: Write the publishing workflows for all 3 package types.
+  Include: the workflow YAML, the package.json / Dockerfile / setup.py
+  configuration needed for GitHub Packages, the authentication setup
+  (GITHUB_TOKEN permissions, .npmrc configuration), and the versioning
+  strategy for each package type. Explain the difference between GitHub
+  Packages and external registries.
+
+assertions:
+  - type: llm_judge
+    criteria: "npm publishing is correctly configured — uses .npmrc with GitHub Packages registry URL, GITHUB_TOKEN authentication, publishConfig in package.json, provenance attestation with --provenance flag, and the workflow triggers on release published"
+    weight: 0.35
+    description: "Correct npm publishing"
+  - type: llm_judge
+    criteria: "Docker publishing uses GHCR correctly — authenticates with ghcr.io, uses docker/metadata-action for smart tagging (SHA, branch, semver), multi-arch build with docker/build-push-action and QEMU, and the image is properly tagged for both main and release triggers"
+    weight: 0.35
+    description: "Correct Docker GHCR publishing"
+  - type: llm_judge
+    criteria: "Access control and versioning are properly explained — differentiates package visibility settings, explains GITHUB_TOKEN vs PAT for cross-repo access, and the versioning strategy is consistent across package types (semver from git tags or package.json)"
+    weight: 0.30
+    description: "Proper access control and versioning"

package/courses/github-actions-cicd/scenarios/level-2/intermediate-cicd-shift.yaml

@@ -0,0 +1,68 @@
+meta:
+  id: intermediate-cicd-shift
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Intermediate CI/CD shift — handle complex workflow issues, optimization requests, and deployment incidents simultaneously"
+  tags: [github, actions, shift-simulation, troubleshooting, optimization, intermediate]
+
+state: {}
+
+trigger: |
+  You're the CI/CD on-call engineer handling multiple requests during
+  a busy shift. Handle all 4 situations.
+
+  Situation 1 — Deployment rollback needed:
+  Production deployment just completed but monitoring shows 500 errors
+  spiking from 0.1% to 5%. The deployment was triggered by a merge
+  to main 10 minutes ago. You need to:
+  - Identify which commit caused the issue
+  - Trigger a rollback to the previous version
+  - The rollback workflow exists but has never been used — you need
+    to verify it works and execute it
+  - Prevent further auto-deployments until the issue is resolved
+
+  Situation 2 — Matrix build timeout:
+  The cross-platform test matrix has been running for 2 hours (normal
+  is 20 minutes). Investigation shows: macOS runner is stuck on "Set
+  up job" with no logs. This is blocking a critical security patch PR.
+  You need to:
+  - Unblock the security patch
+  - Fix the matrix build for future runs
+  - Decide if you should rerun the entire matrix or just the failed job
+
+  Situation 3 — Secret exposure alert:
+  GitHub sent a secret scanning alert: an AWS access key was found in
+  a workflow file committed 2 hours ago. The key was in a hardcoded
+  env value (not using secrets). You need to:
+  - Assess the exposure (was the key used in any workflow runs?)
+  - Remediate immediately (rotate key, remove from code)
+  - Prevent recurrence (how to block secret commits)
+
+  Situation 4 — Cache corruption:
+  Multiple teams report that their CI workflows are failing with
+  "Module not found" errors despite no code changes. Investigation
+  shows the shared cache (node_modules) was corrupted by a workflow
+  that ran during a failed npm publish. You need to:
+  - Clear the corrupted cache for affected repos
+  - Fix the failing workflows immediately
+  - Prevent cache corruption from happening again
+
+  Task: Handle all 4 situations. For each, write: the immediate action
+  (what to do in the next 5 minutes), the resolution steps, the root
+  cause analysis, and the prevention measures. Prioritize and explain
+  your priority order.
+
+assertions:
+  - type: llm_judge
+    criteria: "Priority order is correct — secret exposure (Situation 3) and production errors (Situation 1) are highest priority, matrix timeout (Situation 2) is medium (blocks security patch), and cache corruption (Situation 4) is handled but less urgent. The security patch PR gets unblocked quickly"
+    weight: 0.35
+    description: "Correct priority order"
+  - type: llm_judge
+    criteria: "Resolutions are technically sound — rollback uses the existing workflow with correct version targeting, secret remediation includes key rotation AND code removal AND history rewriting if needed, cache clearing uses correct GitHub API or CLI, and matrix fix addresses the macOS runner issue"
+    weight: 0.35
+    description: "Technically sound resolutions"
+  - type: llm_judge
+    criteria: "Prevention measures are systemic — secret scanning with push protection, pre-commit hooks for secrets, cache key design that prevents corruption (immutable keys), macOS runner fallback strategy, and deployment safeguards (canary, automatic rollback on error rate)"
+    weight: 0.30
+    description: "Systemic prevention measures"

package/courses/github-actions-cicd/scenarios/level-2/matrix-builds.yaml

@@ -0,0 +1,59 @@
+meta:
+  id: matrix-builds
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Configure matrix builds — test across multiple OS, language versions, and configurations using strategy.matrix"
+  tags: [github, actions, matrix, cross-platform, multi-version, intermediate]
+
+state: {}
+
+trigger: |
+  You maintain an open-source Node.js library that must work across
+  multiple environments. The library is used by projects running
+  different Node.js versions, operating systems, and package managers.
+
+  Test matrix requirements:
+  - Node.js versions: 18, 20, 22
+  - Operating systems: ubuntu-latest, windows-latest, macos-latest
+  - Package managers: npm, yarn, pnpm
+  - Full matrix = 3 x 3 x 3 = 27 combinations
+
+  Constraints:
+  - The full matrix takes too long (45 minutes) and costs too much
+  - Node 18 on Windows with pnpm has a known incompatibility — exclude
+    this combination
+  - Node 22 is experimental — failures shouldn't block the PR
+  - macOS runners cost 10x more than Linux runners — minimize usage
+  - You want to add a specific combination not in the matrix: Node 21
+    (nightly) on ubuntu-latest with npm
+
+  Additional requirements:
+  - If any matrix job fails, you want to see all results (don't cancel
+    other jobs immediately)
+  - The matrix should generate a human-readable job name like
+    "Test (node-20, ubuntu-latest, npm)"
+  - After all matrix jobs complete, a summary job should report which
+    combinations passed/failed
+
+  Task: Write the complete matrix workflow. Include: the matrix
+  configuration with include, exclude, and fail-fast settings, the
+  strategy for reducing the 27-combination matrix to a practical subset
+  (explain your reasoning for which to cut), the Node 22 experimental
+  configuration using continue-on-error, and the summary job that
+  collects all matrix results. Explain the cost implications of your
+  matrix choices.
+
+assertions:
+  - type: llm_judge
+    criteria: "Matrix syntax is correct — uses strategy.matrix with proper include/exclude syntax, fail-fast: false, continue-on-error for Node 22, and the exclude for Node 18 + Windows + pnpm is correctly specified"
+    weight: 0.35
+    description: "Correct matrix syntax"
+  - type: llm_judge
+    criteria: "Matrix reduction is well-reasoned — reduces the 27-combination matrix to a practical subset (maybe 12-15), justifies which combinations to keep (e.g., full Linux matrix, reduced macOS to save cost), and the cost analysis shows the savings"
+    weight: 0.35
+    description: "Well-reasoned matrix reduction"
+  - type: llm_judge
+    criteria: "Summary job correctly aggregates results — uses needs with the matrix job, accesses matrix job outcomes, and produces a clear pass/fail report for all combinations. The workflow would work correctly in a real repository"
+    weight: 0.30
+    description: "Correct summary aggregation"

package/courses/github-actions-cicd/scenarios/level-2/reusable-workflows.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: reusable-workflows
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Build reusable workflows — create DRY CI/CD with reusable workflows, composite actions, and workflow templates"
+  tags: [github, actions, reusable-workflows, composite-actions, DRY, intermediate]
+
+state: {}
+
+trigger: |
+  Your organization has 15 Node.js repositories that all have nearly
+  identical CI/CD workflows. When you need to update the Node version
+  or add a security scan, you have to modify 15 files across 15 repos.
+  Last month, someone forgot to update 3 repos and they broke.
+
+  Current duplication:
+  - All 15 repos: checkout → setup-node → install → lint → test → build
+  - 8 repos: + deploy to staging on merge to main
+  - 5 repos: + deploy to production on release
+  - All repos: same Slack notification on failure
+
+  You need to create reusable components:
+
+  Component 1 — Reusable workflow (workflow_call):
+  Create a reusable CI workflow that accepts inputs:
+  - node-version (default: 20)
+  - run-e2e (boolean, default: false)
+  - deploy-target (string: none/staging/production)
+  And passes secrets:
+  - AWS credentials (for deployment)
+  - Slack webhook URL (for notifications)
+
+  Component 2 — Composite action:
+  Create a composite action "setup-and-test" that bundles:
+  - Checkout, setup-node, cache, install, lint, test
+  Into a single reusable action that can be used in any workflow
+
+  Component 3 — Workflow template (organization level):
+  Create a starter workflow template that new repos can adopt from
+  the "Actions" tab, pre-configured with your org's standards
+
+  Task: Build all 3 components. For each, write: the complete YAML
+  files, the calling workflow that uses them, and the comparison (when
+  to use reusable workflows vs composite actions vs templates). Include
+  the migration plan for moving the 15 repos from duplicated workflows
+  to the reusable approach.
+
+assertions:
+  - type: llm_judge
+    criteria: "Reusable workflow is correctly structured — uses workflow_call trigger with typed inputs and secrets, the calling workflow uses 'uses: org/repo/.github/workflows/file.yml@main' syntax, and secrets are passed correctly (secrets: inherit or explicit)"
+    weight: 0.35
+    description: "Correct reusable workflow structure"
+  - type: llm_judge
+    criteria: "Composite action is properly defined — has action.yml with inputs/outputs, uses 'composite' runs type, steps use correct shell specification, and the calling workflow uses it with 'uses: org/repo/path@version' syntax"
+    weight: 0.35
+    description: "Proper composite action definition"
+  - type: llm_judge
+    criteria: "Comparison is clear and practical — explains when to choose reusable workflows (full job reuse, secret passing), composite actions (step-level reuse, can run in existing jobs), and templates (one-time setup for new repos), with a migration plan that doesn't break existing CI"
+    weight: 0.30
+    description: "Clear comparison and migration plan"

package/courses/github-actions-cicd/scenarios/level-2/workflow-cost-optimization.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: workflow-cost-optimization
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Optimize workflow costs — reduce GitHub Actions spend through caching, concurrency, path filters, and runner selection"
+  tags: [github, actions, cost, optimization, billing, runners, intermediate]
+
+state: {}
+
+trigger: |
+  Your engineering manager just received the GitHub Actions bill:
+  $4,200/month for a 25-person team. They want you to cut it by 50%
+  without sacrificing CI quality. Here's the current usage breakdown:
+
+  Billing data (last month):
+  - Total minutes used: 42,000
+  - Linux runners: 28,000 min ($280 at $0.008/min)
+  - macOS runners: 8,000 min ($640 at $0.08/min)
+  - Windows runners: 6,000 min ($96 at $0.016/min)
+  - Storage (artifacts + packages): $180
+  - Overage beyond free tier: $3,000
+
+  Workflow analysis:
+  | Workflow          | Runs/month | Avg duration | Total min | Cost  |
+  |-------------------|-----------|-------------|-----------|-------|
+  | ci.yml            | 1,200     | 15 min      | 18,000    | $1,440|
+  | deploy.yml        | 60        | 8 min       | 480       | $38   |
+  | nightly-tests.yml | 30        | 45 min      | 1,350     | $108  |
+  | e2e-all-os.yml    | 400       | 30 min      | 12,000    | $1,560|
+  | lint-on-save.yml  | 2,000     | 3 min       | 6,000     | $480  |
+  | security-scan.yml | 200       | 12 min      | 2,400     | $192  |
+  | stale-cleanup.yml | 30        | 5 min       | 150       | $12   |
+
+  Key observations:
+  - ci.yml runs on every push (even draft PRs, even docs-only changes)
+  - e2e-all-os.yml runs full matrix on all 3 OSes for every PR
+  - lint-on-save.yml triggers on every push including commit amends
+  - nightly-tests.yml runs a full test suite even when nothing changed
+  - Artifacts are retained for 90 days (default)
+
+  Task: Create the cost optimization plan. For each workflow, write:
+  the specific optimization (with YAML changes), the expected savings,
+  and any quality trade-offs. Include: the optimized billing projection,
+  the comparison of GitHub-hosted vs self-hosted runner economics for
+  this team's usage, and a monitoring dashboard design for ongoing
+  cost tracking. Target: reduce from $4,200 to under $2,100/month.
+
+assertions:
+  - type: llm_judge
+    criteria: "Optimizations are specific and impactful — ci.yml gets path filters and draft PR skip, e2e-all-os runs full matrix only on main (reduced matrix on PRs), lint-on-save gets concurrency cancel-in-progress, artifact retention is reduced, and each optimization has a dollar-value estimate"
+    weight: 0.35
+    description: "Specific impactful optimizations"
+  - type: llm_judge
+    criteria: "Cost reduction achieves the target — the total projected savings reach or exceed 50% ($2,100 target), each optimization's savings are calculated from the billing data, and the math is consistent and reasonable"
+    weight: 0.35
+    description: "Target-achieving cost reduction"
+  - type: llm_judge
+    criteria: "Self-hosted runner analysis is included — compares the monthly cost of GitHub-hosted vs self-hosted for this usage level, considers the maintenance overhead of self-hosted, and makes a clear recommendation with break-even analysis"
+    weight: 0.30
+    description: "Self-hosted runner analysis"

package/courses/github-actions-cicd/scenarios/level-3/advanced-cicd-shift.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: advanced-cicd-shift
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Advanced CI/CD shift — handle security incidents, compliance failures, and infrastructure emergencies in GitHub Actions"
+  tags: [github, actions, shift-simulation, security, compliance, incident, advanced]
+
+state: {}
+
+trigger: |
+  You're the CI/CD platform engineer handling an intense shift with
+  4 critical issues arriving within the same hour.
+
+  Issue 1 — Supply chain attack detected (Critical):
+  GitHub's secret scanning alerted that a popular action you use
+  (actions/setup-python@v4) had its v4 tag overwritten 30 minutes ago
+  by a compromised maintainer account. The malicious version exfiltrates
+  environment variables (including secrets) to an external server. Your
+  organization has 25 repos using this action. 8 workflow runs have
+  already executed since the compromise.
+  Immediate: Determine which repos are affected, assess exposure, and
+  block further execution.
+
+  Issue 2 — SOC 2 audit finding (High):
+  The SOC 2 auditor found that your required workflow (security scan)
+  can be bypassed. A developer discovered they can modify the workflow
+  file in their PR to skip the security scan, and since the modified
+  workflow is what runs, the bypass succeeds. This is a critical control
+  failure.
+
+  Issue 3 — Runner fleet failure (High):
+  Your self-hosted runner fleet (Kubernetes with ARC) is experiencing
+  cascading failures. The runner controller pod is in CrashLoopBackOff,
+  new jobs are queueing but not starting, and 15 deployments are
+  blocked. The last change was a Kubernetes cluster upgrade 2 hours ago.
+
+  Issue 4 — Cost spike (Medium):
+  GitHub Actions billing shows a 400% cost spike in the last 24 hours.
+  Investigation reveals a workflow with an infinite loop — a workflow
+  triggers on push, creates a commit, which triggers another push,
+  creating another commit. It's been running for 18 hours creating
+  5,000+ commits.
+
+  Task: Handle all 4 issues. For each, write: the immediate containment
+  action (what to do in the next 5 minutes), the investigation and
+  remediation steps, the root cause analysis, and the permanent fix.
+  Include: the incident communication (what to tell the security team,
+  auditors, and engineering org), and the post-incident improvements
+  to prevent all 4 types of issues.
+
+assertions:
+  - type: llm_judge
+    criteria: "Supply chain attack response is comprehensive — identifies all 25 affected repos, assesses which 8 runs were compromised, immediately pins to SHA or blocks the action, rotates all exposed secrets, and reports the compromised action to GitHub"
+    weight: 0.35
+    description: "Comprehensive supply chain response"
+  - type: llm_judge
+    criteria: "Audit finding is remediated correctly — explains that required workflows from the calling repo can be modified, the fix uses organization-level required workflows (which run the org's version, not the PR's), and the auditor is given a corrective action plan"
+    weight: 0.35
+    description: "Correct audit finding remediation"
+  - type: llm_judge
+    criteria: "Infinite loop and runner issues are resolved — the infinite loop is stopped by disabling the workflow or adding recursion prevention ([skip ci] or checking github.actor), the runner fleet recovery addresses the K8s upgrade issue, and permanent fixes prevent both recurrence"
+    weight: 0.30
+    description: "Loop and runner resolution"

package/courses/github-actions-cicd/scenarios/level-3/compliance-automation.yaml

@@ -0,0 +1,68 @@
+meta:
+  id: compliance-automation
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Automate compliance in CI/CD — embed SOC 2, PCI DSS, and HIPAA controls into GitHub Actions workflows"
+  tags: [github, actions, compliance, SOC2, PCI-DSS, HIPAA, audit, advanced]
+
+state: {}
+
+trigger: |
+  Your fintech company processes healthcare payments (both PCI DSS and
+  HIPAA apply) and is pursuing SOC 2 Type II certification. The
+  auditors want to see that compliance controls are automated in CI/CD,
+  not just documented.
+
+  Required automated controls:
+
+  1. Change management (SOC 2 CC8.1):
+     - Every production change has an approved PR (no direct pushes)
+     - PR approval is from someone other than the author
+     - All CI checks pass before merge
+     - Deployment creates an auditable record (who, when, what, why)
+
+  2. Security testing (PCI DSS 6.5):
+     - SAST scan on every PR (CodeQL or Semgrep)
+     - Dependency vulnerability scan (Dependabot or Snyk)
+     - Secret scanning with push protection
+     - Container image scanning before deployment
+
+  3. Data protection (HIPAA):
+     - No PHI in logs (log sanitization check)
+     - Encryption verification (TLS, at-rest encryption config checks)
+     - Access audit log generation for every deployment
+
+  4. Evidence collection:
+     - All workflow runs produce compliance artifacts
+     - Artifacts are retained for 7 years (regulatory requirement)
+     - Evidence must be tamper-proof (signed, immutable)
+     - Monthly compliance report generation (automated)
+
+  Current gaps:
+  - Some repos don't have branch protection
+  - Security scans exist but are not required (can be skipped)
+  - No centralized compliance artifact storage
+  - Deployment audit logs are in plain text files, easy to modify
+
+  Task: Build the compliance automation pipeline. Write: the required
+  workflows (as organization-level required workflows), the branch
+  protection rulesets (org-wide enforcement), the security scan
+  configuration (CodeQL + Dependabot + secret scanning), the evidence
+  collection system (artifact storage, retention, signing), and the
+  monthly compliance report workflow. Include: the auditor-facing
+  documentation explaining how the automation satisfies each control.
+
+assertions:
+  - type: llm_judge
+    criteria: "Controls are automated correctly — organization-level required workflows enforce security scans on all repos, branch protection rulesets prevent self-merge and require CI, and deployment audit records are generated automatically with tamper-proof signatures"
+    weight: 0.35
+    description: "Correctly automated controls"
+  - type: llm_judge
+    criteria: "Evidence collection meets regulatory requirements — compliance artifacts are stored with 7-year retention (not default 90 days), artifacts are signed for tamper-proofing, and the monthly report aggregates compliance data across all repos"
+    weight: 0.35
+    description: "Regulatory-meeting evidence collection"
+  - type: llm_judge
+    criteria: "Auditor documentation maps controls to workflows — each SOC 2/PCI/HIPAA control has a corresponding workflow or configuration with evidence of automation, and the documentation would satisfy an auditor (not just an engineer)"
+    weight: 0.30
+    description: "Auditor-satisfying documentation"

package/courses/github-actions-cicd/scenarios/level-3/docker-action-development.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: docker-action-development
+  level: 3
+  course: github-actions-cicd
+  type: output
+  description: "Build custom Docker actions — create isolated, language-agnostic actions using Docker containers with proper testing and publishing"
+  tags: [github, actions, Docker, custom-actions, containers, advanced]
+
+state: {}
+
+trigger: |
+  Your security team needs 3 custom Docker-based actions for their
+  compliance pipeline. Docker actions are required (not JavaScript)
+  because they need specific CLI tools, language runtimes, and
+  isolation guarantees.
+
+  Action 1 — "compliance-scanner":
+  Purpose: Run a compliance scan against CIS benchmarks for Docker
+  images and Kubernetes manifests. Must include specific tools
+  (trivy, kubesec, conftest) that aren't available as standalone
+  actions with the versions you need.
+  Inputs: scan-type (docker/k8s), target (image name or manifest path),
+  severity-threshold (critical/high/medium), policy-dir (OPA policies)
+  Outputs: findings-count, report-path, pass/fail status
+  Requirements: Multi-stage Dockerfile, report in SARIF format,
+  integration with GitHub Security tab
+
+  Action 2 — "license-auditor":
+  Purpose: Audit all dependencies for license compliance. Must support
+  npm, pip, Go, and Java (Maven) in a single action. Uses a Python
+  script with specific libraries.
+  Inputs: package-manager, allowed-licenses (JSON array), fail-on-deny
+  Outputs: audit-report-path, denied-licenses-count
+  Requirements: Should generate a license bill of materials (BOM)
+
+  Action 3 — "secret-detector":
+  Purpose: Scan PR diffs for accidentally committed secrets using
+  custom regex patterns and entropy analysis. Runs in isolated
+  container for security (action itself handles sensitive data).
+  Inputs: custom-patterns (file path to regex list), entropy-threshold
+  Outputs: secrets-found-count, findings-path
+  Requirements: Must NOT log the actual secret values, must annotate
+  the PR with findings location
+
+  Task: Build all 3 Docker actions. For each, write: the Dockerfile
+  (multi-stage for size optimization), the entrypoint script, the
+  action.yml metadata, the test workflow (how to test a Docker action),
+  and the CI/CD for the action itself (building, testing, and publishing
+  the action). Include: the Docker caching strategy for action builds,
+  the versioning approach, and the security considerations for Docker
+  actions that handle sensitive data.
+
+assertions:
+  - type: llm_judge
+    criteria: "Dockerfiles are well-designed — uses multi-stage builds to minimize image size, includes all required tools, entrypoint scripts handle inputs from environment variables correctly, and the action.yml files have complete metadata with all inputs/outputs"
+    weight: 0.35
+    description: "Well-designed Docker actions"
+  - type: llm_judge
+    criteria: "Testing strategy is practical — includes unit tests for the scripts, integration tests using a test workflow (workflow_dispatch or push to test branch), and explains how to test Docker actions locally before publishing"
+    weight: 0.35
+    description: "Practical testing strategy"
+  - type: llm_judge
+    criteria: "Security considerations are addressed — the secret-detector doesn't log secrets, Docker actions run in isolation, the compliance-scanner SARIF output integrates with GitHub Security tab, and the versioning approach uses SHA-pinned tags"
+    weight: 0.30
+    description: "Security considerations addressed"