Design a golden path CI/CD pipeline for a Go API

WHAT THIS TESTS: This question tests platform engineering judgment. Interviewers want to see if you can design opinionated infrastructure that reduces cognitive load while preserving enough flexibility for edge cases. They are looking for awareness of security non-negotiables, maintainability, and the governance model behind a golden path.

A GOOD ANSWER COVERS: First, mandatory stages that enforce standards. These should include dependency vulnerability scanning, unit and integration testing, linting and formatting checks, static application security testing, reproducible container builds with pinned base images, image signing, and staged deployments with smoke tests. Second, a flexibility mechanism. Great candidates mention pipeline hooks such as pre-build or post-deploy scripts, opt-in feature flags for additional stages, or YAML config overlays that inherit from the base template. Third, governance. Explain how changes roll out via versioned templates, how teams request new hooks through a platform backlog, and how exceptions are audited rather than silently allowed. Fourth, developer experience. Mention local testing of the pipeline, clear documentation, and self-service onboarding so teams adopt it voluntarily rather than by mandate.

COMMON WRONG ANSWERS: A rigid pipeline with no extension points signals you have not operated in a large engineering org. Letting teams fully customize or disable security stages like SAST or container scanning is another failure mode. Proposing a golden path that requires forking the entire template for minor tweaks shows poor abstraction. Ignoring secrets management or suggesting each team manages their own registry credentials is a red flag.

LIKELY FOLLOW-UPS: How would you roll this out to fifty teams without breaking existing workflows? What happens when a team needs a GPU node or a non-standard dependency? How do you prevent configuration drift if teams can override stages? How do you measure adoption and developer satisfaction?

ONE CONCRETE EXAMPLE: Imagine a Go backend API. The golden path template runs go mod tidy and go vet, executes go test with race detection, performs a Trivy scan on dependencies, builds a distroless image with ko or BuildKit, signs it with Cosign, pushes to a central registry, and deploys to a staging namespace via GitOps. A team that needs protobuf code generation adds a pre-build hook in their repo-level pipeline config. A team that requires a canary deploy opts into the flag canary: true, which injects a Flagger stage after the standard smoke test. Neither team maintains the base template.