Capstone — submit pipeline YAML, ArgoCD repo and live dashboard — CI/CD, GitOps, DevSecOps & Observability

The capstone submission brings together all three artefacts produced in Lessons 37, 38, and 39 into a single reviewable repository that demonstrates an end-to-end secure, observable GitOps delivery platform on EKS. This is not an exercise with guided steps—it is a project submission evaluated against the five success criteria defined in the project brief. The submitted platform must work holistically: the components must be connected, not just individually functional.

The project evaluates whether you have internalised the course's core discipline: that security, delivery reliability, and observability are not independent concerns to be addressed separately but integrated properties of a single coherent platform. A submission where every component works but the connections between them are broken—the CI pipeline signs an image that Kyverno still rejects, or the AnalysisTemplate queries a metric that does not exist—does not meet the capstone standard.

Analogy🏏Cricket

Think of it like cricket: Imagine the BCCI's team management system for an international tour with matches in three different countries simultaneously. Rather than a coordinator manually managing each match day's logistics, the system reads the official tour schedule document and automatically dispatches the right squad, equipment, and support staff to each venue. When the tour schedule changes—a match is rescheduled, a squad member is replaced—the system detects the change and updates the arrangements automatically. Just as the tour management system uses the official document as the source of truth and orchestrates multiple concurrent deployments to multiple venues, ArgoCD uses the Git repository as the source of truth and orchestrates multiple concurrent Application syncs to multiple clusters. Just as the system provides a dashboard showing which venues are 'ready', 'delayed', or 'degraded', ArgoCD provides a dashboard showing which Applications are Synced, OutOfSync, or Degraded. This reveals why ArgoCD is valued at scale: managing dozens of applications across multiple clusters manually is operationally equivalent to coordinating an international cricket tour by phone.

Submission Checklist

Before submitting, verify every item on the submission checklist. The checklist is not a formality—each item tests a specific integration point between platform components. A Kyverno policy in Audit mode rather than Enforce mode fails the admission control criterion even if the policy YAML is correct. A Cosign verify command that succeeds with unconstrained `--certificate-identity-regexp` does not verify that the signature was produced by your specific pipeline. Work through the checklist item by item against the live cluster.

Analogy🏏Cricket

🏏 Think of it like cricket: The submission checklist is not a formality; it is the match-official's pre-game inspection, where each item probes a real safety point rather than a box to tick for show. Just as an inspector who finds the boundary official is merely noting infractions in a logbook rather than actually stopping play would fail the venue — even though a logbook exists — a Kyverno policy running in Audit mode instead of Enforce fails the admission criterion even if the policy YAML is perfectly written, because it observes violations without blocking them. And just as accepting any player who merely waves some card — without checking it names the right person — is no real accreditation check at all, a `cosign verify` that passes with an unconstrained `--certificate-identity-regexp` proves nothing, because it would accept a signature from anyone. The payoff: each checklist item forces a genuinely enforced control, so passing the list means the platform actually blocks bad actors rather than just quietly recording that they walked in.

bash

# Capstone submission checklist — verify each item before submitting.

# ══ ARTEFACT 1: GitHub Actions Pipeline ══════════════════════════════════
#
# File: .github/workflows/capstone-ci.yml
# Required elements:
# [ ] sast job: Semgrep with custom .semgrep/ rules, SARIF upload
# [ ] sca job: Snyk with --fail-on=upgradeable, SARIF upload
# [ ] build-scan-sign job: needs [sast, sca]
#     [ ] AWS OIDC authentication (no static keys stored as secrets)
#     [ ] Docker build with push: false and load: true before scanning
#     [ ] Trivy scan with exit-code: 1 on HIGH/CRITICAL, SARIF upload
#     [ ] ECR push after scan passes
#     [ ] Cosign sign by digest with --yes flag
#     [ ] Cosign verify immediately after signing
# [ ] update-gitops job: needs [build-scan-sign], only on main branch
#     [ ] Commits image digest to GitOps repo overlays/production/

# ══ ARTEFACT 2: ArgoCD GitOps Repository ════════════════════════════════
#
# Repository: MY_ORG/india-squad-gitops
# Required files:
# [ ] policies/require-image-signature.yaml: Kyverno ClusterPolicy
#     [ ] validationFailureAction: Enforce
#     [ ] attestors: keyless with correct GitHub Actions workflow subject
#     [ ] mutateDigest: true
# [ ] rollout/india-squad-rollout.yaml: Argo Rollouts Rollout resource
#     [ ] canary strategy with canaryService/stableService
#     [ ] two analysis steps referencing india-squad-error-rate
#     [ ] trafficRouting with ALB ingress
# [ ] rollout/analysis-template.yaml: AnalysisTemplate
#     [ ] Prometheus provider querying error rate by pod_template_hash
#     [ ] successCondition <= 0.01, failureCondition > 0.05
# [ ] monitoring/prometheus-rule.yaml: PrometheusRule
#     [ ] recording rule: job:http_error_ratio:rate5m
#     [ ] IndiaSquadHighErrorRate, IndiaSquadHighP99Latency alerts
#     [ ] IndiaSquadSLOBudgetBurning (critical)
#     [ ] IndiaSquadCanaryRolloutDegraded (critical, for: 0m)

# ══ ARTEFACT 3: Live Grafana Dashboard Evidence ══════════════════════════
#
# Screenshot: grafana-golden-signals-dashboard.png
# Required evidence in the screenshot:
# [ ] Dashboard title: 'India Squad API — Golden Signals'
# [ ] Request Rate panel: non-zero values
# [ ] Error Rate panel: a value (even if 0%)
# [ ] P99 Latency panel: a latency value in seconds
# [ ] At least one deployment annotation visible (vertical marker)
# [ ] Time range: at least 30 minutes of data
# [ ] Dashboard URL confirms it is from a live cluster (not a local mock)

Five Success Criteria Verification

The five success criteria from the project brief each require specific evidence. Criterion 1—signed image produced within 10 minutes—is evidenced by the pipeline run timestamp and the `cosign verify` output with the correct identity regexp. Criterion 2—Kyverno admits signed and rejects unsigned—is evidenced by kubectl output showing a successfully deployed signed pod and an admission error for an unsigned pod attempt in squad-prod.

Analogy🏏Cricket

🏏 Think of it like cricket: Verifying the five success criteria is like producing the match evidence a referee demands for each disputed decision — not your word, but the actual footage and timestamp for every claim. Just as 'the over was bowled inside the time limit' is proven by the clock reading, criterion 1 — a signed image within ten minutes — is proven by the pipeline run's timestamp and the `cosign verify` output showing the correct identity regexp, not merely your assertion. And just as 'only accredited players took the field' is proven by showing both the accredited player walking out and the impostor being turned away at the gate, criterion 2 is proven by kubectl output showing the signed pod running and the admission error rejecting the unsigned one. The payoff: attaching concrete, specific evidence to each criterion turns 'I believe it works' into 'here is the proof it works', which is the only thing a reviewer can actually trust.

Criterion 3—canary rollout references real Prometheus metrics—is evidenced by a running or completed AnalysisRun in the squad-prod namespace whose Prometheus query returns numeric values. Criterion 4—PrometheusRule alerts evaluated—is evidenced by all four alert rules appearing in the Prometheus Alerts page with correct expression syntax. Criterion 5—Grafana shows 30 minutes of live data—is evidenced by the dashboard screenshot with the time range visible and the request rate panel showing non-zero values.

bash

# Verification commands for all five success criteria.

# ── Criterion 1: Signed image from CI pipeline ────────────────────────
DIGEST=$(aws ecr describe-images \
  --repository-name india-squad-api --region ap-south-1 \
  --query 'sort_by(imageDetails, &imagePushedAt)[-1].imageDigest' \
  --output text)

cosign verify \
  --certificate-identity-regexp='https://github.com/MY_ORG/india-squad-helm/.github/workflows/capstone-ci.yml' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
  123456789.dkr.ecr.ap-south-1.amazonaws.com/india-squad-api@${DIGEST}
# Save output to: evidence/signed-image-verification.txt

# ── Criterion 2: Kyverno admits signed, rejects unsigned ──────────────
# Attempt to run an unsigned nginx pod in squad-prod:
kubectl run unsigned-capstone-test --image=nginx:latest -n squad-prod --restart=Never 2>&1
# Save the error output to: evidence/kyverno-enforce-rejection.txt
# Expected: 'was blocked due to the following policies: require-india-squad-signature'

# Confirm the signed india-squad-api pod is running:
kubectl get pods -n squad-prod -l app=india-squad-api
# Expected: Running pods with the signed image

# ── Criterion 3: AnalysisRun with real Prometheus metrics ─────────────
kubectl get analysisrun -n squad-prod
kubectl describe analysisrun -n squad-prod | grep -A5 'Measurements'
# Expected: measurements with numeric values (not 'no data')

# ── Criterion 4: All alert rules in Prometheus ─────────────────────────
# Open http://localhost:9090/alerts
# Verify: all four alerts present
# Take screenshot for evidence

# ── Criterion 5: Grafana dashboard with 30+ minutes of data ──────────
# Open http://localhost:3000/dashboards → India Squad API — Golden Signals
# Set time range to 'Last 1 hour'
# Take screenshot for evidence/grafana-golden-signals-dashboard.png

Submission Structure

Organise the submission as a GitHub repository named `india-squad-capstone` with the three artefact directories and an evidence directory containing all screenshots and command output files. The README.md is the most important document in the submission—it is the reviewer's entry point and must make the platform's architecture, the connections between components, and the verification evidence immediately clear. A well-written README demonstrates understanding; a minimal README suggests the platform was assembled without full comprehension of how the components integrate.

Analogy🏏Cricket

🏏 Think of it like cricket: Organising the submission is like preparing the tour dossier a selection committee receives — everything filed in a known structure so a reviewer can navigate it without a guide. Just as a professional dossier separates the training programme, the match playbook, and the fitness records into labelled sections plus an evidence folder of match footage, your capstone repo `india-squad-capstone` holds the three artefact directories plus an evidence directory of screenshots and command output. And just as the dossier's cover summary is the single most important page — the one the committee reads first to decide whether to dig deeper — the README is the reviewer's entry point and must make the platform's architecture, the connections between components, and the verification evidence immediately clear. The payoff: a predictable structure with a strong front page means the reviewer spends their time judging your platform rather than hunting for where you buried the proof.

yaml

# Submission structure — final repository layout for review.

india-squad-capstone/
├── README.md                      # Platform overview and component map
├── ci/
│   └── capstone-ci.yml            # GitHub Actions workflow (Artefact 1)
├── gitops/
│   ├── policies/
│   │   └── require-image-signature.yaml  # Kyverno ClusterPolicy
│   ├── rollout/
│   │   ├── india-squad-rollout.yaml      # Argo Rollouts Rollout
│   │   └── analysis-template.yaml        # AnalysisTemplate
│   └── monitoring/
│       └── prometheus-rule.yaml          # PrometheusRule (Artefact 2)
└── evidence/
    ├── grafana-golden-signals-dashboard.png   # Artefact 3: screenshot
    ├── pipeline-run-success.png               # Screenshot: all 4 CI jobs green
    ├── signed-image-verification.txt          # cosign verify output
    ├── kyverno-enforce-rejection.txt          # kubectl output showing unsigned pod rejected
    └── rollout-degraded-alert.png             # Screenshot: Slack critical alert

# README.md must include:
# 1. A one-paragraph description of the platform architecture
# 2. The AWS account ID and ECR repository ARN (for signature verification)
# 3. The Grafana dashboard URL (accessible to the reviewer)
# 4. The commands used to verify each of the five success criteria
# 5. Any deviations from the reference implementation and their justification

README Requirements

The README must describe the platform architecture in enough detail that a reviewer who has not taken this course can understand what each component does and how they connect. The architecture section should mirror the diagram from Lesson 36's project brief, adapted to the specific implementation choices you made. The verification section must include the exact commands used to verify each success criterion, with example expected outputs that the reviewer can reproduce.

Analogy🏏Cricket

🏏 Think of it like cricket: The README requirements are like the match-plan briefing a visiting analyst must be able to read cold, having never sat in your team meetings, and still understand exactly how your side is set up. Just as a good briefing draws the field placement clearly enough that a newcomer grasps what each fielder does and how they cover for one another, the README must describe the platform architecture so a reviewer who never took the course understands each component and how they connect, mirroring the diagram from the project brief. And just as a rigorous briefing lists the precise drills used to confirm each tactic works — not 'we practised catching' but the exact routine — the verification section must include the exact commands used to prove each success criterion. The payoff: a README written for an outsider means your platform is judged on what it demonstrably does, not on background knowledge the reviewer would have to already share with you.

If you made any deviations from the reference implementation—using Flux CD instead of ArgoCD, Grafana Tempo instead of Jaeger, or implementing SLSA Level 3 provenance in addition to Cosign signing—document these in a 'Design Decisions' section with the rationale. Deviations that improve the platform are valued; deviations that omit required security properties are not. A platform that uses Flux CD but omits Kyverno image signature verification fails the supply chain security criterion regardless of which GitOps tool is used.

Evaluation Criteria

The capstone is evaluated across three dimensions. The first is integration completeness: all five success criteria are met, and the evidence demonstrates the connections between components are live rather than staged. The second is security posture: no security gate is bypassed or weakened—the Kyverno policy is in Enforce mode, OIDC federation is used rather than static credentials, and the Cosign verification uses constrained identity requirements. The third is observability depth: the Grafana dashboard shows all three golden signals, the PrometheusRule alerts include both threshold alerts and the burn rate alert, and the canary degradation alert connects the delivery layer to the alerting layer.

Analogy🏏Cricket

🏏 Think of it like cricket: The capstone is judged on three dimensions, much like a touring side is assessed not on one innings but on several qualities at once. The first is integration completeness — like proving the whole team functions as a unit, all five criteria met with evidence showing the connections are live in a real match, not staged in a posed team photo. The second is security posture — like confirming no player cut a corner: the Kyverno policy is in Enforce mode and genuinely turns violators away, credentials use OIDC federation rather than static keys smuggled in, and the Cosign checks are properly constrained rather than accepting anyone. Just as a selection panel that saw only a staged highlight reel but no live-match proof, or spotted one player quietly breaking the rules, would mark the side down, a reviewer marks down staged evidence or any weakened gate. The payoff: being judged across integration and security together ensures the platform is both connected and genuinely safe, not one achieved at the expense of the other.

Extra credit is awarded for: adding SBOM generation to the CI pipeline, implementing SLSA Level 3 provenance alongside Cosign signing, adding deployment annotations to Grafana from the CI pipeline, or deploying a second application service and demonstrating that the Kyverno policy and monitoring stack extend to cover it without any central configuration changes.

Warning: Do not take screenshots of dashboards with no data and submit them as evidence. An empty Grafana panel—showing 'No Data' for the request rate—does not demonstrate that the observability stack is working; it demonstrates that either the application is not instrumented, the ServiceMonitor is not scraping, or the dashboard query is wrong. Generate real traffic to the application—using the load generation commands from M5 Lab 35—and confirm that all three panels show meaningful values before taking the submission screenshot.

Final Tip: The most common capstone failure mode is forgetting to connect the CI pipeline to the GitOps repository. A pipeline that builds, scans, and signs an image but does not commit the image digest to the GitOps repository means ArgoCD never deploys the new version, the Rollout never fires, and the AnalysisTemplate never queries Prometheus. Verify the GitOps update step works by checking the GitOps repository for a new commit from the CI bot after running the pipeline. This is the integration point that makes the whole platform work end-to-end.