5 exercises — Practice feature flag vocabulary in English: kill switch, rollout percentage, targeting rules, flag lifecycle management, LaunchDarkly, and OpenFeature standards.
A product manager explains the release strategy to a new engineer: "We use feature flags for every significant feature. The code ships to production but the feature is off by default — controlled by a flag. When we're ready, we don't do a big-bang release. We enable it for internal users first, then 1% of users, then 10%, then 50%, then 100%. If metrics degrade at any rollout percentage, we turn the flag off instantly — no deployment needed. That instant off switch is what makes flags powerful for risk management. We call it a kill switch." What is a kill switch in the context of feature flags?
Kill switch (ops toggle): a feature flag specifically designed as a circuit breaker for operational risk. Unlike release toggles (enabling new features gradually), ops toggles are permanent fixtures — they exist to provide rapid response capability indefinitely. Examples: a flag to disable a new payment integration if the third-party service goes down; a flag to switch from a new recommendation algorithm back to the old one if CTR drops; a flag to disable a resource-intensive feature during peak traffic. Feature flag taxonomy (Martin Fowler): Release toggle: hides incomplete features, enables trunk-based development. Short-lived — removed after graduation. Experiment toggle: A/B testing, multivariate experiments. Controls which variant a user sees. Ops toggle: kill switch, performance toggle. Longer-lived, sometimes permanent. Permission toggle: enables features for specific user segments (beta users, paying customers, internal staff). Rollout vocabulary: Percentage rollout: enable for a random percentage of users (e.g., 5%). Targeting rule: enable for users matching criteria (country, plan, email domain, user ID). Default rule: fallback for users not matching any targeting rule. Gradual rollout: progressively increase the percentage over time, monitoring metrics at each step. In conversation: 'Every significant production deployment should have a kill switch. The two minutes it takes to add a flag beats the hour of emergency deployment to revert.'
2 / 10
A senior engineer explains how they use feature flags for A/B testing: "We're testing two versions of our checkout flow. Flag 'new-checkout-v2' has a targeting rule: 50% of users get variant 'new', 50% get 'control'. The assignment is sticky — the same user always gets the same variant, based on their user ID. We measure conversion rate, cart abandonment, and revenue per session. The experiment runs for two weeks to get statistical significance. LaunchDarkly's SDK evaluates the flag client-side so there's no server round-trip on each page render." What does sticky assignment mean in feature flag experiments?
Sticky assignment: a user must always see the same variant for an experiment to be valid. If a user saw "new checkout" on Monday and "control" on Wednesday, their behavior data is polluted — you can't attribute their conversion to either variant. Implementation: hash(userID + flagKey) → modulo percentage boundary. Same inputs always produce the same output, so assignment is deterministic without storing per-user state. A/B testing vocabulary: Control: the existing behavior (baseline). Variant/Treatment: the new behavior being tested. Allocation: the percentage assigned to each variant. Statistical significance: confidence that observed differences are not random noise (typically p < 0.05). Minimum detectable effect (MDE): the smallest improvement the experiment is powered to detect. Sample ratio mismatch (SRM): when actual traffic split differs from intended — a sign of a broken experiment. LaunchDarkly concepts: Flag variation: possible values (true/false for boolean, or strings/JSON for multivariate). Targeting rules: ordered rules — first match wins. If no rule matches, the default rule applies. Contexts: multi-context SDK — evaluate flags based on user, organization, device, or any custom entity. Streaming connection: SDK maintains SSE/websocket connection to LD; flag changes propagate in milliseconds. In conversation: 'If your experiment doesn't use sticky assignment, your results are meaningless. A user seeing both variants introduces noise that inflates variance and can mask real effects.'
3 / 10
A tech lead raises a concern in a quarterly code review: "We have 47 feature flags in this codebase. Twelve of them have been fully rolled out to 100% of users for more than six months. But the flag checks are still in the code. The engineers who added them left the company. Nobody knows if it's safe to remove them. This is flag debt — stale flags that add cognitive overhead, make the code harder to understand, and create untested code paths. Every flag should have an owner, a removal date, and a process for cleanup after graduation." What is flag debt and what causes it?
Flag debt: a form of technical debt specific to feature management. A flag passes through a lifecycle: Create → Evaluate in test → Gradual rollout → 100% → Graduate (flag removed). The "graduate" step is where teams fail. Consequences of stale flags: Dead code paths: the "false" branch of a fully-rolled-out flag is dead code — never executed, never tested. Cognitive overhead: every developer reading the code must parse "what does this flag do, is it on or off?". Testing complexity: each flag doubles the number of code paths to test. N flags = 2^N theoretical paths. Flag evaluation failures: if the flag platform is down and you have no cached defaults, old code paths may behave unexpectedly. Flag lifecycle best practices: Owner: assign an engineer responsible for cleanup. Expiry date: document expected removal date when creating the flag. Graduation criteria: define what "100% rollout and stable" means. Removal PR: when graduating, create a dedicated PR that removes the flag check and the dead code branch. Tests: remove flag-specific test variants and ensure coverage of the now-permanent behavior. OpenFeature vocabulary: an open standard (CNCF) for feature flag SDKs — vendor-neutral API that providers implement. Allows switching between LaunchDarkly, Unleash, Flagsmith, etc. without changing application code. In conversation: 'Treat flag removal like bug fixes — it improves code health. Schedule it in the same sprint as the 100% rollout, not "someday".'
4 / 10
A product engineer presents the team's progressive delivery strategy: "We practice continuous deployment — code goes to production multiple times a day. But 'deployed' doesn't mean 'released'. New features are deployed behind flags and dark-launched: they execute in production but the user never sees the output. We measure performance, error rates, and resource usage. If everything looks good, we start the rollout: 1% → 5% → 25% → 100%. At each step we gate on metrics — error rate below 0.1%, p99 latency under 200ms. If a metric breaches, we pause. This is progressive delivery." What is progressive delivery and how does it differ from continuous delivery?
Progressive delivery: coined by James Governor (RedMonk). Continuous delivery gets code to production reliably; progressive delivery controls how that code reaches users. Decouples deployment (technical operation) from release (business decision). Techniques: Feature flags: code is deployed to all servers but user-visible only to a percentage. Canary release: deploy new version to a small subset of servers; route a percentage of traffic to them. Unlike flags, canaries involve multiple active code versions running simultaneously. Blue-green deployment: full environment switch with instant rollback. Dark launch: execute new code path but discard output — test performance and correctness in production with no user impact. A/B testing: compare two variants with statistical rigor. Ring-based deployment: deploy in concentric rings — internal, beta, production east, production global. Metric gates: automated promotion decisions based on error rate, latency, business metrics. Tools like Argo Rollouts and Flagger automate canary analysis. OpenFeature standard: defines a vendor-neutral SDK interface for flag evaluation. Application code calls OpenFeature API; a provider plugin connects to LaunchDarkly, Unleash, etc. Allows migration between providers without code changes. In conversation: 'Deploy and release are different words with different meanings. Separating them with flags is one of the highest-leverage practices in modern software delivery.'
5 / 10
An engineering manager explains the team's trunk-based development workflow: "All engineers commit directly to the main branch — no long-lived feature branches. But features take weeks to build. The solution: wrap incomplete features in a flag. The flag is off by default. Engineers commit their work-in-progress daily. CI runs against main, everything passes because the new code path is never reached. Once the feature is complete, we enable the flag in staging, then gradually in production. This is how flags enable trunk-based development — incomplete code ships safely because flags prevent users from reaching it." How do feature flags enable trunk-based development?
Trunk-based development (TBD): all developers integrate to a single main branch (trunk) at least once a day. Avoids long-lived feature branches, which cause painful merge conflicts and delay integration feedback. The challenge: a feature taking 3 weeks cannot be committed piecemeal to main without exposing incomplete work to users. Feature flags solve this: The flag is created first, defaulted to off. All feature code is wrapped in the flag check (if (flags.isEnabled('new-search'))). Daily commits to main — CI passes because the flag is off in all environments. Flag enabled in dev/staging when feature is testable. Gradual production rollout when ready. Flag removed after graduation. Benefits: no merge conflicts from long-lived branches; CI always runs against the integration point; the main branch is always deployable; collaboration is easier when everyone works on the same branch. Complementary practices: Feature branches: still used, but for hours/days, not weeks. Branch by abstraction: for large-scale refactoring without flags. Code-level patterns for flags: Decision point: the place in code where the flag is evaluated. Flag router: single class/module that encapsulates all flag evaluations. Avoids scattering SDK calls. Branching by abstraction: use an interface/adapter pattern to swap implementations. In conversation: 'The best feature branch is one that lives for less than a day. Flags make that possible for features that take weeks to build.'
6 / 10
During a Slack discussion about a new user onboarding flow, Sarah (Product) says: 'We're using feature flags to roll out personalized welcome messages. Initially, everyone sees the standard message, but after completing their first task, they'll be automatically enabled for the 'personalized-greeting' flag.' What does 'automatic enablement' refer to in this context? This phrase is crucial for understanding how dynamic flags operate
'Automatic enablement' describes a dynamic scenario where the flag state is altered without direct human action. It means that a specific user event (completing their first task) triggers an update to the flag's value, enabling it for that particular user. This contrasts with flags set manually or by rules defined in a separate service; the key here is the event-driven change.
7 / 10
Mark, a senior developer, is reviewing a PR that implements a new payment gateway integration. He sees several conditional statements wrapped in feature flags: `if (use_new_gateway) { ... }`. He asks the author: 'What's the purpose of this flag?' The author responds: 'We're using it to gradually roll out the new gateway, starting with a small percentage of users. This allows us to monitor performance and stability before fully switching.' What is the primary benefit of utilizing a feature flag in this scenario? This approach minimizes risk during rollout
The core benefit of using a feature flag in this case is controlled experimentation and phased rollout. By enabling the flag for only a small percentage of users initially, the team can carefully monitor performance, stability, and error rates *before* fully switching all users to the new payment gateway. This dramatically reduces the risk associated with deploying a potentially problematic change to everyone.
8 / 10
During a standup meeting, David (Engineering Lead) says: 'We're using feature flags to implement our new analytics tracking. Initially, all users are seeing the basic version of the tracking – just page views. We'll enable more detailed events later, once we have confidence in the impact on performance.' What does 'wait for confidence' imply in this context? This refers to a risk-based approach to feature rollout
'Wait for confidence' describes a risk-based approach to feature rollout. It signifies that the team isn't just passively waiting; they're actively monitoring key metrics (likely performance impact and user behavior) to gauge whether enabling more detailed tracking is safe and won't negatively affect the user experience or system stability. This contrasts with simply 'waiting for approval.'
9 / 10
A code review comment reads: 'The `enable_dark_mode` flag is set based on user preference, but the UI components are not yet styled to reflect dark mode. We need to ensure that enabling the flag doesn't result in a broken or confusing user experience.' What is the primary concern highlighted in this comment? This indicates a potential mismatch between flag activation and UI readiness
This comment focuses on the crucial aspect of ensuring UI readiness alongside feature flag activation. Simply enabling the `enable_dark_mode` flag doesn't automatically update the UI components to reflect dark mode styling. The concern is that activating the flag without corresponding UI changes could lead to a broken or confusing user experience – a common pitfall when managing dynamic features.
10 / 10
In a PR description for a new feature, Alex (Engineer) writes: 'We're using a feature flag to control access to the premium analytics dashboard. Initially, only beta users can see it. This allows us to gather feedback and iterate on the design before releasing it to all customers.' What is the primary purpose of using this approach? This describes a technique for early user testing and iterative refinement
The core purpose here is controlled experimentation and iterative refinement. By limiting access to the premium analytics dashboard initially to only beta users, Alex can collect valuable feedback on the design *before* making it available to all customers. This allows for rapid iteration and ensures a smoother release process.
These modules build the same on-the-job skills as Feature Flags Vocabulary
— work through them together for a fuller vocabulary set.
Feature Flag Lifecycle— useful for Feature flags & parallel development (Full-Stack Developer)
Frequently Asked Questions
What does the "Feature Flags Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to feature flags vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.