Q149: Runtime Configuration, Feature Flags and Environment Data

What Interviewers Want To Evaluate

This question checks whether you understand configuration as runtime data. Interviewers want build-time vs runtime config, public vs secret values, feature flags, environment variables, validation, caching, rollout safety, and frontend security boundaries.

Senior answers should connect configuration to deployments, experiments, rollback, and user-specific behavior.

Short Interview Answer

Runtime configuration controls app behavior without changing code. Frontend config must be treated as public because users can inspect shipped JavaScript. Secrets must stay on the server. Feature flags are a form of runtime config used for rollout, experiments, kill switches, and permissions. Good systems validate config, define defaults, track ownership, avoid stale values, and make flag behavior observable.

Detailed Interview Answer

Configuration answers:

which API endpoint should this app use?
is this feature enabled?
which experiment variant applies?
what tenant settings are active?
what limits should the UI enforce?

Bad configuration can break production as quickly as bad code.

Build-Time Config

Build-time config is baked into the JavaScript bundle.

In many frameworks, public environment variables are replaced during build.

This means changing the value may require a rebuild and redeploy.

Use build-time config for values that truly belong to the artifact.

Runtime Config

Runtime config is loaded when the app runs.

Examples:

config endpoint
edge config
server-rendered bootstrap data
tenant settings
feature flag service

Runtime config supports faster changes but needs loading, caching, validation, and fallback behavior.

Public vs Secret

Frontend JavaScript is inspectable.

Never put secrets in client-side config.

Examples of secrets:

private API keys
database URLs
service credentials
signing secrets
admin tokens

Public identifiers may be okay, but they should still be scoped and monitored.

Feature Flags

Feature flags control behavior dynamically.

Use cases:

progressive rollout
A/B experiments
tenant-specific access
kill switches
beta programs
permissioned features
migration safety

Flags should have owners and cleanup plans.

Flag Evaluation

Flags may be evaluated:

server-side
client-side
edge-side
per request
per user
per tenant
per session

Server-side evaluation protects sensitive rules better. Client-side flags are visible and should not enforce real authorization.

Defaults and Validation

Config should be validated before use.

function normalizeConfig(raw) {
  return {
    apiBaseUrl: typeof raw.apiBaseUrl === "string" ? raw.apiBaseUrl : "/api",
    enableNewSearch: raw.enableNewSearch === true,
  };
}

Bad config should fail safe where possible.

Staleness

Runtime config can become stale.

Questions to define:

how long is config cached?
how are updates delivered?
what happens offline?
does a user keep the same experiment variant?
how are rollbacks applied?

Flag consistency matters for user experience and analytics.

Observability

Log or tag important flag context in monitoring.

Useful data:

feature name
variant
tenant
release
config version
evaluation source

This helps debug issues that affect only flagged users.

Common Mistakes

A common mistake is using client-side flags as authorization.

Another mistake is leaving old flags forever.

Another mistake is changing config without validation or rollback plan.

Senior Trade-Offs

Runtime config increases flexibility but adds distributed-state complexity.

Use it for behavior that truly needs runtime control. Keep stable build constants in code or build config.

Document ownership because forgotten flags become technical debt.

Code or Design Example

function canShowBillingPage(user, flags) {
  return user.permissions.includes("billing:read") && flags.enableBillingPage;
}

The flag controls rollout. The permission still controls access.

Debugging Workflow

When config-driven behavior is wrong:

check release version
check config version
check flag owner and rule
check user or tenant targeting
check client vs server evaluation
check stale cache
check default fallback
check monitoring tags

Interview Framing

Explain build-time vs runtime config, then public vs secret values, feature flags, validation, rollout, and observability.

Revision Notes

Runtime config is powerful because it changes behavior outside deployments, but it must be validated and observable.

Key Takeaways

Feature flags and config are production control systems. Treat them with the same care as code.

Follow-Up Questions

1. What is runtime configuration?
2. How does build-time config differ?
3. Why are frontend secrets unsafe?
4. What are feature flags used for?
5. Why should client flags not enforce authorization?
6. What config should be validated?
7. How can config become stale?
8. Why do flags need owners?
9. What monitoring context helps debug flags?
10. When should a flag be removed?

How I Would Answer This In A Real Interview

I would separate build-time config from runtime config, then say all frontend config is public. I would describe feature flags for rollout and kill switches, but permissions still need server enforcement. I would close with validation, defaults, observability, and flag cleanup.