Permitting is split into small independently deployable services for payments, inspections, and notices instead of one monolith. What cloud-native concept does this primarily illustrate?
Select an answer to reveal the explanation.
Short Explanation
Chopping permitting into payments, inspections, and notices is microservices in civic clothing—each crew ships its own piece without waiting on the whole city hall build. Independent deployability is the punch line. One giant monolith would couple every change together.
Full Explanation
Microservices architecture decomposes an application into small, independently deployable services that own focused capabilities. Splitting permitting into separate payments, inspections, and notices services instead of one monolith primarily illustrates microservices and the cloud-native preference for independently releasable units. Hardware pass-through of specialty PCIe cards into a single guest is a virtualization device-assignment technique unrelated to application decomposition. Cold-site disaster recovery addresses facility readiness after outages, not how permitting code is modularized. Vertical scaling of one giant VM when traffic spikes is a capacity tactic that can still apply to a monolith and does not define the microservices concept. Exam caveat: microservices emphasize independent deployability and bounded contexts; simply running multiple processes on one VM without independent release and ownership is not the full pattern. Operational check: give each permitting service its own deployment pipeline and health checks, define clear API contracts between payments, inspections, and notices, avoid a shared mutable database schema that re-creates a distributed monolith, and monitor per-service error budgets.