Capacity is tight and running two full production stacks for blue-green is too expensive for the parks reservation API. Which deployment approach is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
If you cannot afford two complete stages, do not rent the second theater — upgrade seats row by row instead. Rolling uses the capacity you already have and keeps service up. When dual-stack blue-green cost is the blocker, rolling (or sometimes in-place) is the practical fit.
Full Explanation
Rolling deployment upgrades instances in batches within the existing capacity envelope, avoiding the need to run a full duplicate production stack. When capacity is tight for the parks reservation API and blue-green’s idle twin is too expensive, rolling is the appropriate municipal compromise that still enables incremental change with continuous service. Blue-green that doubles compute spend for the release window fails the cost constraint stated in the stem. Maintaining a permanent idle twin of production solely for every minor patch fails because it institutionalizes the same capacity waste the city cannot afford. Shipping only weekend big-bang outages with no incremental update path fails because it abandons progressive deployment discipline and forces citizen-visible downtime windows. Exam caveat: Cloud+ often tests whether you recognize capacity and cost as first-class selectors among blue-green, rolling, and canary—not only risk vocabulary. Operational check: size batches so remaining capacity meets parks peak SLOs, pause on failed health checks, and verify reservation and payment flows during mixed-version periods. Record the cost rationale in the architecture decision record so future releases do not reintroduce unaffordable dual-stack assumptions for this civic API.