Question 1

What is a feature flag?

Accepted Answer

A **feature flag** (or feature toggle) is a conditional in code allowing behaviour to be changed **without deploying new code**. The feature exists in the deployed application, and a configuration value decides whether it runs.

**Why they are used:**

**Decoupling deployment from release.** This is the central benefit. Code can be merged and deployed continuously while remaining invisible, then enabled when ready. It removes the pressure to hold long-lived branches, which are the source of painful merges.

**Trunk-based development** depends on this — merging incomplete work behind a flag rather than maintaining a separate branch for weeks.

**Gradual rollout.** Enable for 1% of users, watch the metrics and errors, then 10%, then everyone. This limits the blast radius of a problem enormously.

**Instant rollback.** Turning a flag off is far faster and safer than reverting a deployment, and it can be done by someone who is not deploying.

**A/B testing and experimentation**, serving different behaviour to different cohorts.

**Targeted access** — beta users, internal staff, specific customers, or a single account for debugging.

**Operational kill switches**, disabling an expensive feature under load.

**The types matter**, because they have different lifespans:

**Release toggles** — short-lived, removed once the feature ships.

**Experiment toggles** — removed when the experiment concludes.

**Ops toggles** — long-lived kill switches, deliberately permanent.

**Permission toggles** — effectively part of the product, controlling entitlements.

**The main cost is complexity.** Every flag doubles the number of code paths, and flags interact combinatorially. A codebase with dozens of stale flags becomes genuinely difficult to reason about and to test, since no test run covers every combination.

**The discipline that makes it work:** treat release flags as **temporary by default**, record an owner and a removal date, and schedule cleanup. Flag debt is real and accumulates silently.

Question 2

What is trunk-based development?

Accepted Answer

A branching strategy where everyone commits to a single shared branch frequently — at least daily — with short-lived branches lasting hours rather than weeks. It is the practice most strongly

Question 3

What is CI/CD actually doing?

Accepted Answer

Continuous integration verifies that changes work together, continuously; continuous delivery keeps the software always in a releasable state; continuous deployment goes further and releases

Question 4

What is infrastructure as code?

Accepted Answer

Defining servers, networks, databases and everything else supporting an application in files that are version-controlled and executed, rather than configuring them by hand through a console or by

Question 5

What is the difference between rolling back and rolling forward?

Accepted Answer

Reverting to the previous version versus fixing forward with a new release — and which is appropriate depends on factors that are worth deciding before an incident rather than during one. Rollback.

Question 6

When should I use git rebase instead of git merge?

Accepted Answer

Both commands integrate work from one branch into another, and they differ in what happens to history. Merge records that two lines of development came together, creating a merge commit with two

Question 7

Why does documentation always go out of date?

Accepted Answer

Because documentation and the code it describes are coupled in meaning but decoupled in enforcement — nothing breaks when they diverge, so they diverge. The core mechanism. Code has a merciless

Related Questions