In this capstone project you will apply every skill from all six modules to the CricketPulse platform. You will harden the CI/CD pipeline (Module 1–2), enforce cluster policies (Module 3), simulate and document a production incident (Module 4), run a Game Day with two fault injections (Module 5), and produce a complete Production Readiness Review (Module 6). By the end, CricketPulse will have a defensible, documented security and reliability posture across all six PRR domains.
Analogy🏏Cricket
🏏 Think of it like cricket: This is the final of the tournament. Everything from the training camps — fitness, technique, strategy, teamwork — must come together in one match. The capstone is your team's final match: six innings (six modules), each requiring the skills practiced in training, all contributing to a single match result — a production-ready, hardened CricketPulse platform.
Phase 1 — Pipeline Security (Modules 1 & 2)
Harden the CricketPulse CI/CD pipeline using the Module 2 exercise as the baseline. Verify that all five security gates are active and that the pipeline uses OIDC for all cloud authentication.
Analogy🏏Cricket
🏏 Think of it like cricket: The pre-series equipment certification — every bat weighed, every pad inspected, every helmet certified. No compromises before the first ball.
bash
# Phase 1 verification checklist
# 1. No static credentials in any workflow file
grep -r "AWS_ACCESS_KEY_ID\|AWS_SECRET\|password" .github/workflows/ 2>/dev/null && echo "FAIL" || echo "PASS: no static credentials"
# 2. All GitHub Actions pinned to commit SHA
grep -r "uses:.*@" .github/workflows/ | grep -v "@[a-f0-9]\{40\}" && echo "WARN: unpinned actions found" || echo "PASS: all actions SHA-pinned"
# 3. Pipeline runs all five gates in parallel: dep-scan, sast, image-scan, conftest, sbom
# Verify in GitHub Actions run log: all three scan jobs show "In progress" simultaneously
# 4. Trivy blocks on HIGH/CRITICAL
trivy image cricketpulse:latest --exit-code 1 --severity HIGH,CRITICAL
echo "Trivy exit code: $?" # Expected: 0 (no HIGH/CRITICAL findings)
# 5. SBOM artifact exists for last pipeline run
gh run download --name sbom-$(git rev-parse HEAD) --dir /tmp/sbom-check
ls /tmp/sbom-check/sbom.spdx.json && echo "PASS: SBOM artifact found"
# 6. Required reviewer gate configured on production environment
gh api repos/{owner}/{repo}/environments/production | python3 -c "
import json,sys
env = json.load(sys.stdin)
reviewers = env.get('protection_rules',[])
print('PASS: required reviewers configured' if reviewers else 'FAIL: no reviewer gate')
"Phase 2 — Cluster Policy Enforcement (Module 3)
Verify all three Kyverno ClusterPolicies from the Module 3 exercise are in Enforce mode and that the CricketPulse manifests pass all policies. Run conftest against all Kubernetes manifests and confirm zero policy violations.
Analogy🏏Cricket
🏏 Think of it like cricket: This phase is the umpires switching from warnings to enforcing the laws for real. Just as, once the match begins, an umpire no longer merely notes a front-foot no-ball but actively calls and penalises it, you confirm all three Kyverno ClusterPolicies are in Enforce mode — not audit — so any violating manifest is genuinely rejected, not just logged. Just as every player's kit is inspected against the laws before they take the field and must pass without exception, you run conftest against all Kubernetes manifests and confirm zero policy violations. Just as a clean scorecard from the match officials means the game was played entirely within the laws, a clean PolicyReport for the CricketPulse namespace proves the workloads comply with the registry, non-root, and resource-limit rules. The payoff: verifying enforcement is truly on — rather than assuming it — is what stops a non-compliant, insecure workload from ever reaching the field of play in production.
bash
# Phase 2 verification
# 1. All Kyverno policies in Enforce mode
for policy in restrict-image-registries require-nonroot require-resource-limits; do
mode=$(kubectl get clusterpolicy $policy -o jsonpath='{.spec.validationFailureAction}' 2>/dev/null)
echo "$policy: ${mode:-NOT_FOUND}"
done
# Expected: all three show Enforce
# 2. CricketPulse namespace PolicyReport is clean
kubectl get policyreport -n cricketpulse -o json | python3 -c "
import json,sys
r = json.load(sys.stdin)
fails = [res for item in r.get('items',[]) for res in item.get('results',[]) if res['result']=='fail']
print(f'Policy violations: {len(fails)}')
if fails:
for f in fails: print(f' {f["policy"]}: {f["message"]}')
"
# Expected: Policy violations: 0
# 3. conftest passes on all manifests
conftest test k8s/ --policy policies/k8s/ --output table
# Expected: No failures
# 4. Kubernetes audit logging enabled
kubectl get apiserver -o yaml 2>/dev/null || cat /etc/kubernetes/audit-policy.yaml 2>/dev/null || echo "Verify audit policy exists on API server config"Phase 3 — Incident Simulation (Module 4)
Run the incident drill from Module 4's exercise. Play the role of Incident Commander for the rate-limit misconfiguration scenario. Complete the full lifecycle: detect, triage, contain, resolve, and produce a postmortem document. The postmortem must have at least three action items with owners and due dates.
Analogy🏏Cricket
🏏 Think of it like cricket: This phase is the full match simulation where you captain the side through a crisis from the first ball to the final report. Just as a captain handling a mid-innings collapse must read the situation, steady the response, make the change, and see the innings through, you play Incident Commander for the rate-limit misconfiguration and run the complete lifecycle — detect, triage, contain, resolve. Just as the drill is only meaningful under real match conditions — timed, pressured, decisions logged as you make them — you time the response against targets and document each step. And just as the simulation isn't finished until the coaching staff produce a review that traces the collapse to a systemic gap and assigns concrete training plans to named coaches with deadlines, the phase isn't complete until you produce a postmortem with a Five Whys root cause and at least three action items, each with an owner and a due date. The payoff: rehearsing the whole crisis end-to-end builds the reflexes and the paperwork discipline a real production incident will demand.
python
# Phase 3 verification
# 1. Complete the drill (inject the fault, respond as IC)
# Inject: kubectl edit configmap nginx-configmap
# Change rate_limit_requests_per_second from 50 to 5
# Time the full response cycle:
# - T0: fault injected
# - T1: first detection (user report or alert)
# - T2: incident channel opened
# - T3: root cause identified
# - T4: fix applied (rate limit restored)
# - T5: verification complete
# Record times:
DRILL_METRICS = {
"time_to_detect": "T1 - T0", # target: <10 minutes
"time_to_contain": "T4 - T0", # target: <30 minutes
"status_page_updated": "T2 + 5 minutes", # target: within 5 min of IC engaged
}
# 2. Postmortem document produced
# File: postmortems/capstone-drill-{date}.md
# Must contain: impact, timeline, root cause (Five Whys), action items, lessons learned
# 3. Action items quality check
# Each action item must have:
# - Specific action (not "improve monitoring")
# - Owner (named individual)
# - Due date (specific date, not "soon")
# - Definition of done
echo "Phase 3 complete when: drill timed, postmortem filed, action items tracked in issue tracker"Phase 4 — Game Day (Module 5)
Run the Game Day from the Module 5 exercise. Both experiments (pod failure and payment latency) must be executed with documented hypotheses, observations, and findings. Produce the Game Day report with at least two action items.
Analogy🏏Cricket
🏏 Think of it like cricket: This phase is the structured practice match where you deliberately inject two tough situations and record exactly how the side copes. Just as a coach sets up two specific scenarios — an opener retired hurt to test how fast the next batter settles, and a surprise slow bowler to test the batting adjustment — you run two experiments, a score-API pod failure and a payment-service latency injection. Just as each scenario is run with a clear hypothesis, an analyst logging what actually happens, and a verdict on whether the technique held, both experiments must be executed with documented hypotheses, observations, and findings. Just as the practice match is worthless without the written report naming the fixes to work on, you produce a Game Day report with at least two action items drawn from what deviated. The payoff: deliberately breaking the system under observation reveals its true resilience boundaries before a real match-day crowd ever tests them.
bash
# Phase 4: Run both experiments and produce Game Day report
# Experiment 1: Score API pod failure
# Pre-conditions: Chaos Mesh installed, CricketPulse running in staging
kubectl apply -f experiment-01-pod-failure.yaml
# Record:
# - Time to pod replacement: ______ seconds
# - Peak error rate during gap: ______ %
# - Hypothesis result: PASSED / DEVIATED
# Experiment 2: Payment service latency injection
kubectl apply -f experiment-02-payment-latency.yaml
# Record:
# - Circuit breaker trip time: ______ seconds (or did NOT trip)
# - Peak checkout error rate: ______ %
# - Hypothesis result: PASSED / DEVIATED
# Game Day report must document:
# - Steady state baseline for each experiment
# - Actual observations vs hypothesis
# - At least one action item per deviated hypothesis
# Verification:
echo "Phase 4 complete when:"
echo " - experiment-01-pod-failure.yaml exists and was applied"
echo " - experiment-02-payment-latency.yaml exists and was applied"
echo " - gamedayreports/capstone-gameday.md exists with all sections"
echo " - all chaos experiments show 'Finished' status (not still running)"
kubectl get podchaos,networkchaos -n cricketpulse
# Expected: all experiments in Finished statePhase 5 — Production Readiness Review (Module 6)
Complete the full six-domain PRR checklist for CricketPulse. Every domain must be checked and the document signed off. Any blocking items that cannot be resolved must be documented with an exception rationale, owner, and completion date.
Analogy🏏Cricket
🏏 Think of it like cricket: This final phase is the selection committee's sign-off before the team is declared ready for the tournament. Just as the committee will not clear a squad until every dimension of readiness is confirmed — fitness, equipment, tactics, depth, and ground certification — you complete the full six-domain PRR checklist and ensure every domain is checked, not just the convenient ones. Just as a senior selector formally puts their name to the decision, creating clear accountability, the PRR document is signed off rather than left as an informal tick-box. And just as a player carrying a minor niggle can only be included with a documented management plan — a named physio, a rationale, and a recovery date — any blocking item that cannot be resolved must be recorded as an exception with an owner, a justification, and a completion date. The payoff: CricketPulse enters production with a defensible, fully-documented readiness posture across all six domains, not a hopeful launch with hidden gaps.
bash
# Phase 5: Complete PRR document
# File: docs/prr/cricketpulse-capstone.md
# Auto-verify what can be automated
echo "=== PRR Automated Verification ==="
# Security domain
echo "--- Security ---"
trivy image cricketpulse:latest --exit-code 0 --severity HIGH,CRITICAL --format json | python3 -c "import json,sys; r=json.load(sys.stdin); vulns=sum(len(x.get('Vulnerabilities',[])) for x in r.get('Results',[])); print(f'Trivy: {vulns} HIGH/CRITICAL (target: 0)')"
pip-audit --requirement requirements.txt --format json | python3 -c "import json,sys; r=json.load(sys.stdin); vulns=sum(len(d.get('vulns',[])) for d in r.get('dependencies',[])); print(f'pip-audit: {vulns} vulnerabilities (target: 0)')"
# Observability domain
echo "--- Observability ---"
curl -s "http://prometheus:9090/api/v1/rules" | python3 -c "
import json,sys
data = json.load(sys.stdin)
sli_rules = [r for g in data['data']['groups'] for r in g['rules'] if 'sli:' in r.get('name','')]
slo_alerts = [r for g in data['data']['groups'] for r in g['rules'] if 'SLOBurn' in r.get('name','')]
print(f'SLI rules: {len(sli_rules)} (target: >=1)')
print(f'SLO burn alerts: {len(slo_alerts)} (target: >=2)')
"
# Reliability domain
echo "--- Reliability ---"
kubectl get hpa -n cricketpulse
# Expected: score-api HPA with min/max configured
# Capacity domain
echo "--- Capacity ---"
echo "Load test results: check k6-results/ directory for last run"
ls k6-results/ 2>/dev/null || echo "WARN: no load test results found"
# Operations domain
echo "--- Operations ---"
echo "Runbooks present:"
ls runbooks/ 2>/dev/null | wc -l
# Compliance domain
echo "--- Compliance ---"
ls sbom*.spdx.json 2>/dev/null && echo "SBOM: found" || echo "SBOM: NOT FOUND"Final Rubric
The capstone is evaluated across four areas, each worth 25 points, for a maximum of 100 points. Each area requires a specific artifact as evidence.
Analogy🏏Cricket
🏏 Think of it like cricket: The tournament result isn't a vague impression — it's a scorecard with defined ways to earn runs, each backed by evidence on the sheet. Just as a match is judged across distinct disciplines — batting, bowling, fielding, and captaincy — that each contribute to the final tally, the capstone is scored across four areas, each worth 25 points toward a maximum of 100. Just as a bowler's figures aren't taken on trust but recorded ball-by-ball in the scorebook, each rubric area requires a specific artifact as proof — a pipeline run, a policy report, a postmortem, a Game Day report, a signed PRR — so a claim is credited only when the evidence exists. Just as a balanced side must perform in every discipline rather than carrying a weakness, the four areas span pipeline security, cluster policy, incident readiness, and resilience, so you cannot pass on one strength alone. The payoff: a transparent, evidence-backed score that proves the platform is genuinely hardened, not merely declared so.
bash
# Capstone rubric
# Area 1: Pipeline Security (25 points)
# Evidence: GitHub Actions workflow file + last successful pipeline run screenshot
# Requirements:
# - 0 static credentials (5 pts)
# - All actions SHA-pinned (5 pts)
# - Parallel security gates (dep-scan, sast, image-scan) (5 pts)
# - SBOM artifact present in last pipeline run (5 pts)
# - Required reviewer gate on production environment (5 pts)
# Area 2: Cluster Policy & Compliance (25 points)
# Evidence: kubectl output + conftest output + PRR compliance section
# Requirements:
# - 3 ClusterPolicies in Enforce mode (10 pts)
# - 0 PolicyReport violations in cricketpulse namespace (5 pts)
# - conftest passes on all manifests (5 pts)
# - Audit policy covers secret access (5 pts)
# Area 3: Incident & Operations Readiness (25 points)
# Evidence: postmortem document + at least 3 runbook files
# Requirements:
# - Drill completed within time targets (MTTD <10m, MTTC <30m) (10 pts)
# - Postmortem has Five Whys root cause (5 pts)
# - 3+ action items with owners and due dates (5 pts)
# - 3+ runbooks in runbooks/ directory (5 pts)
# Area 4: Resilience & PRR (25 points)
# Evidence: Game Day report + PRR document
# Requirements:
# - Game Day report with both experiments documented (10 pts)
# - At least 2 action items from Game Day deviations (5 pts)
# - PRR document with all 6 domains checked or excepted (5 pts)
# - PRR signed off by reviewer (5 pts)
# Passing score: 70/100
# Outstanding: 90/100Do not start the capstone until all 23 preceding lessons are complete. Each phase builds on skills from its corresponding module — attempting Phase 4 (Game Day) without the Chaos Mesh skills from Lesson 18, or Phase 5 (PRR) without the SLO knowledge from Lesson 22, will produce incomplete artifacts that do not meet the rubric requirements.
The PRR document produced in Phase 5 is a reusable template for all future CricketPulse service launches. Store it in your repository under docs/prr/ and reference it in your development runbooks as the required pre-launch process. The investment in this capstone produces permanent organisational infrastructure, not just a course submission.
- Phase 1 (Security): zero static credentials, SHA-pinned actions, parallel gates, SBOM artifact, reviewer gate.
- Phase 2 (Policy): three ClusterPolicies in Enforce, zero PolicyReport violations, conftest clean.
- Phase 3 (Incident): drill MTTD <10m, MTTC <30m, postmortem with Five Whys and 3+ action items.
- Phase 4 (Game Day): both experiments documented with hypothesis vs actual, action items for any deviations.
- Phase 5 (PRR): all six domains verified, exceptions documented with owner and date, document signed off.