Feature Flag Platform Engineer Interview Questions

Option B is strongest because local evaluation against a background-synced cache with explicit safe defaults removes the flag service from the synchronous request path entirely, with staleness and fallback usage tracked as observable metrics. Option A makes the flag service a hard dependency for every request, exactly the single point of failure the question asks to avoid. Option C avoids the network call but risks serving indefinitely stale, potentially unsafe flag values with no visibility into how stale the cache actually is. Option D turns a transient flag-service outage into a full platform outage by blocking service startup entirely.

Option B is strongest because it builds lifecycle tracking, staleness alerting, and low-friction automated cleanup tooling into the platform itself, addressing the root cause of flag accumulation rather than relying on individual memory. Option A is the status quo that predictably leads to the exact accumulation problem the question describes. Option C removes the ownership and classification data needed to know which flags are safe to clean up and which are permanent by design. Option D is dangerous, since deleting a flag that is mid-rollout or a permanent kill-switch on a fixed timer regardless of its actual state can break production behavior.

Option B is strongest because it closes the actual correlation gap by tagging every request with active flag state and automating cohort-based health comparison during rollouts, turning a slow manual investigation into a fast automated alert. Option A reduces blast radius somewhat but does nothing to fix the underlying correlation and detection gap, so the same slow diagnosis would recur. Option C removes gradual rollout, which is a valuable risk-mitigation tool, rather than fixing the actual detection tooling gap. Option D provides only a toggle history with no way to connect flag state to the specific requests or errors affected, which is exactly the missing link that caused the multi-hour delay.

Option B is strongest because it prevents contradictory states structurally, through validated dependency and mutual-exclusion declarations and multivariate flag modeling, and gives engineers visibility into related flags before creating overlap. Option A relies on individual memory across a large, evolving flag inventory, which does not scale and is exactly how contradictory states arise. Option C resolves conflicts silently and arbitrarily at runtime, which can produce confusing, hard-to-debug behavior with no warning that a conflict even occurred. Option D is impractical at scale, since collapsing all related behaviors into one global flag removes the ability to roll out, target, or roll back individual features independently, which is the core value of a flag platform.

Option B is strongest because it makes cross-team dependencies visible to the platform and surfaces them specifically at change time for high-blast-radius flags, adding proportional friction only where it is needed rather than uniformly. Option A creates a centralized bottleneck that will not scale and slows down the many low-risk, single-owner flag changes that do not need cross-team coordination. Option C is the status quo that caused the incident, providing no visibility into cross-team dependencies before a change is made. Option D is impractical and would prevent the owning team from ever legitimately evolving or deprecating their own flag, which is not a sustainable policy.