During a late-night outage, a transit-authority developer finds a misconfigured runtime on a production host and is tempted to SSH in and edit files until the service recovers. Which immutable-infrastructure response is the cloud-native alternative?
Select an answer to reveal the explanation.
Short Explanation
Immutability is like swapping a broken streetlight bulb for a known-good one instead of soldering inside the old housing at midnight. You launch a fresh revision and retire the bad one. Rollback becomes redeploying yesterday’s artifact, not scavenging a drifted box.
Full Explanation
Immutable infrastructure answers the transit-authority outage by launching a new known-good revision of the image or host and retiring the drifted one. Rollback becomes redeploying yesterday’s artifact instead of scavenging a box someone edited under pressure. That keeps production instances disposable and reproducible: what runs is always a built revision, not a host whose filesystem diverged during an emergency SSH session.
Patching libraries on the live host and leaving that instance as the golden image institutionalizes drift and makes “what is production?” unanswerable after the next emergency edit. Disabling health checks so a misconfigured process stays in the load-balancer pool hides failure from the platform and keeps bad instances in the serving path. Copying production data onto a developer laptop and serving traffic from there until morning breaks trust boundaries, auditability, and any notion of a controlled release.
Exam caveat: immutability does not forbid all configuration; it forbids mutating the running production artifact in place as the recovery strategy. Config still belongs in the release model, not in ad-hoc live edits.
Operational check: recover by deploying the last known-good image digest, confirm the bad instance is drained and terminated, and verify you can roll forward or back without SSH file edits on the live host.