After splitting a monolith, a city IT group wants each microservice to stay independently deployable. Which ownership model supports that goal?
Select an answer to reveal the explanation.
Short Explanation
If you build the boat, you also sail it and fix the leaks. Throwing a finished crate over a wall to another crew recreates the bottleneck microservices were meant to remove.
Full Explanation
Independent deployability needs matching organizational ownership: the team that changes a municipal microservice should also ship it, observe it, and own its pages. End-to-end ownership removes throw-over-the-wall handoffs so recovery and releases stay local to the people with the deepest context. That methodology pairs with microservices; without it, you rebuild the monolith’s bottleneck in the org chart.
Handing finished artifacts to a separate operate-only group that never changes the code recreates a build/run wall and slows fixes when production pages fire. Centralizing all releases through one weekly release-train board batches unrelated services and undoes independent cadence. Assigning coding to feature teams and production alerts exclusively to a shared NOC separates accountability from change authority so the people who can fix the code are not the ones woken for the outage.
Exam caveat: you-build-it-you-run-it does not ban a platform team that provides shared tooling; it bans outsourcing ownership of a service’s production behavior. Operational check: for each service, verify a single owning team is listed on the runbook, pager rotation, and deployment pipeline—and that a failed deploy pages that team, not an unrelated central queue.