# Feature flag

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/feature-flag

## Quick definition

A feature flag is like a light switch for a new feature in your app. It lets developers hide or show a feature to users without needing to update the entire app. This makes it safer to test new ideas and gradually roll them out.

## Simple meaning

Imagine you are building a house and you want to try a new type of smart lock on the front door. Instead of installing it permanently and then having to tear it out if it doesn't work, you put it in with a switch. You can turn the smart lock on for a few days, see if your family likes it, and then decide to keep it or remove it. That switch is like a feature flag in software.

In the world of IT and software development, a feature flag is a simple on/off toggle embedded in the code. Developers use it to control whether a new feature is visible or active for users. For example, a social media app might add a new 'dark mode' feature but only turn it on for 10% of users first. If those users love it and report no bugs, the company flips the flag to 'on' for everyone. If something goes wrong, they flip it back to 'off' instantly, without needing to write new code or stop the app.

Feature flags are important because they let teams test features in real-world conditions with real users, but with a safety net. They also allow for 'canary releases' where new code is tested on a small group before a full rollout. This reduces the risk of a bug affecting everyone at once. In essence, feature flags give developers a remote control for their software, making updates safer and faster.

## Technical definition

A feature flag, also known as a feature toggle, is a software configuration mechanism that enables or disables specific functionality at runtime without deploying new code. It works by wrapping code blocks in conditional statements that check a flag's state, which is often stored in an external configuration service or a database.

Technically, feature flags can be implemented in several ways. The simplest is a hardcoded boolean variable in the codebase, but modern systems use dedicated feature flag management platforms like LaunchDarkly, Split, or Flagr. These platforms provide a centralized dashboard for toggling flags, targeting specific user segments, and monitoring flag usage in real-time.

From an infrastructure perspective, feature flags can be stored in configuration files, environment variables, or distributed key-value stores like etcd or Consul. When a service starts, it reads the flag's state and caches it locally. Changes to a flag trigger a webhook or a polling mechanism that updates the cache without restarting the service. This is critical for high-availability systems where restarts are costly.

For exam accuracy, candidates should understand that feature flags are not the same as feature branches in version control. Feature branches isolate code changes until merge, while feature flags keep code in the main branch but hidden. This technique supports continuous delivery and trunk-based development, both of which are tested in IT certifications like AWS DevOps Engineer or Azure DevOps Solutions.

Security considerations are also important. Feature flags can expose unpublished features to unauthorized users if not properly scoped. Therefore, flags must be integrated with authentication and authorization systems. Stale flags should be removed to avoid technical debt. Tools like 'flipt' or custom scripts can audit flag usage and flag unused ones for cleanup.

Performance overhead is minimal but exists. Each flag check adds a conditional branch and a call to a configuration service or cache. In latency-sensitive systems, developers may batch flag evaluations or use client-side SDKs with local caching. Monitoring tools should track flag evaluation frequency to detect misconfigurations that could degrade performance.

## Real-life example

Think about flying an airplane. When a new navigation system is installed, the pilots and engineers don't just switch it on for every flight right away. They first enable it for a few test flights, maybe only for the co-pilot's display. If the system works well, they gradually turn it on for more flights and more screens. If there is a glitch, they can quickly turn it off, and the plane still runs on the old system. This controlled rollout is exactly how feature flags work in software.

In this analogy, the airplane's cockpit is the software application. The new navigation system is the new feature. The switch that allows engineers to enable or disable the system on specific screens or during specific flights is the feature flag. The engineers can monitor the system's performance, gather feedback from pilots, and decide to make it permanent or scrap it, all without changing the airplane's wiring or performing a maintenance overhaul.

Mapping this back to IT: the airplane is your web app or mobile app. The new navigation system is a feature like a new checkout flow. The feature flag is the configuration that lets you turn that checkout flow on for 5% of users first. If the data shows it improves sales, you turn it to 100%. If it causes crashes, you turn it off immediately. This approach minimizes risk and allows for data-driven decisions, just like the careful testing of new aviation equipment.

## Why it matters

Feature flags matter in IT because they fundamentally change how software is delivered and managed. In traditional development, a new feature meant a big release, often with downtime and high risk. With feature flags, teams can deploy code continuously and toggle features on or off dynamically. This aligns with DevOps principles of agility and safety.

For IT professionals, understanding feature flags is essential for implementing continuous delivery pipelines. They allow teams to separate 'deploy' from 'release'. Code can be deployed to production at any time, but features remain hidden until they are ready. This reduces the pressure of coordinating release dates and minimizes the impact of bad code.

From an operational perspective, feature flags provide a quick kill switch. If a new feature causes a performance degradation or a security vulnerability, engineers can disable it instantly without rolling back the entire deployment. This is especially important in cloud environments where auto-scaling and distributed systems make rollbacks complex.

Feature flags also enable A/B testing and gradual rollouts, which are key strategies for validating features with real user data. For example, a platform like Netflix uses feature flags to test different recommendation algorithms with small user groups. This data-driven approach improves the product while limiting exposure to bugs.

Finally, feature flags help manage technical debt by encouraging code modularity. When a feature is behind a flag, developers must write clean, isolated code that can be toggled. This leads to better architecture and makes it easier to retire features later. Feature flags are not just a development tool but a strategic asset for IT operations and product management.

## Why it matters in exams

Feature flags are a recurring topic in several IT certification exams, especially those focused on DevOps, cloud architecture, and agile methodologies. For example, in the AWS Certified DevOps Engineer – Professional exam, feature flags are relevant to the 'Continuous Integration and Continuous Delivery' domain. Candidates may be asked how to implement progressive rollouts using tools like AWS CodeDeploy or how to use feature flags with AWS AppConfig to toggle features in production.

In the Azure DevOps Solutions exam (AZ-400), feature flags appear in the context of 'Design a release strategy' and 'Manage security and compliance'. Questions often involve using Azure App Configuration or Feature Management libraries to control feature availability across environments. Candidates should know how to use feature flags to enable 'ring-based deployment' or 'canary releases'.

The Certified Kubernetes Administrator (CKA) exam may touch on feature flags indirectly through ConfigMaps or custom resources that toggled features. However, it is more directly tested in the Certified Kubernetes Application Developer (CKAD) exam, where understanding how to expose new functionalities via environment variables or ConfigMaps is expected.

For general IT certifications like CompTIA IT Fundamentals or A+, feature flags are less central but can appear in the context of system configurations and user settings. For example, an A+ question might describe a scenario where a new feature is hidden by default and ask how to enable it-this mirrors the concept of feature flags.

In exam questions, the focus is often on the benefits, risks, and implementation patterns. Common question types include: 'Which strategy allows you to test a feature with a subset of users without deploying new code?' (answer: feature flags/feature toggles). Or 'What is the primary advantage of using feature flags?' (answer: decoupling deployment from release). Candidates should also understand the trade-offs, such as the risk of code complexity and the need for flag cleanup.

## How it appears in exam questions

Feature flag questions in IT certification exams appear in several patterns. One common pattern is scenario-based questions where a development team wants to release a new feature but is unsure of its stability. The candidate must select the technique that allows incremental release with rollback capability. The answer is usually feature flags or canary releases, often linked together.

Another pattern is configuration-based. For example, an exam might describe a situation where a production system is crashing due to a new feature, and ask how to disable it without downtime. The correct approach is to toggle the feature flag off. Distractors might include rolling back the code, restarting the service, or reverting the database schema.

Troubleshooting scenarios also appear. For instance, a candidate might be told that a feature flag was turned on but users still cannot see the new feature. The question might ask why: possible reasons include caching, incorrect flag scope, or the flag not being refreshed. The candidate must identify that the flag value is cached and needs to be reloaded, or that the flag is only enabled for certain user segments.

In more advanced exams like the AWS DevOps Engineer, questions can involve integration with other services. For example: 'You are using AWS AppConfig to manage feature flags. How do you ensure that flag changes are applied without restarting the EC2 instances?' The answer would involve configuring the AppConfig agent to poll for updates and apply them dynamically.

Finally, some questions test the conceptual understanding of feature flags versus feature branches. A question might ask: 'Which approach allows you to merge code to the main branch while keeping a feature hidden until it is ready?' The answer is feature flags, whereas feature branches would keep the code separate from the main branch until merge. Understanding this distinction is key for agile and DevOps exams.

## Example scenario

Consider a scenario from the AWS Certified Solutions Architect exam context. A company has a web application running on EC2 instances behind an Application Load Balancer. The development team has built a new payment gateway feature that they want to test with 5% of users before full release. The company uses AWS CodeDeploy for deployments and wants to avoid redeploying the entire application each time they adjust the percentage.

The solution is to implement a feature flag. The team integrates the new payment code into the main branch, but wraps it in a condition that checks a flag stored in AWS AppConfig. They create a configuration in AppConfig with a flag named 'new_payment_gateway' set to false. They then write a Lambda function that updates the AppConfig configuration to set the flag to true for 5% of users based on user ID hash. The application code uses the AppConfig agent to fetch the flag value every 30 seconds.

During the test, the team monitors error rates and transaction times. After a week, the data shows the new gateway is faster and has fewer errors. The team updates the AppConfig configuration to set the flag to true for 100% of users. If issues had arisen, they would have set the flag back to false immediately. This scenario demonstrates the practical use of feature flags for safe, data-driven rollouts in a cloud environment, exactly as tested in AWS certifications.

## Common mistakes

- **Mistake:** Confusing feature flags with feature branches in version control.
  - Why it is wrong: Feature branches isolate code changes in separate branches until merge, while feature flags keep code in the main branch but hidden. Feature flags allow continuous integration while feature branches delay it.
  - Fix: Remember that feature flags enable 'trunk-based development' where code is merged frequently but hidden behind a toggle.
- **Mistake:** Believing feature flags are only for hiding features before release.
  - Why it is wrong: Feature flags are also used for gradual rollouts, A/B testing, kill switches, and even for enabling premium features for paying customers after release.
  - Fix: Think of feature flags as a flexible configuration tool, not just a 'hide until ready' switch.
- **Mistake:** Assuming feature flags have no performance impact.
  - Why it is wrong: Each flag check adds a conditional branch and typically a call to an external configuration service or cache. In high-traffic systems, many flags checked on every request can increase latency.
  - Fix: Use local caching of flag values and batch evaluations to minimize performance overhead.
- **Mistake:** Leaving stale feature flags in the codebase indefinitely.
  - Why it is wrong: Stale flags add code complexity and can cause confusion or bugs. Eventually, they must be removed to keep the code clean and maintainable.
  - Fix: Establish a process to audit and remove flags after the feature is fully rolled out and stable.
- **Mistake:** Thinking feature flags are only for frontend features.
  - Why it is wrong: Feature flags can be used anywhere in the stack, including backend services, database queries, or infrastructure configurations.
  - Fix: Implement feature flags at appropriate layers: UI, API, or backend logic depending on the feature.

## Exam trap

{"trap":"In an exam question, you might be asked which technique allows you to deploy code to production but not make it available to users. The trap is that some candidates might choose 'feature branch' or 'version control tag' instead of 'feature flag'.","why_learners_choose_it":"Many learners mistakenly think that if code is in a feature branch, it is not in production. But feature branches are separate branches and are not deployed to production unless merged. Feature flags allow the code to be in production but hidden.","how_to_avoid_it":"Focus on the phrase 'deploy code to production but not available to users.' That describes exactly what feature flags do. Feature branches don't deploy to production until merged, so they don't fit the scenario."}

## Commonly confused with

- **Feature flag vs Feature branch:** A feature branch is a separate branch in version control where developers work on a new feature. The code is not merged into the main branch until it is complete. In contrast, a feature flag allows the code to be merged into the main branch but hidden from users until toggled on. (Example: If you create a branch called 'dark-mode' and merge it only after testing, that's a feature branch. If you merge the dark mode code into main but hide it behind a feature flag, you can test it gradually.)
- **Feature flag vs Canary release:** A canary release is a deployment strategy where a new version is released to a small subset of users first. Feature flags are often used to implement canary releases, but they are not the same. Canary releases involve routing traffic to a new version, while feature flags control feature logic within the same version. (Example: Deploy v2 of an app to 5% of servers is a canary release. Using a feature flag to turn on a new payment method for 5% of users is feature flagging.)
- **Feature flag vs A/B testing:** A/B testing compares two versions of a feature to see which performs better. Feature flags can enable A/B testing by toggling different code paths for user segments. However, A/B testing is a method of experimentation, while feature flags are the mechanism to control which users see which version. (Example: To test two button colors, you can have a feature flag that shows color A to half the users and color B to the other half. The flag is the tool; A/B testing is the experiment design.)
- **Feature flag vs Configuration toggle:** Configuration toggles are broader than feature flags; they can control any setting like database connection strings or logging levels. Feature flags are a subset of configuration toggles specifically for controlling feature availability. (Example: A configuration toggle might set the log level to DEBUG. A feature flag enables or disables a new search bar.)

## Step-by-step breakdown

1. **Identify the feature** — The team decides which new feature will be controlled by a flag. It should be a self-contained piece of functionality that can be toggled on/off independently.
2. **Wrap the code in a conditional** — The developer writes the new code inside an if statement that checks the flag's value. If the flag is true, the feature runs; if false, it is skipped or runs the old code.
3. **Define the flag in a configuration system** — The flag is stored in a centralized place like a config file, environment variable, or a dedicated feature flag service. This allows dynamic changes without code deployment.
4. **Deploy the code to production** — The code with the new feature is deployed to all servers, but the feature remains off by default (flag set to false) so users don't see it yet.
5. **Enable the flag for a small group** — Using the configuration system, the team sets the flag to true for a specific user segment (e.g., internal testers or 5% of users). This is the gradual rollout phase.
6. **Monitor and assess** — The team monitors metrics like error rates, response times, user feedback, and click-through rates to ensure the feature works as expected without negative impact.
7. **Roll out to all users or disable** — If the feature works well, the flag is set to true for all users. If issues are found, the flag is set to false immediately, disabling the feature for everyone. This is the kill switch benefit.
8. **Remove the flag** — Once the feature is fully rolled out and stable, the flag and the old code path are removed from the codebase to reduce complexity. This step is often forgotten but is critical.

## Practical mini-lesson

Feature flags are a powerful tool, but they require thoughtful implementation to avoid common pitfalls. In practice, a feature flag system involves three main components: the flag storage, the flag evaluation logic, and the user targeting rules.

First, flag storage can be as simple as an environment variable or as sophisticated as a cloud service like LaunchDarkly. For exam context, AWS AppConfig is a popular choice because it integrates with EC2, Lambda, and ECS. AppConfig allows you to create configurations that can be updated dynamically and automatically applied to your running applications. The key is that the application must be written to check the flag value at runtime, not at build time.

Second, the evaluation logic must be efficient. In high-traffic applications, making a network call for every flag check would be too slow. Therefore, most SDKs cache flag values locally and update them asynchronously when changes occur. This is known as a 'pull' or 'push' model. In a pull model, the application polls the config service periodically. In a push model, the config service sends updates to the application via webhooks or a streaming connection.

Third, targeting rules determine which users see the feature. For example, you might want to enable the feature for users with a specific email domain (internal testers) or a random 10% of users based on user ID hash. These rules are defined in the feature flag management tool and evaluated at runtime.

What can go wrong? One common issue is that flag changes do not propagate to all instances immediately due to caching. This can lead to inconsistent user experiences. Another issue is flag explosion-having too many flags that become unmanageable. Teams should have a policy to clean up old flags. Also, security risks arise if flags are exposed to the client-side; malicious users could inspect network requests and toggle flags themselves. Therefore, sensitive flags should be evaluated server-side only.

Professionals should also be aware of flag debt: the accumulated cost of keeping old flags in the code. This adds cognitive load and can introduce bugs if the flag condition is accidentally left on or off. Tools like 'flipp' or custom CI pipeline checks can help identify flags that can be removed.

feature flags are a best practice for modern DevOps, but they require discipline. Plan your flag lifecycle, use a robust configuration service, enforce server-side evaluation for security, and regularly prune old flags.

## Memory tip

Think 'Feature Flag = Light Switch for Code', you can turn features on/off without rewiring (deploying).

## FAQ

**What is the difference between a feature flag and a configuration toggle?**

A configuration toggle controls any setting like database connections or logging. A feature flag is a specific type of configuration toggle that controls whether a feature is visible or active. All feature flags are configuration toggles, but not all configuration toggles are feature flags.

**Can feature flags be used for security-sensitive features?**

Yes, but they must be evaluated server-side to prevent manipulation by clients. For example, a feature that controls access to admin functions should only be checked on the server, not transmitted to the user's browser.

**How do feature flags affect testing?**

Feature flags introduce the need for testing both states: flag on and flag off. Test suites should cover both paths, and integration tests should verify that flag changes propagate correctly across all services.

**What is the risk of having too many feature flags?**

Too many flags can lead to 'flag explosion,' making the codebase complex and hard to maintain. It also increases the cognitive load on developers and can cause performance issues if every flag requires a network call. Regular cleanup is essential.

**Are feature flags only for frontend features?**

No. Feature flags can be used at any layer: frontend, backend API, database queries, or even infrastructure decisions like which service to call. They are a general mechanism for runtime feature control.

**Do feature flags replace feature branches?**

They are complementary. Feature flags allow trunk-based development where code is merged early but hidden. Feature branches isolate code before it's ready. Many teams use both: feature branches for initial work and feature flags for safe rollout after merge.

## Summary

A feature flag is a runtime toggle that allows developers to enable or disable features without deploying new code. This simple concept has profound implications for software delivery, enabling continuous deployment, gradual rollouts, A/B testing, and instant kill switches. For IT professionals and exam candidates, understanding feature flags is essential for modern DevOps practices.

Feature flags decouple deployment from release, allowing code to be in production but hidden until validated. They reduce risk, improve agility, and support data-driven feature launches. However, they also introduce complexity if not managed carefully-stale flags can accumulate, performance can degrade, and security issues can arise if misapplied.

In certification exams, feature flags appear in scenarios about safe deployment strategies, release management, and configuration management. Key associated terms include canary releases, A/B testing, and trunk-based development. The fundamental exam takeaway is that feature flags enable safe, incremental feature delivery, and they are a key tool in the DevOps toolkit.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/feature-flag