A parks recreation site suffers outages when in-place package updates fail mid-deploy on long-lived instances. Which deploy approach best reduces change-related downtime?
Select an answer to reveal the explanation.
Short Explanation
Blue/green is like swapping to a fresh stage set instead of rewiring lights mid-show. New ASG or ECS tasks go live only when healthy, and the old set stays until you cut over. Live SSH patching is how shows go dark.
Full Explanation
A parks recreation site that suffers outages when in-place package updates fail mid-deploy on long-lived instances is showing classic mutable-infrastructure risk. Immutable blue/green deployments with Auto Scaling groups or Amazon ECS best reduce change-related downtime because a new fleet or task set is launched alongside the old one, health-checked, then cut over; a bad change rolls back by shifting traffic back to the prior green set instead of attempting emergency SSH surgery on half-patched hosts.
SSH into every production instance and patching packages live during peak visitor hours fails because concurrent mutable changes create inconsistent fleets and maximize blast radius during citizen traffic. Overwriting files on the only production server and rebooting if the site stops responding fails as both a SPOF and an uncontrolled deploy method. Disabling deployment health checks so partial rollouts always complete fails conceptually: health checks are what stop a bad version from taking all parks traffic.
Exam caveat: blue/green requires enough capacity and a traffic-shifting mechanism (ALB target groups, ECS deployment controllers, or similar); without health gates it becomes just two mutable piles. Operational check: define immutable AMIs or container images, automate blue/green with automatic rollback on failed health checks, and ban emergency live package edits except through the same pipeline.