A project team debates whether citizen records need rigid relational schemas or flexible documents, while another debate asks who patches the database engine. What distinction should the architect emphasize?
Select an answer to reveal the explanation.
Short Explanation
One argument is about the shape of the data — tables versus documents. The other is about who changes the oil on the engine — you or the provider. Do not mash them together: you can run relational or document models either self-managed or managed. Keep those two dials separate.
Full Explanation
Data model choice—relational versus non-relational—answers how information is structured and queried, while deployment option—self-managed versus provider-managed—answers who operates the engine day to day. An architect should emphasize that those axes are independent: citizen records might be relational or document-oriented, and either model can run self-managed on VMs or as a managed cloud service. The brand of hypervisor does not determine whether data is relational. Provider-managed services are not limited to unstructured object blobs; managed relational and document engines are common in municipal architectures. Tagging alone cannot convert a file share into an ACID relational system with enforced foreign keys. Exam caveat: Cloud+ scenarios sometimes intertwine schema debates with operations debates—separate “what store” from “who patches” to avoid false constraints in design reviews and procurement. Operational check: for each municipal dataset, record both the chosen data model and the deployment option in the architecture decision register, map shared-responsibility tasks accordingly, train application owners on the distinction, and ensure procurement language does not accidentally force the wrong axis (for example, buying managed object storage when transactional relational integrity is required).