A legacy Elastic Beanstalk civic app must move toward containers with an upgrade path that stages features and supports rollback. Which approach best fits?
Select an answer to reveal the explanation.
Short Explanation
Do not yank the Beanstalk rug. Ease into containers with feature flags so you can turn a risky feature off and roll back—citizens should not notice the renovation dust.
Full Explanation
Moving a legacy Elastic Beanstalk civic application toward containers is safest when the upgrade is incremental: feature flags stage new behavior for subsets of users, and a rollback-capable deployment path preserves a way back if containerized components misbehave. That approach limits blast radius for permitting, licensing, or other citizen-facing flows still anchored on Beanstalk during transition. Deleting the Beanstalk environment mid-day with no replacement running creates an outage by design and abandons users mid-transaction. Forking into unmanaged EC2 pets without a pipeline or flags reintroduces snowflake operations and weakens rollback discipline for a regulated civic workload. Disabling version control so operators deploy laptop zip files destroys provenance and makes safe rollback guesswork. Exam caveat: feature flags do not replace data migration planning—dual-write or expand/contract schema steps may still be required before a flag can be safely flipped for all users. Operational check: enable a flagged container path for a small internal cohort, exercise the rollback procedure to the Beanstalk-known-good path, and verify citizen-critical transactions complete on both paths before widening the flag.