Feature Toggle Scenarios: The Answer, and Why

The answer, and the working behind it

All of the options. The phrase “feature toggle can be used in the following scenarios” comes from Jenkins and continuous integration quiz banks, and the keyed answer covers every scenario listed.

#	Option	Correct?
I	Enhancing an existing feature in an application	✅ Yes
II	Adding a new feature to an application	✅ Yes
III	Disabling or hiding a feature	✅ Yes
IV	None of the options	❌ No
V	All of the options	✅ The answer

Why each of the first three works. Adding a new feature: the toggle guards an unfinished codepath so it ships to production invisible. Enhancing an existing one: the toggle picks between two implementations of the same behaviour, old and new. Disabling or hiding: the toggle is flipped off, either before anyone ever sees the feature or during an incident after they have.

“None of the options” only tempts you if you think a toggle exists solely to ship new things. It doesn’t. The single most consequential production use of a toggle is the opposite direction: turning something off, fast, without a deploy.

Variants of this question float around with java, brain and qui suffixes from different quiz platforms. The option set is identical in each, so the answer key is identical too. And if your version shows only the three scenarios with no “All of the options” line, every individual scenario listed is still correct on its own.

Visual needed: Answer-key callout graphic showing five options for the question “feature toggle can be used in the following scenarios”, with I, II and III ticked, IV crossed, and “All of the options” highlighted

---

What a feature toggle actually is (30-second version)

A feature toggle is a conditional that reads external state at runtime and picks between two codepaths inside the same deployed artifact. That’s the whole mechanism. No branching in version control, no second binary, no separate deploy.

Martin Fowler’s article, written by Pete Hodgson and titled “Feature Toggles (aka Feature Flags)”, states plainly that feature toggles, feature flags, feature bits and feature flippers are synonyms for the same set of techniques (martinfowler.com). Quiz banks and vendor docs use them interchangeably. So should you.

One idea explains every scenario on this page: a toggle decouples deployment (the code is on the server) from release (users can see it). Everything below is a consequence of that split.

The canonical shape:

if (features.isEnabled("new-pricing-engine")) {
    return newPricingEngine.quote(cart);
}
return legacyPricingEngine.quote(cart);

Fowler names the parts: the call site is the Toggle Point, the decision logic behind isEnabled is the Toggle Router, and the state it reads is the Toggle Configuration. When the decision depends on who is asking, the router also consults a Toggle Context — the request, the user, the cookie.

An exam trap worth pre-empting: a toggle is not a branch. Feature branching isolates code in version control; a toggle isolates behaviour at runtime on trunk. Same problem, opposite mechanics. The same quiz bank asks about both, which is why the table near the end of this page covers branching questions too.

---

Why all three quiz scenarios are valid

Adding a new feature

This is Fowler’s release toggle. Incomplete, partially tested code ships to production as latent code that may never be switched on in that deploy. It is what makes trunk-based development survivable: a half-finished checkout redesign merges to master on Tuesday and stays invisible until the team decides otherwise. No long-lived branch, no merge day, no integration drama.

Release toggles are transitionary. Fowler is specific that they should generally not stick around much longer than a week or two.

Enhancing an existing feature

This is the case the competing pages skip past, and it is the one that proves the answer. Here the toggle wraps two implementations of the same behaviour. Fowler’s worked example replaces a Spline Reticulation algorithm with a faster version over several weeks while teammates keep committing to trunk.

The detail that matters: the old implementation is moved into its own named function rather than deleted. That is what makes the toggle reversible. If you delete the old path as you write the new one, the toggle can be flipped off but the system can’t actually go back, and you’ve shipped a deploy wearing a toggle costume.

Disabling or hiding a feature

The quiz collapses two distinct cases into one line.

Hiding is pre-release. The feature works, the code is live, and a product manager doesn’t want it visible until it behaves correctly for every partner. Fowler’s example is an Estimated Shipping Date display held back until it works across all shipping providers.

Disabling is post-release. That’s the kill switch, flipped by an operator mid-incident while the pager is still buzzing.

The same mechanism serves all three because the toggle is indifferent to intent. What separates these scenarios is how long the toggle lives and who flips it, not how it is built.

---

The scenarios the quiz leaves out

Nine more, from production practice.

Canary release. Expose the new codepath to a small random cohort. Fowler’s example samples 1% of users, often by taking a modulo of the user ID, keeping the feature consistently on for that 1% and off for the other 99% while engagement and revenue are compared across the two groups (martinfowler.com).

A/B and multivariate experiments. The toggle router must route a given user down the same path every time for the experiment’s duration, and the configuration must sit unchanged long enough to reach statistical significance. Fowler puts that window at hours to weeks depending on traffic, and warns that holding it longer is unlikely to help because other system changes start invalidating the result.

Dark launch. The new code runs in production and does real work: real queries, real load, real logging. Its output is discarded or hidden. Nobody sees it. That is the clean distinction from canary, where a small number of real users see real output.

Champagne brunch. Fowler’s term for exposing a feature to a specific named set of internal or beta users rather than a randomly sampled percentage. The implementation differs accordingly: the router reads a per-request Toggle Context (a cookie, a header, a user ID in an allowlist) instead of hashing into a bucket.

Ops toggles and load shedding. Long-lived switches that let operators degrade non-vital functionality under pressure. Fowler describes an online retailer that maintained toggles able to intentionally disable non-critical features in its main purchasing flow immediately before a high-demand product launch, and a separate case of disabling an expensive Recommendations panel under heavy load. He frames these as a manually-managed Circuit Breaker.

Permissioning and entitlement toggles. Premium tiers, alpha cohorts, beta programmes. The lifespan outlier: Fowler notes these may live for multiple years, unlike release toggles.

Migration and infrastructure cutovers. Switching reads between an old and new datastore, an API version, or a third-party vendor, with instant failback. Read the “wrong answer” section below before you reach for this one.

Scheduled and time-based toggles. Feature complete, tested, sitting in production, released at 09:00 on campaign day without a deploy window.

AI and model rollouts. The newest entry. LaunchDarkly — and this is a vendor describing its own product category, not an independent finding — describes serving a new recommendation model to 5% of users while the existing model serves 95%, plus kill switches that disable AI features producing biased or unsafe output or exceeding a cost threshold (launchdarkly.com). Treat the mechanism as real and the framing as marketing. See also progressive delivery for LLM features.

Visual needed: Scenario matrix mapping twelve feature toggle scenarios to Fowler category, lifespan, dynamism, who flips it, config mechanism and removal trigger

---

Scenario → toggle category → how to implement it

Fowler organises toggles on two axes: how long the toggle lives and how dynamic the decision must be. Where a scenario sits on those axes tells you how to build it.

Category	Longevity	Dynamism	Who flips it
Release	Transient (days to ~2 weeks)	Static — same answer for every request in a release	Developer
Experiment	Transient (hours to weeks)	Highly dynamic — per user, consistent per user	Data/product
Ops	Mostly short-lived, some indefinite	Dynamic, must reconfigure fast mid-incident	Operator
Permissioning	Very long-lived (years)	Always per-request	Product / entitlements

A transient release toggle can be a bare if/else at the call site and nobody will mind, because it’s gone in a fortnight. A multi-year permissioning toggle must not be, or you end up with entitlement checks sprinkled indiscriminately through the codebase. Fowler’s remedies are to de-couple the Toggle Point from the Toggle Router, apply Inversion of Decision so the core code doesn’t reach out to a flag service, and remove conditionals entirely by injecting strategy implementations at wiring time.

The configuration ladder

Mechanism	Change requires	Good for	Cost
Hardcoded constant	Recompile + deploy	Latent code during development	Useless in production
Parameterised / env var	Restart	Release toggles, per-environment differences	No per-user routing
Config file	Restart or file watch	Release, simple ops	No audit trail
Application database	Admin UI write	Permissioning, per-user state	Adds a read to the hot path
Distributed config service	API call	Ops kill switches, experiments	Network dependency, SDK caching decisions

Fowler’s advice here runs against instinct and deserves its own line: prefer static configuration where you can. Dynamic routing is harder to test, harder to reason about, and harder to reproduce in an incident postmortem.

The testing problem nobody mentions

Feature toggles introduce validation complexity that compounds. With N independent toggles, there are 2^N possible system states. Ten flags is 1,024 combinations. Twenty is 1,048,576. You cannot test them all, and pretending otherwise produces a test suite that takes an hour and still misses the state that breaks.

Fowler’s practical rule: test the codepath you are about to release, and the current production codepath. Toggle-on and toggle-off for the flag under change. Not the full matrix.

Edge or core?

Put the toggle at the edge — in request routing or the presentation layer — when you are hiding a whole UI surface or gating access by entitlement. Put it in the core, next to the behaviour, when the toggle swaps an algorithm rather than a visibility. A pricing engine swap belongs in the pricing module. A premium-only dashboard belongs at the router.

---

When a feature toggle is the wrong answer

Database and schema migrations. A toggle can switch which schema the code reads. It cannot un-write data. Flip a migration toggle off after an hour of dual writes and the old codepath meets rows it has never seen. The real answer is the four-step expand and contract migration: add the new column, write to both, backfill, switch reads (this is where a toggle legitimately helps), then drop the old column in a later deploy once nothing reads it.

Changes that cannot be made reversible. The test is one sentence long. Can you flip it back with no other action? If restoring the old behaviour also requires a data repair, a cache purge or a partner notification, you do not have a kill switch. You have a deploy with extra steps and false confidence.

Long-lived business logic that should be entitlements. If a “toggle” encodes a permanent product tier, it belongs in an entitlements model with RBAC and an audit trail, not in a flag list where a developer with dashboard access can accidentally grant every free user the enterprise plan.

Flag debt. Fowler is explicit that toggles carry ongoing carrying cost and must be actively retired. Two disciplines work: create the removal task at the same moment you create the flag, or cap the number of live toggles so that adding one forces removing one. A flag inventory with expiry dates turns this from intention into process.

Fowler cites Knight Capital Group’s $460 million loss, sustained in 45 minutes of trading on 1 August 2012, as a cautionary tale for what can go wrong when feature flags are not managed correctly — with his own hedge, “amongst other things” (martinfowler.com). Keep the hedge. The flag repurposing was one factor in a failure with several causes, and any page presenting it as the cause is overselling.

One cost that nobody in the current top ten quantifies: a toggle evaluated per request in a hot path adds latency and, if the SDK evaluates remotely, an availability dependency on the flag service. The magnitude depends entirely on SDK design and local caching. This page has not measured it and will not invent a number. Measure it yourself: p99 of the evaluation call in your own service, with your own SDK configuration, and the behaviour when the flag service is unreachable.

Visual needed: Decision tree titled “Should this be a feature toggle?” branching on reversibility, per-user variation, lifespan and who flips it

---

Feature toggle or feature flag? The terminology question, settled

The primary source settles it. The canonical article is titled “Feature Toggles (aka Feature Flags)” and states the terms are synonyms, alongside feature bits and feature flippers (martinfowler.com).

Vendors draw a line anyway. LaunchDarkly positions toggles as a “subset of the broader feature flag ecosystem” and publishes a table splitting toggles (binary, config-file driven, developer-only, temporary) from flags (percentage rollouts, targeting rules, dashboards, RBAC, persistent), and assigns “small teams, 1-10 developers” to toggles versus enterprise to flags (launchdarkly.com). That is a vendor statement, and the split maps almost exactly onto the boundary between what you can build in an afternoon and what you buy. Commercial framing, not an industry definition.

The same page asserts that Martin Fowler’s later writing on feature branching chose “feature flag” over “feature toggle”, signalling a terminology shift. The canonical article is titled with both terms and uses them interchangeably throughout, so the asserted shift does not survive contact with the source.

For the quiz, and in any interview, treat toggle and flag as the same thing. The only room where the distinction earns its keep is a procurement conversation.

---

Implementing a toggle: minimal examples

Four stages, ending in deletion.

1. Hardcoded boolean. Latent code during development. Recompile to change it.

private static final boolean USE_NEW_PRICING = false;

2. A lookup against an injected router. Now the decision leaves the class.

public interface FeatureToggles {
    boolean isEnabled(String name);
}

class PricingService {
    private final FeatureToggles features;
    PricingService(FeatureToggles features) { this.features = features; }

    Money quote(Cart cart) {
        return features.isEnabled("new-pricing-engine")
            ? newQuote(cart)
            : oldFashionedQuote(cart);
    }
}

Injecting the router is what lets a unit test exercise both sides. Pass a stub returning true, assert the new behaviour; pass one returning false, assert the old. That is the toggle-on/toggle-off rule from the testing section, made concrete.

3. Per-request context, with a multivariate return. A/B tests need more than a boolean.

type Variant = "control" | "compact" | "expanded";

function checkoutVariant(ctx: ToggleContext): Variant {
  return router.variant("checkout-layout", ctx.userId) ?? "control";
}

Keying on a stable user ID is what keeps a given user on the same variant for the experiment’s life.

4. Remove the conditional. For a long-lived toggle, select the implementation once at wiring time rather than branching on every call:

PricingEngine engine = config.useNewPricing()
    ? new NewPricingEngine()
    : new LegacyPricingEngine();

Then the cleanup commit, which is four deletions: the old function, the toggle point, the config entry, and the flag record in whatever dashboard or file holds it. Teams routinely do only the last one, which is how you end up with dead code guarded by a flag that no longer exists.

Visual needed: Code-evolution figure showing the same Java pricing function at all four toggle stages, from hardcoded boolean to removal

---

Build or buy: the open-source feature flag landscape

For the three scenarios in the quiz, a config file is genuinely enough. The reasons to adopt a platform are targeting rules, audit trails, and letting non-engineers flip switches without a deploy. Every vendor’s own comparison table puts exactly those on the paid side, which tells you something.

Provenance for the open-source options comes from the projects’ own public launch threads rather than a listicle. All facts as of the thread dates; re-check licences and release versions against each repository before publishing, and date-stamp the table.

Project	Source of truth	Public provenance
Flipt	Non-relational declarative stores including Git, OCI and object storage, per the founder	HN item 41460061, 137 points
GrowthBook	Self-hosted platform, open source	Launch HN (YC W22), 191 points — open-source feature flagging and A/B testing
Dorkly	YAML files in GitHub; speaks the LaunchDarkly SDK protocol; built by a former LaunchDarkly employee	HN item 40796697, 304 points
Unleash, Flagsmith, PostHog, Statsig	Licence and self-host terms differ; read each project’s own repository	—

Three independent projects converged on Git as the flag store. That is the pattern worth naming: flag configuration is increasingly treated as versioned code with review and history built in, not as dashboard state — which addresses the compliance argument vendors make for their own hosted consoles, using a mechanism you already run.

OpenFeature is the vendor-neutral SDK layer, hosted by the CNCF, and it matters mainly for exit cost: instrument once, swap the provider behind it. Its spec status and maturity level move, so read them from the OpenFeature site rather than from any vendor’s characterisation. More on this in vendor-neutral flag SDKs.

One thing deliberately omitted. Flagsmith’s blog carries headlines asserting a $1.1 billion feature-flag acquisition by OpenAI and a LaunchDarkly outage during an AWS incident (flagsmith.com). Those are competitor-published claims about a rival. Without independent primary sourcing they stay out.

Visual needed: Open-source flag tooling provenance table listing project, licence, config source of truth, self-hostability, SDK compatibility and last-reviewed date

---

The rest of the CI quiz, answered

A study aid, not an answer key. Option wording varies by platform, so confirm each against your own course material.

Question (as commonly worded)	Keyed answer	Why
Feature toggle can be used in the following scenarios	All of the options	A runtime conditional is indifferent to whether the codepath is new, changed or withdrawn
Which is NOT true about continuous integration	It involves moving code in large amounts	CI is defined by small, frequent increments integrated many times a day
The developer runs private builds before moving changes to the local version control	False	Private builds precede the push to shared/central version control; “local” is the fumbled word
Is Maven a CI tool?	No	Maven is a build and dependency management tool; Jenkins, TeamCity and Travis CI are the CI servers
Subversion (SVN) is a distributed VCS	False	SVN is centralised; Git is distributed; IBM ClearCase is stream-based
Feature branching is used for	User stories	Quiz-specific framing. The claim that it excludes bug fixes is an answer-key artefact, not engineering fact
Release builds can be triggered by	Event-driven, polling, on-demand	All three are standard Jenkins trigger modes
Build repair rate measures	Time taken to fix a broken build	A team-health metric, not a code metric
Afferent coupling measures	Incoming dependencies	Efferent coupling is the outgoing direction
Cyclomatic complexity determines	The minimum number of test inputs	One independent path per branch
Faster feedback can be received by	Running smaller, faster build stages first	Fail cheap before you fail slow

One correction worth a mark. The widely-copied bank keys “a build can be triggered by a version control tool” as True, and separately keys “version control trigger” as the invalid option in a list of build triggers. Both appear in the same set, unreconciled. The distinction the quiz is fumbling: VCS webhooks absolutely trigger builds, but “version control trigger” is not a named trigger type in Jenkins’ vocabulary. The six named types are poll SCM, webhook, upstream/downstream, parameterised, manual and scheduled. Answer True to the first, and pick “version control trigger” as the invalid name in the second.

Also treat with suspicion any answer asserting that software is deployed to production from the release branch and not master as a universal truth. That contradicts standard trunk-based development, where master is the deployable line. Mark it the way the quiz wants; don’t carry it into an interview.

Full working for the surrounding questions lives in the Jenkins and CI answer bank.

Visual needed: CI quiz bank answer table with question wording, keyed answer and a one-line verified reason for each of the surrounding questions

A note on ‘trunk’: two unrelated things called the same name

Searchers reading about trunk-based development alongside feature toggles frequently land on trunk-rs/trunk, a Rust and WebAssembly build and bundling tool with nothing to do with release management.

Its open issue backlog is Rust compile profile configuration (#605), Web Worker bundling (#46) and wasm-opt build failures on Rust 1.82 (#904). The project is Apache-2.0 licensed (github.com/trunk-rs/trunk). Nothing about feature management.

Search the practice name, “trunk-based development”, not the bare word. And never cite a trunk-rs issue as evidence about feature flags.

---

Frequently Asked Questions

Feature toggle can be used in the following scenarios — what is the answer?

All of the options. Enhancing an existing feature, adding a new feature, and disabling or hiding a feature are all valid uses, because a feature toggle is a runtime conditional that is indifferent to whether the codepath it guards is new, modified, or being withdrawn from users.

How to use a feature toggle?

Wrap the new codepath in a conditional reading a named flag. Keep the old codepath intact in its own function so the toggle is reversible. Supply the value from configuration, starting with an env var or file. Schedule the removal commit when you create the flag. Test both paths.

What is feature toggle management and what is it used for?

Feature toggle management is the practice of tracking every live toggle: who can change it, what it evaluates to per environment, and when it gets deleted. Its purpose is controlling the carrying cost Fowler warns about. The artefacts are a flag inventory, an owner per flag, an expiry date, and an audit log.

Is a feature toggle the same as a feature flag?

Yes, for all practical purposes. The canonical reference is titled “Feature Toggles (aka Feature Flags)” and treats toggle, flag, feature bits and feature flippers as synonyms. Some vendors draw a toggle-versus-platform distinction in comparison tables, but that is commercial positioning rather than an industry definition.

What are the four types of feature toggles?

Release toggles ship unfinished code dark. Experiment toggles route A/B and multivariate cohorts. Ops toggles cover kill switches and load shedding. Permissioning toggles handle premium, alpha and beta entitlements. They differ mainly in lifespan and how dynamic the decision must be, which determines how each should be implemented.

Can a feature toggle be used to turn off a feature?

Yes, and it is the highest-stakes use: the kill switch. An operator disables a misbehaving feature in production in seconds, with no deploy or rollback. The caveat matters. If data has been written that the old codepath cannot read, flipping the flag off is not actually a recovery.

Is feature toggling a CI or CD practice?

Both. Toggles make trunk-based development workable, serving continuous integration by letting unfinished work merge to master daily. They also implement the continuous delivery principle of separating release from deployment. Quiz note: deploying to production is usually keyed as not a CI practice in these banks.

What are the disadvantages of feature toggles?

Four costs. Combinatorial testing burden, since N independent flags produce 2^N states. Code complexity as conditionals spread. Technical debt from flags nobody retires. An added runtime dependency and possible latency when flags are evaluated remotely in a hot path, whose magnitude depends on your SDK and caching and needs measuring locally.

---

How this page was sourced. Every category, lifespan and implementation-pattern claim comes from “Feature Toggles (aka Feature Flags)” by Pete Hodgson on martinfowler.com. Open-source tooling provenance comes from each project’s own public launch thread on Hacker News, linked inline. Vendor statements from LaunchDarkly and Flagsmith are labelled as vendor statements wherever they appear. Volatile figures such as release versions and issue counts should be re-checked before publication. No product on this page has been installed, configured or benchmarked by the author; where an answer requires measurement, such as flag evaluation latency in a request hot path, the page says so and leaves it open. There is no commercial relationship between this publication and any feature flag vendor named here.

The short version: a feature toggle can be used in the following scenarios — all three the quiz lists, plus the nine it never asks about. If you take one operational rule away, make it the reversibility test. A toggle you cannot flip back without a data repair is not a toggle, and the fortnight you give a release toggle before deletion starts the day you merge it.