Product & contracts
Identify recurring developer friction, define a self-service contract, version the interface and measure task success instead of feature count.
Platform Engineering Fundamentals · PLAT-FND · Learning Quality Edition
Turn infrastructure complexity into a supported developer product.
Learn platform engineering as a product discipline: start from developer friction, define stable self-service contracts, compose golden paths from Kubernetes, IaC, GitOps, policy, security and observability, then operate those capabilities with explicit ownership and measurable developer outcomes.
My Learning progress
0% complete
0 of 12 curriculum modules completed · 0/12 currently published modules complete · 0 with lab + knowledge-check evidence.
LevelFundamentals · intermediate foundation
Recommended preparationLinux · Git · containers · Kubernetes · CI/CD · IaC basics
Typical time~11–12 hours · allow 10–14
Labs12 account-free core labs + 12 real-tool practica
Assessment30 questions · ≥10 scenarios · 35 min · pass ≥75%
CertificationOptional · ₹499 incl. GST
Learner outcomes
After this course, you should be able to design and operate a small internal platform capability.
The goal is not to memorize tools. It is to design interfaces, evidence and ownership that make delivery safer and easier.
Golden path & delivery
Design templates, workload profiles, immutable artifact promotion, GitOps reconciliation and rollback evidence without turning tools into the product.
Guardrails & tenancy
Apply policy, workload identity, secrets boundaries, quotas, cost ownership and accountable exceptions with specific developer feedback.
Operate the platform
Define platform SLOs, on-call and incident boundaries, intake/roadmap practices, support signals, deprecations and stakeholder feedback loops.
Before you begin
Prerequisites are recommended, not hidden.
You do not need expert-level mastery, but the course assumes the underlying engineering vocabulary is already familiar.
Recommended knowledge
- Linux command line and basic networking
- Git branches, pull requests and repository workflows
- Containers / Docker fundamentals
- Kubernetes workload and Service basics
- CI/CD pipeline concepts
- Terraform/OpenTofu or equivalent IaC concepts
This course is not
- A Kubernetes administration course
- A Backstage installation course
- An Argo CD certification course
- A collection of vendor tool tutorials
- A replacement for the prerequisite Fundamentals courses
Core lab environment
Linux, macOS or Windows 11+WSL2 with bash and Python 3. Core labs remain account-free and do not require a cloud account or cluster.
Recommended Academy preparation
Platform Engineering sits on top of capabilities the Academy already teaches.
Use the sequence below as preparation when a prerequisite area is unfamiliar.
Learning sequence
Product first. Interface second. Tools underneath.
Modules 4–5 design the golden-path and provisioning contracts first; Modules 6–8 then implement those ideas with runtime, reconciliation and policy primitives.
Platform engineering as a product
Treat the internal platform as a product for developers: discover repeated friction, define a supported interface, and measure whether it reduces cognitive load without hiding critical operational reality.
Open module →Developer journeys and platform contracts
Turn developer needs into explicit self-service contracts: inputs, outputs, policies, ownership, failure states, support boundaries and service-level expectations.
Open module →Software catalog, ownership and documentation
Use a software catalog to make services, owners, systems, APIs and documentation discoverable, and treat metadata quality as an operational control rather than decorative inventory.
Open module →Golden paths and software templates
Design an opinionated, supported way to create and change services, with safe defaults, extension points and generated evidence instead of brittle copy-and-paste.
Open module →Self-service environments and provisioning
Expose infrastructure and environment capabilities through bounded self-service contracts with quotas, ownership, TTLs, idempotency and cleanup instead of handing every developer raw administrative access.
Open module →Kubernetes, Helm and runtime abstractions
Use Kubernetes and packaging primitives behind stable workload contracts, while preventing platform abstractions from leaking every cluster implementation detail to application teams.
Open module →GitOps and declarative delivery
Use version-controlled desired state and reconciliation to make platform delivery observable, reviewable and recoverable, while separating build pipelines from deployment authority.
Open module →Policy guardrails and secure defaults
Encode organizational requirements as early feedback and runtime admission guardrails, distinguishing defaulting, warning, auditing and enforcement while maintaining accountable exceptions.
Open module →Observability, scorecards and operational readiness
Make operational readiness part of the platform product by connecting ownership, telemetry, SLOs, runbooks and scorecards to concrete remediation rather than vanity compliance percentages.
Open module →Multi-tenancy, identity, quotas and cost governance
Design shared-platform boundaries using least privilege, tenancy scope, quotas, ownership and cost signals so self-service scales without turning the platform into an uncontrolled shared admin plane.
Open module →Platform reliability, adoption and evolution
Operate the platform itself as a reliable product: define SLOs, on-call and support ownership, manage intake/roadmaps/deprecations, measure adoption and task success, align platform/enabling/application teams, and evolve the platform from evidence.
Open module →Capstone — build a self-service golden path
Design and validate a small internal platform contract that turns a developer service request into owned, policy-compliant, observable desired state with a rollback path and measurable platform outcome.
Open module →Real-tool practicum
Model the idea first, then watch real controllers enforce and reconcile it.
Every module retains an account-free core lab. Key runtime, GitOps and policy modules now point to a disposable local kind environment so the learner can see controller behaviour rather than only simulate it.
One-command local substrate
./ops/setup-platform-kind-lab.shCreates or reuses the disposable gnu-platform-lab kind cluster and platform-lab namespace. Clean it with ./ops/cleanup-platform-kind-lab.sh.
Module 06 · runtime
Inspect a real Kubernetes node/context and render the supported Helm workload contract before deployment.
Module 07 · GitOps
Install a pinned Argo CD lab release, create the official guestbook Application, introduce live drift and observe self-healing reconciliation.
Module 08 · policy
Install a tagged Kyverno release, enforce an ownership-label contract, observe a denied request and then an admitted request.
Learning modules
FREE
All 12 modules are available without purchasing a certificate.
Hands-on labs
FREE
Core labs and provided local lab scripts are part of the learning experience.
Assessment
FREE
30 randomized questions, 35-minute server timer, pass mark ≥75%, maximum 2 attempts per 24 hours.
Certificate
OPTIONAL · ₹499 incl. GST
Purchase is only for certification after a qualifying assessment result; learning and assessment remain free.
Course stewardship
Curriculum maintained by GNU Group Learning Academy. A named instructor/author profile should only be published when the corresponding role, biography and credentials have been verified for public use.
Tooling philosophy
Backstage, Kubernetes, Helm, Argo CD, Terraform/OpenTofu, Kyverno and related tools are implementation choices. The supported developer contract is the durable learning object.
Emerging workloads
Module 11 includes a field note on AI/LLM and GPU platform extensions—accelerator scheduling, model/artifact registries, quotas, cost and provenance—without turning Fundamentals into a specialized AI-platform course.
Knowledge assessment
Prove you can diagnose contracts and platform decisions—not merely name tools.
30 questions are selected from an 84-question bank across seven domains. The bank contains 28 scenario/application questions and each attempt is guaranteed at least 10 scenarios while retaining the category quotas.
12 MODULES→30 QUESTIONS · ≥10 SCENARIOS→35 MIN · PASS ≥75%→2 ATTEMPTS / 24H→OPTIONAL CERTIFICATION
2–3 hour platform capstone
Build and defend one self-service golden path.
The capstone validates ownership, build-platform and supply-chain evidence, immutable artifact identity, workload-identity/secrets boundaries, policy, readiness, rollback and platform-team operating semantics. A portal screenshot is not enough.
Developer need→Catalog→Golden path→Build evidence→GitOps→Policy→Operate