A reporting service on the inspections team starts issuing SQL against the licensing service’s tables to “avoid an extra API hop.” What persistence rule of microservice design does that break?
Select an answer to reveal the explanation.
Short Explanation
Your neighbor does not rummage in your filing cabinet—they submit a request at the counter. Each service owns its data behind its API. Direct SQL into another service’s tables blocks independent deploys and schema evolution.
Full Explanation
Microservice persistence rules say each service owns its data; the inspections reporting service must not issue SQL against the licensing service’s tables to avoid an API hop. Other services change or read that data only through the owning service’s API so licensing can evolve its schema and release train independently. Direct cross-service SQL couples deployments, freezes the owner’s model, and turns “avoiding a hop” into a long-term coordination tax.
Requiring every service to store data only on local container ephemeral disk confuses ownership with ephemeral storage and destroys durability. Requiring all services to share one schema so JOINs remain possible is the opposite of service-owned persistence. Restricting database access to Resource Manager stack outputs misstates both IaC and runtime data-access patterns; Resource Manager is not the microservice data boundary.
Exam caveat: private persistence behind the owner’s API is the rule; Autonomous Database product deep-dives and Resource Manager mechanics are not the core of this item.
Operational check: replace the cross-service SQL with a licensing API (or emitted events), deploy a licensing schema change without coordinating an inspections SQL rewrite, and confirm reporting still works through the published interface.