Managing a risky release with feature flags
Whether you can decouple deploy from release and roll out safely.
Deploy code dark behind an off flag, enable for internal then small percentage, monitor metrics, ramp gradually, then remove the flag.
What's really being asked
Whether you understand the operational value of feature flags, decoupling code deployment from feature release, and can describe a disciplined, reversible rollout lifecycle.
The full answer
First, deploy the code to production with the flag off, so the feature ships dark with zero user impact and deployment risk is separated from release risk. Then begin a progressive rollout: enable the feature for internal or employee users first to catch obvious problems, then for a small percentage of real users as a canary. At each step, monitor the signals that matter, error rate, latency, and business or feature-specific metrics, comparing flagged versus unflagged cohorts. If anything regresses, flip the flag off instantly, an immediate kill switch that is far faster than redeploying or rolling back. If metrics stay healthy, ramp the percentage gradually (for example 1%, 10%, 50%, 100%), continuing to watch at each tier. Once the feature is fully rolled out and stable, complete the lifecycle by removing the flag and the old code path to avoid accumulating technical debt from stale flags.
The mistakes people make
Flipping straight to 100% with no canary or monitoring, defeating the purpose. Treating the flag as a permanent fixture and never cleaning it up, leaving a tangle of dead conditionals. Forgetting to monitor business metrics, not just system health, since a feature can be technically fine but harm conversion.
What usually comes next
How do you target flag cohorts (percentage, user attributes, regions)? How do you prevent stale-flag debt at scale? How do flags interact with database migrations that are not reversible?
A concrete example
A new recommendation algorithm ships behind an off flag. It is enabled for staff, then 1% of users; latency and click-through look good, so it ramps to 10%, 50%, then 100% over a few days. When an early 1% test showed elevated errors, the flag was flipped off in seconds with no redeploy. After a stable week at 100%, the flag and the old code path are deleted.
Interview question
What is the primary risk-mitigation advantage of releasing a risky feature behind a feature flag rather than a normal deploy?
- a.It makes the application start up faster
- b.It separates deploy from release, enabling gradual rollout and an instant kill switch without redeployingCorrect
- c.It removes the need to monitor metrics during rollout
- d.It guarantees the feature will have no bugs
Why? this is the answer
Flags decouple shipping code from exposing the feature, so you can ramp exposure gradually and disable instantly if metrics regress, far faster than a redeploy. Flags do not remove the need for monitoring nor guarantee bug-free code.
Just read this? Test yourself on what you have been reading.
- #sre
- #feature-flags
- #progressive-delivery
- #release
- #canary
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on sre — each one lists the topics its interview covers.
See open roles