1. Scoping the App
Before writing a single manifest, define exactly what you're deploying and why — the same discipline every earlier week's exercise has quietly required, made explicit here at full project scale.
- What's the app? — Reuse something from an earlier course (a React frontend, a Node/Express or Python API, a database) or build something small and simple; the deployment architecture is the point, not the app's feature set.
- How many independently-deployable services does it genuinely need? — A frontend, a backend API, and a database is a realistic, achievable minimum that exercises every concept from Weeks 7–17 without becoming unmanageable.
- What's genuinely in scope for this capstone? — A small, fully-working, properly-deployed system beats an ambitious one left half-configured. Depth of implementation matters more than breadth of features here.
Sketch the architecture before writing any YAML — which service talks to which, what's public vs. internal-only, and where persistent storage is needed. This is the same "diagram before config" discipline the Cybersecurity Basics course's own capstone uses for a threat model, applied here to deployment topology instead.
2. Architecture Plan
Map every piece of your app to the specific Kubernetes concept that handles it — this plan is what Section 3 then implements, in order:
- Each service's workload type — Deployment for the frontend and API (Week 8), a Deployment or StatefulSet for the database depending on whether you need multiple replicas (Week 11, Week 15).
- Networking — ClusterIP Services between internal components, one Ingress as the single public entry point routing to the frontend and API by path or host (Week 9, Week 12).
- Configuration — Non-sensitive settings in ConfigMaps, credentials and connection strings in Secrets, referenced by name so nothing is hardcoded into an image (Week 10).
- Storage — A PVC (or StatefulSet volumeClaimTemplates) for whatever needs to survive a Pod restart — almost certainly your database (Week 11, Week 15).
- Scaling — Resource requests/limits on every container, and an HPA on at least your API service (Week 14).
- Observability — Liveness/readiness probes on every service, and at least one Grafana panel reflecting real behavior (Week 16).
Write this mapping down as an actual document, not just a mental checklist — it becomes the backbone of Section 5's write-up.
3. Full Implementation, in a Sensible Order
Build in an order that lets each layer be verified before the next depends on it:
# 1. Multi-stage, non-root, minimal images for every service (Week 6)
# 2. Deployments + ClusterIP Services for each component, verified working
# with kubectl port-forward before touching Ingress (Week 8, 9)
# 3. ConfigMaps and Secrets, externalizing every hardcoded value (Week 10)
# 4. PVC/StatefulSet storage for your database, verified to survive a
# Pod deletion before building anything else on top of it (Week 11, 15)
# 5. Ingress routing to your public-facing services, with TLS if you have
# a real domain available, otherwise documented as a known gap (Week 12)
# 6. Package the whole thing as ONE Helm chart with values-dev.yaml and
# values-prod.yaml (Week 13)
# 7. Resource requests/limits and an HPA on your API service, load-tested
# to confirm it actually scales (Week 14)
# 8. Probes on every service, and a Prometheus/Grafana dashboard showing
# real metrics for the running system (Week 16)
# 9. CI pipeline building and pushing images, and ArgoCD deploying from
# Git with selfHeal enabled (Week 17)
Verify each step with the same "prove it, don't assume it" standard used throughout this course — confirm a Service actually has Endpoints before layering Ingress on top of it, confirm your PVC's data survives a Pod deletion before trusting it with anything else, confirm the HPA actually scales under real generated load.
4. A Resilience & Observability Pass
Apply Weeks 14, 16 and 17 in full against the finished deployment, not as an afterthought:
- Resource correctness (Week 14) — every container has requests and limits set from real measured usage, not guesses; the HPA's target percentage is verified against an actual load test.
- Self-healing, proven (Week 8, 9, 15) — delete a Pod from every service and confirm it's replaced automatically, with Endpoints and data intact afterward.
- Observability (Week 16) — a real Grafana dashboard covering at minimum CPU/memory and restart count for every service, and one alert rule that you've deliberately triggered and confirmed fires.
- GitOps drift test (Week 17) — perform both drift tests from Week 17's exercise against your actual capstone deployment: a Git-driven change that deploys automatically, and a manual cluster change that ArgoCD reverts.
5. Deployment & Portfolio Write-Up
A deployment nobody else can see the reasoning behind is far less valuable as a portfolio piece than one with a clear, documented architecture story. Deploy the real application through your finished pipeline, then write it up properly.
- The architecture — the Section 2 diagram and mapping, presented cleanly, showing every service, its workload type, and how they connect.
- What you built, and why — mapped explicitly back to specific weeks/concepts, the same mapping discipline Section 2 started with.
- What you tested, and found — real results from your resilience and observability pass, honestly described, including anything you chose to leave as a documented gap rather than fully solve.
- Evidence — screenshots of a Grafana dashboard with real data, a successful Pod self-heal, an HPA scaling event, an ArgoCD sync — the same evidence discipline used throughout this course's exercises.
- What you'd do with more time — an honest gap list (a real domain and TLS, a managed database instead of self-hosted, multi-region) is more credible than an unqualified "production-ready" claim.
6. The Capstone Project
Containerize, orchestrate, expose, scale and automate a real multi-service app
Pick a real, small application — one from an earlier course, or something new and simple — and take its full deployment through Sections 1–5.
Requirements:
- Scope the app and sketch its architecture with every service, its workload type, and its connections marked (Sections 1–2) before writing any manifests.
- Containerize every service with a multi-stage, non-root, minimal image (Week 6), and push each to a registry with a real, commit-traceable tag.
- Implement the full stack in the order from Section 3: Deployments/Services for every component, ConfigMaps/Secrets for all config, persistent storage for your database, an Ingress as the single public entry point, the whole thing packaged as one Helm chart with dev and prod values files, resource limits and an HPA on your API, probes everywhere, and a Grafana dashboard with real data.
- Wire a CI pipeline that builds and pushes images on every commit, and an ArgoCD Application that deploys from Git — run the full drift-test pair from Section 4 against it and confirm both directions work.
- Produce the portfolio write-up from Section 5, with real evidence attached for every major claim.
Not the number of microservices or the size of the cluster — a small, genuinely working, properly observed and self-healing deployment with real evidence and an honest gap list reads as far more credible to a real employer or collaborator than an ambitious setup nobody's actually confirmed works end to end. This is the same lesson every earlier week's exercise has been building toward: prove it, don't just claim it.
7. Final Checklist
Before calling the capstone — and the course — done, confirm each of these honestly:
✓
Does every service run through a Deployment or StatefulSet — no bare Pods anywhere in the final deployment?
Does every service run through a Deployment or StatefulSet — no bare Pods anywhere in the final deployment?
Week 8's core lesson, checked one more time: every workload should be self-healing by construction, not by luck. Confirm this by deleting a Pod from each service and watching a replacement appear automatically.
✓
Does your database's data genuinely survive a Pod deletion, verified by actually deleting it and checking?
Does your database's data genuinely survive a Pod deletion, verified by actually deleting it and checking?
Week 11's exercise made this point directly: "should survive" and "verified to survive" are different claims. Confirm you actually deleted the Pod and reconnected to see your data, not just that you configured a PVC and assumed it works.
✓
Does the HPA actually scale under real load, confirmed by watching replica count change, not just by having applied the manifest?
Does the HPA actually scale under real load, confirmed by watching replica count change, not just by having applied the manifest?
Week 14's own exercise required watching real load drive a real scaling event. An HPA object existing in the cluster proves nothing on its own — confirm you've watched kubectl get hpa --watch show replicas actually change under generated load.
✓
Does ArgoCD's selfHeal actually revert a manual change, confirmed by deliberately making one and watching it get corrected?
Does ArgoCD's selfHeal actually revert a manual change, confirmed by deliberately making one and watching it get corrected?
Week 17's drift-test pair, run for real against your capstone: a Git commit that deploys automatically, and a manual kubectl change that ArgoCD reverts on its own. Both directions need to be observed, not assumed from the config alone.
✓
Is the write-up honest about gaps and things you'd still improve, rather than claiming the deployment is "production-ready"?
Is the write-up honest about gaps and things you'd still improve, rather than claiming the deployment is "production-ready"?
No self-hosted, single-cluster learning project is genuinely production-ready without further work — a real domain and TLS, a managed database, multi-region resilience are all real next steps most capstones will legitimately lack. A specific, honest gap list reads as far more credible than an unqualified claim.
✓
Is there a real result someone else can actually see — a repo, a dashboard screenshot, a recorded walkthrough?
Is there a real result someone else can actually see — a repo, a dashboard screenshot, a recorded walkthrough?
A finished capstone that only exists on your local cluster, with no write-up, screenshots or public repo, is much harder to use as portfolio evidence than one someone else can actually inspect. Publish the manifests/chart to a public repo (secrets excluded, per Week 10) and attach real evidence to the write-up before considering this done.