A Kubernetes golden path is a maintained, supported route for taking a common service from repository creation to a secure, observable and recoverable runtime. It is not a single YAML template and should not conceal every platform decision from developers.
Direct answer
Build the smallest end-to-end path that proves:
- a service can be created from an owned template;
- infrastructure and configuration are reviewable;
- artifacts are built and verified;
- policy failures block or route to an exception;
- deployment is reconciled and reversible;
- telemetry and an SLO are present; and
- cost and ownership are attributable.
The CNCF Platform Engineering Technical Community Group describes golden paths as preferred patterns supported by reusable templates, practices and guardrails. See the CNCF platform engineering work.
Begin with one developer journey
Choose a common service type and interview its users. Record current steps, waiting, handoffs, failure points, security reviews and operating effort. Define the intended reduction in time or risk.
Avoid starting with every language, cloud and database. A path that supports one meaningful workload end to end is more testable than a catalogue of unfinished templates.
Layer 1: service template
The template should create a repository with build configuration, dependency policy, health endpoints, ownership metadata, basic tests, documentation and local-run instructions. Generate only what the platform team can maintain.
Expose configuration choices that materially differ—data classification, network exposure, runtime size or availability tier—rather than asking developers to choose low-level infrastructure components.
Layer 2: infrastructure and identity
Provision namespaces, service identities, secrets integration, network boundaries and required managed services through reviewed infrastructure code. Use short-lived workload identity and least privilege instead of long-lived cloud keys.
Make every resource attributable to an owner, environment and cost center. Define lifecycle behavior for preview environments and abandoned services.
Layer 3: controlled delivery
Build an immutable artifact, create a software bill of materials where required, scan dependencies and configuration, and verify provenance or signature before admission. Reconcile deployment from version-controlled intent using an approved pipeline or GitOps controller.
The path should include progressive release or another safe rollout method, health verification and tested rollback. A successful deployment command without a recovery method is incomplete.
Layer 4: policy and exceptions
Apply policy at useful points: source review, pipeline, infrastructure plan and cluster admission. Kubernetes recommends careful RBAC, Pod Security Standards, network controls and protected audit logs in its security checklist.
Policy errors should explain what failed and how to fix it. Define an exception workflow with an owner, justification, compensating control and expiration. Hidden or permanent exceptions erode the path.
Layer 5: observability and SLO
Provide structured logs, metrics, traces and deployment events by default. Let the service owner define a small number of user-relevant indicators and an SLO. Include dashboards, alert ownership and a runbook.
Run a failure exercise: break a dependency, inspect telemetry, communicate impact and restore service. Observability is proven through diagnosis, not by showing that an agent is installed.
Layer 6: feedback and product operation
Track time to first deployment, successful completion, adoption, template failures, support requests, exceptions, reliability and cost. Interview users after adoption. Version the path and communicate breaking changes.
Maintain an escape hatch for workloads the standard path cannot support. The exception may become the next product capability if demand is repeated and justified.
Reference acceptance test
A developer unfamiliar with the platform should be able to create the service, deploy it, view telemetry, trigger a controlled failure, roll back and identify its cost allocation using documented support. The platform team should be able to update a shared control and prove which services are affected.
Practical lab: build and defend the path
The Platform Golden Path Lab creates a reference repository, delivery controls, telemetry, an SLO and unit-cost evidence. The full course adds Kubernetes tenancy, GitOps, artifact trust, self-service and a reliability exercise.
Frequently asked questions
Should a golden path be mandatory?
Make it the easiest supported route for common workloads. Mandatory controls may exist, but teams need a governed exception when the path cannot meet a legitimate requirement.
Is GitOps required?
No single tool is universal. The requirement is reviewable desired state, controlled reconciliation, drift visibility and recovery. GitOps is one widely used implementation pattern.
How many golden paths should a platform provide?
Begin with the few workload patterns that cover substantial repeated demand. Add paths only when user evidence justifies their maintenance cost.
View the Platform Engineering curriculum or request a private platform lab.