Describe high-level steps to onboard a microservice via self-service CI/CD

WHAT THIS TESTS: This question evaluates platform engineering mindset and developer experience design at a beginner level. The interviewer wants to see if you think in terms of reusable abstractions rather than one-off custom implementations. They are looking for understanding of the self-service paradigm: teams should be able to onboard with minimal platform team intervention while still respecting security, compliance, and operational standards. The scope is high-level, so deep tooling specifics matter less than structural clarity and sensible sequencing.

A GOOD ANSWER COVERS: First, scaffolding and discovery. Provide a service catalog, cookie-cutter template, or repository generator that creates the standard repo layout, ownership metadata, and baseline pipeline configuration files. Second, reusable pipeline modules. Offer versioned, centrally maintained templates or containerized actions for stages like checkout, build, unit tests, static analysis, container image scanning, artifact publishing, and deployment. Third, environment promotion and configuration separation. Use variable injection, per-environment GitOps overlays, or sealed secrets so the same pipeline definition runs against dev, staging, and production without hardcoded values. Fourth, guardrails and observability. Enforce mandatory steps such as security scanning, cost tagging, and policy checks that fail the build rather than requiring human approval gates for routine changes. Include automatic wiring for logging, metrics, and alerting. Fifth, ownership and documentation. Make the onboarding process discoverable through internal docs, a developer portal, or a simple CLI wizard, and ensure the service team owns their pipeline configuration while the platform team owns the underlying modules.

COMMON WRONG ANSWERS: A major red flag is describing a ticket-based workflow where the platform team manually creates a new Jenkins job, namespace, or cloud project for every onboarding request. Another weak pattern is proposing a completely blank slate where every team writes their own pipeline from scratch, which leads to drift, security gaps, and operational inconsistency. Avoid conflating CI and CD without explaining how artifacts are promoted and how environment-specific secrets are managed safely.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle breaking changes to the shared pipeline modules without breaking every service simultaneously. They might probe on secrets rotation, multi-region deployments, or how to prevent a single bad service from exhausting shared build pool resources. Be ready to discuss canary deployments, feature flags, or how teams opt out of defaults for exceptional cases.

ONE CONCRETE EXAMPLE: Imagine a platform using GitHub Actions and ArgoCD. The developer runs a CLI command that scaffolds a repository with a preconfigured workflow file referencing reusable workflows owned by the platform team. On push to main, the reusable workflow builds a container image, runs Trivy scanning, pushes to a registry, and updates a dev overlay in a GitOps repo. The developer never files a ticket, but they cannot skip the scan stage because the reusable workflow enforces it. Promotion to staging and production uses the same image tag but different overlay folders with environment-specific replica counts and secrets.