A tiny utility VM is upgraded on the same instance during a maintenance window with brief downtime accepted. Which deployment strategy fits this approach?
Select an answer to reveal the explanation.
Short Explanation
In-place is fixing the car you already own in the driveway — same box, new bits, short downtime okay. A single utility VM during a maintenance window is classic in-place. You are not spinning a twin garage (blue-green) or trickle-testing a tiny traffic slice.
Full Explanation
In-place deployment updates software on the existing instance or environment rather than standing up a parallel stack, often accepting a brief approved outage during a maintenance window. A tiny utility VM upgraded on the same instance with accepted downtime fits that pragmatic municipal pattern when duplicate capacity is unnecessary. Blue-green that stands up an identical second utility VM and switches DNS fails as the best fit because the stem accepts downtime on the same instance rather than requiring an idle twin and instant cutover. Canary that routes 5% of utility jobs to a brand-new fleet first fails because a single tiny VM has no meaningful traffic percentage split across fleets. Rolling across dozens of identical nodes fails when only one VM exists; rolling presupposes a multi-instance pool. Exam caveat: Cloud+ expects you to choose in-place when constraints are single-instance, low criticality, or maintenance-window tolerance, not to force blue-green or canary vocabulary onto every change. Operational check: schedule the civic change window, take a recoverable snapshot or backup, apply the upgrade, run smoke tests, and confirm monitoring before closing the ticket. Document why parallel strategies were rejected so future on-call staff do not invent unsupported canary paths for a lone utility host that serves city background jobs.