Service Catalog and Ownership
You are building a service catalog for your IDP. Your company has 200 microservices, and nobody knows who owns half of them. How do you fix this, and what does a good service catalog look like?
You are building a service catalog for your IDP. Your company has 200 microservices, and nobody knows who owns half of them. How do you fix this, and what does a good service catalog look like?
A service catalog is the single source of truth for 'what do we run, and who owns it?' Without one, every incident starts with 20 minutes of Slack threads asking 'does anyone know who owns this service?' Here is how I would fix the ownership mess: First, require every service to have a catalog-info.yaml in its repo. This file declares the service name, owning team, dependencies, and API specs. If a repo does not have one, it shows up as 'unowned' in the catalog, which creates social pressure to fix it. Second, automate catalog discovery. Do not rely on people manually registering services. Scan your GitHub org, pull in metadata from Kubernetes (what is actually running), and cross-reference with your cloud provider. If a service is running in production but is not in the catalog, flag it. Third, make the catalog useful, not just a registry. A good service catalog shows: who owns this, what it depends on, its current health, recent deployments, on-call rotation, API docs, and cost. If the catalog is just a list of names, nobody will maintain it. The ownership model matters too. Use team ownership, not individual ownership. People leave. Teams persist. And every service must have exactly one owning team. Shared ownership means no ownership. Tools like Backstage, Cortex, or OpsLevel do this well, but you can start with a simple YAML file per repo and a script that aggregates them.
This question tests real operational experience. Anyone who has dealt with a microservices mess knows that the catalog is the foundation of everything else in an IDP. Without knowing what you run and who owns it, you cannot build self-service, you cannot route incidents, and you cannot track costs. Listen for whether the candidate talks about keeping the catalog accurate over time, not just the initial setup.
catalog-info.yaml that lives in each service repo
Script to find unowned services running in production
- Building a catalog that requires manual registration and then wondering why it is always out of date
- Assigning ownership to individuals instead of teams, so it breaks when someone leaves
- Treating the catalog as a one-time project instead of something that needs ongoing data quality checks
- How do you keep the catalog accurate when teams forget to update their catalog-info.yaml?
- How would you handle the 100 services that currently have no owner? You cannot just assign them randomly.
- What is the difference between a service catalog and a CMDB?
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
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.
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