A county records portal still runs three unrelated apps on one long-lived middleware host that operators patch in place after each CVE. What cloud-native deployment posture should replace that shared farm?
Select an answer to reveal the explanation.
Short Explanation
A shared patched-in-place app server is like one town generator powering three buildings: when you shut it down to fix it, everyone goes dark. Cloud-native prefers sealed, replaceable process images you roll forward. That keeps release identity, scale, and blast radius per app.
Full Explanation
The county records portal should leave the shared, patch-in-place middleware farm and ship each of the three unrelated apps as a self-contained, replaceable process image or function that you roll forward. Each app then has its own release identity, scale dial, and failure blast radius. When a CVE appears, you rebuild and redeploy the affected image instead of taking down a shared app-server that hosts everything else.
Continuing to patch the shared middleware in place preserves a single runtime identity for three workloads, so one emergency patch or restart still stops all three. Moving the three apps onto one larger Compute shape only reduces how often you patch; it does not separate lifecycles or shrink blast radius. Forbidding containers and installing each app from OS packages on dedicated bare metal can isolate hosts physically, but it still tends long-lived machines and usually recreates shared operational coupling without the roll-forward image model.
Exam caveat: “replaceable process image or function” is the deployment posture; the item is not a Functions-versus-Kubernetes product bake-off, and bare metal alone does not equal cloud-native.
Operational check: pick one app, ship a new image revision while the other two keep serving, and confirm a CVE response is a rebuild-and-redeploy of that app’s artifact—not an in-place patch of a shared middleware host.