A water-department product team ships a billing microservice but still pages a separate operations group whenever the service misbehaves at 2 a.m. Which cloud-native principle are they missing?
Select an answer to reveal the explanation.
Short Explanation
DevOps culture is like a neighborhood watch where the builders also answer the night call—not a handoff over a fence. Shared ownership and tight feedback loops are the principle. Pipeline SKUs and quarterly boards are not the point of this pillar.
Full Explanation
The missing principle for the water-department billing microservice is DevOps culture: the people who write the service also own how it ships and how it behaves in production. Shared ownership closes the feedback loop between code changes and 2 a.m. signals, so the team that can fix the design is the team that feels the pages. Handing runtime pain to a separate operations group recreates the wall-of-confusion handoff that cloud-native delivery is meant to erase.
Mandating a single commercial CI product for every repository confuses toolchain standardization with cultural ownership; a pipeline SKU does not by itself make developers own production behavior. Region-level disaster recovery with active-active databases in every geography is an architecture concern, not the cultural principle this item targets. Forcing every change through a quarterly change-advisory board before merge lengthens feedback loops and fights the frequent, owned-change model DevOps culture enables.
Exam caveat: this fundamentals question is about ownership and feedback, not an OCI DevOps pipeline design exercise or a multi-region DR topology quiz.
Operational check: confirm the on-call rotation for the billing service includes the developers who ship it, that they can deploy a fix without a separate ops ticket wall, and that production metrics and pages route to that same team.