Practice the vocabulary of centralized service ownership and production-readiness tracking.
0 / 5 completed
1 / 5
At standup, a dev mentions a centralized, searchable inventory listing every microservice in the organization, along with its owning team, repository, and current on-call contact. What is this capability called?
A service catalog is a centralized, searchable inventory listing every microservice across the organization, along with structured metadata like its owning team, repository location, and current on-call contact. This gives any engineer a reliable, up-to-date way to find who owns a given service, rather than relying on a manually maintained spreadsheet that quickly goes stale or a private list only one team can see. It's a foundational piece of infrastructure for any organization operating at a scale where dozens or hundreds of services exist.
2 / 5
During a design review, the team wants each service to be automatically scored against a defined set of production-readiness checks, like having monitoring and an on-call rotation configured. Which capability supports this?
Automated service scorecards evaluate each service against a defined set of production-readiness checks, like having monitoring and an on-call rotation properly configured, and surface a score reflecting how well it meets those standards. This replaces an ad hoc, manual audit process with a consistent, continuously updated evaluation applied uniformly across every service in the catalog. It gives engineering leadership a scalable way to identify which services still need investment to meet the organization's baseline operational standards.
3 / 5
In a code review, a dev notices the catalog automatically pulls a service's current on-call contact and recent deployment history directly from connected tools, rather than requiring someone to manually update that information. What does this represent?
Automated metadata synchronization pulls information like a service's current on-call contact or recent deployment history directly from the connected tools that already track it, rather than requiring someone to manually re-enter and maintain that same information a second time in the catalog. This keeps the catalog trustworthy and current without adding a manual maintenance burden on every team. A catalog that isn't automatically kept in sync tends to go stale quickly, since a manually maintained record type like this is often the first thing to be forgotten during a busy sprint.
4 / 5
An incident report shows an engineer paged the wrong team during an outage because the service catalog's listed on-call contact was outdated and hadn't synced with a recent ownership change. What practice would prevent this?
Verifying that automated synchronization is actually functioning correctly for a critical field like on-call ownership catches a broken sync pipeline before it leads to an engineer paging the wrong team during a real incident. Assuming the catalog is always current without any verification treats an automated system as infallible, when a broken integration can silently go unnoticed for a while. This periodic verification is a reasonable safeguard given how consequential outdated on-call information can be during an actual outage.
5 / 5
During a PR review, a teammate asks why the organization maintains a centralized service catalog instead of relying on each team's own internal documentation and institutional knowledge about their services. What is the reasoning?
Relying on each team's own separate documentation and institutional knowledge means finding information about an unfamiliar service often depends on knowing exactly who to ask, which breaks down as the organization grows and engineers move between teams. A centralized catalog gives everyone a consistent, searchable place to find that same information regardless of who they know. The tradeoff is the ongoing effort of keeping the catalog's automated integrations properly configured and functioning, so its data stays trustworthy rather than silently drifting out of date.