Designing Golden Paths
We want our developers to follow best practices, but we do not want to slow them down with mandatory reviews for every infrastructure change. How would you design 'golden paths' in an internal developer platform?
We want our developers to follow best practices, but we do not want to slow them down with mandatory reviews for every infrastructure change. How would you design 'golden paths' in an internal developer platform?
Golden paths are pre-approved, opinionated templates that let developers build things the 'right way' by default. The trick is making the golden path the easiest path, not just the compliant one. Start by looking at what your teams build most often. If 80% of new services are REST APIs with a PostgreSQL database, build a template for exactly that. It should include the Dockerfile, CI/CD pipeline, Terraform for the database, monitoring dashboards, and alerting rules. A developer runs one command and gets a working, production-ready service in minutes. The key design principles: 1. Golden paths are optional, not mandatory. If a team needs something custom, they can go off-path. But going off-path should require more effort, not less. 2. Encode your standards into the template. Do not write a doc that says 'all services must have health checks.' Instead, bake the health check endpoint into the template so it exists from day one. 3. Keep templates versioned and upgradeable. When you update the base template (say, to add OpenTelemetry tracing), teams on older versions should be able to pull in the update without rewriting their service. 4. Use policy-as-code (OPA, Kyverno) as the safety net for off-path cases. If someone deploys without a health check, the admission controller catches it. The goal is that following best practices requires zero extra effort. Breaking them requires a deliberate choice.
This question gets at a fundamental platform engineering tension: how do you provide guardrails without creating bottlenecks? Candidates who have actually built platforms will talk about making the right thing easy, not making the wrong thing hard. Listen for whether they understand the difference between a template and a mandate. The best answers reference real trade-offs, like how to handle template versioning when you have 50 services on v3 of your template and you just shipped v5.
Backstage scaffolder template for a golden path microservice
OPA policy catching services that skip the golden path health check
- Making golden paths mandatory and creating a bottleneck when teams need something the template does not support
- Building templates that are too rigid - every field hardcoded, no room for customization
- Not versioning templates, so updates to the golden path break existing services
- How do you handle upgrading 50 services from template v3 to v5 without breaking them?
- A team says the golden path does not fit their use case. What do you do?
- How do you decide when a one-off request should become a new golden path?
- What metrics tell you whether your golden paths are actually being adopted?
More Platform Engineering interview questions
Also worth your time on this topic
Building an Internal Developer Platform from Scratch
A step-by-step checklist for designing and building an internal developer platform (IDP) that gives your engineers self-service access to infrastructure, environments, and deployments without filing tickets.
60-120 minutes
Internal Developer Platform Purpose
Your team keeps filing tickets for things like creating new services, setting up databases, and getting access to staging environments. Your CTO asks you to fix this. What would you build, and why?
junior
Building an Internal Developer Platform from Scratch
A step-by-step guide to designing and building an internal developer platform that gives your teams self-service infrastructure, faster deployments, and fewer tickets to the platform team.