Running a 30-Day EKS Platform Engineering Plan

There is a difference between having used Kubernetes and being able to stand up and operate a platform other engineers build on. This is the plan for closing that gap in a deliberate 30-day block, structured as three sprints with a scored review at the end of each.

The target, stated up front

A production-shaped AWS EKS platform that demonstrates, concretely: cluster architecture understood well enough to explain and debug without searching, infrastructure defined entirely in Terraform, a CI/CD pipeline that is actually reliable, observability with Prometheus and Grafana, secure access with Kubernetes RBAC and IAM roles for service accounts, and reliability expressed as service level objectives rather than guesswork.

Sprint one, days one to ten: cluster live

EKS provisioned through Terraform, and torn down cleanly through Terraform, that round trip being the real test. Nodes joining, workloads scheduling, ingress working. The review question at the end is blunt: can I deploy and debug this without looking anything up, and does a destroy leave nothing behind.

Sprint two, days eleven to twenty: delivery and observability

Helm charts structured properly rather than copy-pasted. Prometheus scraping, Grafana dashboards that show something useful, and alerts wired to the service level objectives, not to raw CPU. The measures are an availability indicator, non-5xx responses over total responses, and a latency indicator at the 95th percentile, with a target of 99.5 percent availability over a rolling 30 days.

Sprint three, days twenty-one to thirty: automation and maturity

The CI/CD pipeline made genuinely repeatable, documentation written to the standard where someone else could operate the platform from it, and the whole thing reviewed as if reading it cold for a platform role.

Why a fixed structure matters

Open-ended "learn Kubernetes better" produces a pile of half-finished clusters. A month with named sprints, a defined deliverable per sprint, and a scored review at each boundary produces something you can point at. The proof is the artefacts: the Terraform, the dashboards, the runbook, not the hours.

“Reliability thinking is the part you cannot fake in an interview. Either there are SLOs driving the alerts, or there are not.”

Related