A city permitting office relocates its long-lived JVM monolith onto OCI Compute instances with the same nightly patch cycle and shared in-memory session store. Which change would most clearly move the workload toward a cloud-native design?
Select an answer to reveal the explanation.
Short Explanation
Think of the platform like a fleet of interchangeable city buses: you design for routes and capacity, not for keeping one particular bus forever. Lift-and-shift keeps the same nursed monolith on IaaS. Cloud-native means elastic units, declared desired state, and replaceable infrastructure.
Full Explanation
Cloud-native design for the permitting office starts by treating the workload as many small, independently shippable units whose desired state is declared to the platform, with infrastructure treated as replaceable rather than nursed. That posture replaces the long-lived JVM monolith’s shared in-memory session store and nightly host patch cycle with elastic units that can scale, fail, and release on their own timelines. Independently shippable units also force session and durable state out of process memory into shared backing stores so any replica can serve a request.
Resizing Compute shapes and enabling boot-volume backups improves IaaS operations but leaves the monolith’s release blast radius, in-memory coupling, and host-tending habits intact—capacity and recovery hygiene are not the same as cloud-native decomposition. Moving the same JAR onto a larger instance in another availability domain is still lift-and-shift disaster recovery; the deployable unit and session model remain traditional. Registering an instance with regional DNS and opening a public load-balancer listener exposes the host but does not create replaceable units, declared desired state, or disposable infrastructure.
Exam caveat: cloud-native on OCI is a design posture (small units, desired state, replaceability), not merely “running on Compute” or adding networking and backup features to an unchanged stack.
Operational check: after a change, confirm you can deploy a new revision without SSH patching the live host, that sessions survive replica replacement, and that the platform reconciles replica count from declared desired state rather than from a manual start/stop checklist.