Build your own cert tracker, start to finish

Reading about GitOps, a mesh, an admission policy and a telemetry pipeline is not the same as watching your own cluster do all four at once. This hub is where that gap closes. You'll build kubestronaut-tracker — a small internal API that tracks your own progress through the sixteen-exam ladder — from a bare git repo holding nothing but application code, through five connected parts, to a service any platform team would recognize: delivered by GitOps, rolled out progressively, wrapped in a mesh, gated by policy, watched end to end, and listed in a developer portal. Each part states exactly what "done" looks like before you start it. If you only have an afternoon, the fast path below still gets you real reps across all five.

The world you're building

☺ Like you're 10: Before any building starts, here's the map: one cluster, one small app, two drawers to keep things tidy in, and one repo that grows a new room every part.

The hub you're reading and all five parts build inside one continuous project, so nothing you set up in Part 1 goes stale by Part 5. Here is the whole world, once, so you never have to re-derive it:

• The cluster is created with kind create cluster --name kubestronaut-dev and stays up for the whole capstone (minikube is a fine substitute; translate the commands yourself).
• The workload is kubestronaut-tracker — a small HTTP API with GET /health, GET /certs, POST /certs/:id/complete, and GET /progress, backed by a single-replica Postgres instance you stand up alongside it. It is a real, backend-persisted version of the same idea this course's own lesson checklists use — except those save your progress in localStorage in your browser, and this one is a service you build, deploy, and operate yourself. Its image is registry.internal/kubestronaut-tracker:TAG, pushed to a throwaway local registry: docker run -d -p 5000:5000 --restart=always --name registry registry:2, with registry.internal pointed at 127.0.0.1 in your hosts file.
• Namespaces split cleanly in two: tracker hosts the application itself, and platform hosts every add-on — Argo CD, the Argo Rollouts controller, istiod, Kyverno, kube-prometheus-stack, the OpenTelemetry Collector, and a local Backstage instance. Every part keeps this split consistent.
• The repo is a single git repo, kubestronaut-tracker, that starts bare — app code, a Dockerfile, one passing test, nothing else — and grows exactly one new top-level path per part.

kubestronaut-dev (kind cluster)
├── namespace: platform          # Argo CD, Argo Rollouts controller, istiod, Kyverno, kube-prometheus-stack, OTel Collector, Backstage…
├── namespace: tracker            # the kubestronaut-tracker Deployment/Rollout, Service, Postgres, ServiceMonitor…
└── (git) kubestronaut-tracker/
    ├── app/, tests/, Dockerfile        # the bare repo you start with
    ├── deploy/argocd/                  # Part 1 — GitOps foundation (Argo CD Application)
    ├── deploy/rollout/                 # Part 2 — progressive delivery (Argo Rollouts canary)
    ├── mesh/, policy/                  # Part 3 — mesh & policy (Istio, Kyverno)
    ├── observability/                  # Part 4 — observability (Prometheus, Grafana, OTel)
    └── catalog-info.yaml, portal/      # Part 5 — the portal (Backstage entity + TechDocs)

One manifest ties the whole loop together from the very first part — everything from here on is Argo CD noticing that this repo changed and reconciling your cluster to match it:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kubestronaut-tracker
  namespace: platform
spec:
  project: default
  source:
    repoURL: https://github.com/you/kubestronaut-tracker.git
    targetRevision: main
    path: deploy/argocd
  destination:
    server: https://kubernetes.default.svc
    namespace: tracker
  syncPolicy:
    automated:
      prune: true      # remove anything deleted from git
      selfHeal: true    # revert anything changed out-of-band
    syncOptions:
      - CreateNamespace=true

The five parts

☺ Like you're 10: Five chapters of the same story. Each one hands the next chapter a repo and a cluster that are a little more finished than the ones before.

Work them in order — each part hands the next one a piece it depends on, and each pairs with real hands-on reps toward specific project certifications this course covers, at the tool that certification actually tests.

Deep-dive the concept behind any part via its linked lesson before or after you build — the lesson explains why, the part makes you prove it works: GitOps Philosophy, Service Mesh Architecture, Policy-as-Code Philosophy, The OpenTelemetry Data Model, The Prometheus Model, and The Backstage Portal Model.

The fast path — for an afternoon

☺ Like you're 10: No time for five deep parts? Here's the one-page summary of the whole story, still worth doing.

The five parts are the deep version of this track — real manifests, real breakage, real triage. If you only have an afternoon, or you want one condensed pass before you sit any of these exams, work this shorter seven-item version instead. It touches every part at a lighter depth, using the exact same kubestronaut-tracker/kubestronaut-dev world as the parts above, so nothing you build here is wasted if you come back and go deep later.

What you'll have built

☺ Like you're 10: By the end, your laptop holds a small working version of the whole mission-control room this course keeps describing — the reconciler, the launch pad, the shield, the gauges, and the directory.

Finish the five parts (or the fast path) and you'll have hands-on reps across seven of the nine project certifications this course covers — CGOA, CAPA, ICA, KCA, OTCA, PCA, and CBA — each one earned from a real cluster doing the real thing the exam asks about, not from a definition you memorized. Domain names and weights above come from each project's published curriculum at the time this page was written; always verify current weights, format, and duration on that certification's own page — starting with The Project Certifications — before you register for anything. Two certs this build deliberately never touches: CCA (Cilium's eBPF data plane, a different networking layer from the Istio mesh built here) and LFCS (the Linux Foundation's performance-based exam on the operating system underneath the cluster, not the workloads running on it). Both are honestly out of scope for an application-level capstone — see their own pages for how to build reps toward them instead.

⚖ Mostly multiple-choice, but still worth building — Seven of the nine certs this capstone earns you reps toward are closed-book, knowledge-based exams: no lab, no terminal, no cluster to fix under a clock. So why build any of this? Because their scenario questions are written by people who assume you've done exactly what these five parts walk you through — a question about what selfHeal: true actually does reads very differently once you've watched Part 1 revert your own manual edit. Closed-book doesn't mean untested; it means the test happens at your own terminal, before you ever see the multiple-choice version of it.