What are Feature Toggles (Feature Flags)?
Learn what feature toggles (feature flags) are, the four toggle types, and how they decouple deployment from release — with a DevOps interview answer.
Expected Interview Answer
A feature toggle, also called a feature flag, is a runtime conditional that lets a team turn a piece of functionality on or off without deploying new code, decoupling code deployment from feature release.
Instead of shipping a feature straight to every user the moment it merges, the code path is wrapped in an “if flag enabled” check that reads its state from a config service, database, or flag-management platform at runtime. This lets teams merge unfinished work behind a flag that stays off in production (trunk-based development), release to a specific cohort for a canary or A/B test, and instantly kill a broken feature by flipping the flag rather than rolling back a deploy. Flags are typically categorized as release toggles (short-lived, hide work-in-progress), experiment toggles (A/B testing), ops toggles (kill switches for load shedding), and permission toggles (entitlements per plan or user). Because stale flags accumulate technical debt and dead branches, mature teams track flag ownership and expiry and delete them once a rollout is complete.
- Decouples deployment from release, reducing deploy risk
- Enables instant kill switches without a redeploy or rollback
- Supports trunk-based development with unfinished code merged safely off
- Enables targeted rollouts, canaries, and A/B experiments
AI Mentor Explanation
A feature toggle is like a coach who has a new batting technique fully drilled into a player during practice but keeps a discreet hand signal that says “not yet” for match day. The technique exists in the player's muscle memory already, merged into their game, but only the coach's live signal decides whether it appears in the actual innings. If the technique looks risky mid-series, the coach can withhold the signal for the next match instantly, without retraining the player from scratch. The playbook is always ready; the flag is just the switch controlling when it goes live.
Step-by-Step Explanation
Step 1
Wrap the code path
Guard the new logic behind an if-flag-enabled check rather than shipping it unconditionally.
Step 2
Configure the flag source
Store flag state in a config service, database, or a dedicated flag-management platform read at runtime.
Step 3
Target a rollout
Enable the flag for internal users, a percentage cohort, or a specific segment before a full release.
Step 4
Retire the flag
Once the rollout is complete and stable, remove the flag and the old code path to avoid technical debt.
What Interviewer Expects
- Understanding that toggles decouple deployment from release
- Knowledge of toggle categories: release, experiment, ops, permission
- Awareness of flag debt and the need to retire stale flags
- Ability to explain a kill-switch use case for incident response
Common Mistakes
- Never removing toggles, causing an unmanageable tangle of dead branches
- Treating a feature toggle system as a substitute for proper testing
- Hardcoding flag values instead of reading them from a config source
- Forgetting that combinatorial flag states need their own test coverage
Best Answer (HR Friendly)
“Feature toggles let us hide a new feature behind a switch we control in production, so merging code and actually turning a feature on for users become two separate decisions. That means we can ship code safely and continuously, then release the feature to a small group first, and instantly turn it off if something goes wrong, without needing an emergency rollback.”
Code Example
# Pseudo-code pattern for a flag-gated code path
if flag_client.is_enabled("new-checkout-flow", user_id=current_user.id):
render_new_checkout()
else:
render_legacy_checkout()
# Enable the flag for 10% of users via CLI
flagctl set new-checkout-flow --rollout=10percent
# Instant kill switch during an incident
flagctl set new-checkout-flow --rollout=0percentFollow-up Questions
- How would you prevent feature-flag debt from accumulating over time?
- What is the difference between a release toggle and an ops toggle?
- How do you test a system with many combinable feature flags?
- How would you use a feature toggle as part of an incident-response plan?
MCQ Practice
1. What is the primary purpose of a feature toggle?
Feature toggles let teams deploy code continuously while controlling, separately and at runtime, when a feature is actually exposed to users.
2. Which toggle category acts as an emergency kill switch?
Ops toggles are designed to be flipped quickly during incidents to disable a feature or shed load without a redeploy.
3. What is a key risk of long-lived, un-retired feature toggles?
Stale flags left in code create technical debt, unnecessary branching, and a growing matrix of states that becomes hard to test and reason about.
Flash Cards
What is a feature toggle? — A runtime switch that turns a code path on or off without a new deployment.
What does a toggle decouple? — Code deployment from feature release.
Name the four common toggle types. — Release, experiment, ops, and permission toggles.
Why must toggles be retired? — To avoid flag debt — dead code paths and untested combinatorial states.