Practice the vocabulary of controlled, gradual feature releases using flags.
0 / 5 completed
1 / 5
At standup, a dev mentions releasing a new feature to only five percent of production users initially, gradually increasing that percentage over several days while watching for errors. What is this deployment technique called?
A percentage-based rollout releases a new feature to a small fraction of production users first, then gradually increases that percentage over time while monitoring for errors, rather than exposing the entire user base to a brand-new feature all at once. This limits the blast radius of an unexpected bug to a small subset of users before it potentially affects everyone. It's a core technique enabled by feature flags for reducing the risk of a full-scale production release.
2 / 5
During a design review, the team wants to instantly disable a newly released feature for all users the moment a critical bug is discovered, without deploying new code. Which capability supports this?
A kill switch flag lets the team instantly disable a newly released feature for all users by flipping a flag's configuration, without needing to deploy new code or perform a slower rollback of the release itself. This dramatically speeds up incident response when a critical bug is discovered after release. It's one of the most operationally valuable capabilities feature flags provide, separating the ability to turn a feature off from the traditional, much slower code deployment process.
3 / 5
In a code review, a dev notices a flag's rule targets a specific list of internal employee accounts, exposing the new feature to them before it's released to any real customer. What does this represent?
Internal dogfooding via targeted flag rules exposes a new feature only to a specific list of internal employee accounts first, letting the team use and stress-test it in a real production environment before any actual customer is exposed to it. This catches issues that only surface under genuine production conditions, which a staging environment doesn't always fully replicate. It's a common intermediate step between initial development and a broader percentage-based rollout to real customers.
4 / 5
An incident report shows a stale feature flag was left permanently enabled at one hundred percent months after its rollout completed, and nobody remembered to remove the now-unnecessary flag and its associated conditional code. What practice would prevent this?
Regularly auditing and removing a fully rolled-out flag, along with its now-unnecessary conditional code, prevents the codebase from accumulating stale flags that add complexity with no ongoing benefit. Assuming this cleanup happens naturally without a dedicated process is how flags accumulate indefinitely in a real codebase. This flag hygiene is a widely recognized best practice for any team using feature flags at meaningful scale, since flags are meant to be temporary release mechanisms, not permanent code branches.
5 / 5
During a PR review, a teammate asks why the team releases a new feature through a percentage-based rollout instead of deploying it directly to all production users at once. What is the reasoning?
Deploying a new feature directly to the entire production user base at once means any unexpected bug immediately affects everyone with no opportunity to catch it at smaller scale first. A percentage-based rollout limits that exposure to a small group initially, catching problems before they reach the full user base. The tradeoff is the added complexity of managing flag rules and monitoring metrics carefully throughout the gradual rollout process.