Environment Variables

Environment variables provide externalized configuration that can vary between deployment environments. They let an application read values such as ports, database URLs, and feature settings without hard-coding those values into source code.

An environment variable is a key-value setting supplied by the operating environment to a running process. In Java, values can be read with `System.getenv("NAME")`, returning a `String` or `null` when the variable is absent.

Externalizing configuration separates application code from environment-specific values. For example, development, staging, and production can use different database endpoints while running the same application artifact.

Environment variables are useful for deployment configuration and can reduce the need to commit environment-specific settings to source control. However, they are not automatically a complete secret-management solution; sensitive values should be protected according to the deployment platform's security model.

In production Java applications, environment variables are often consumed directly or mapped into a configuration framework such as Spring Boot configuration. A robust application should define sensible defaults where appropriate and fail clearly when a required setting is missing.

Key points

• Read variables in Java with `System.getenv()`.
• Keep environment-specific configuration outside application code.
• Do not assume an environment variable is present; handle `null` or validate required settings.
• Environment variables can configure ports, URLs, credentials, and feature settings.
• Use a dedicated secret-management mechanism when stronger secret protection is required.

Interview questions

What are environment variables, and why would a Java application use them?

Environment variables are key-value settings supplied by the operating environment to a process. A Java application can read them with `System.getenv()`. They are useful when the same application must run with different configuration in development, staging, and production. This keeps environment-specific values out of application code.

How would you handle a required environment variable in Java?

I would read the value and validate that it exists before starting functionality that depends on it. If the value is required, startup should fail with a clear configuration error rather than allowing a later operation to fail mysteriously. For optional settings, I can provide a documented default. Sensitive values should also be kept out of logs and error messages.

What is the difference between an environment variable and a Java system property?

An environment variable belongs to the operating system process environment and is accessed with `System.getenv()`. A Java system property belongs to the JVM's system properties and is accessed with `System.getProperty()`. System properties are commonly supplied with JVM arguments such as `-Dapp.mode=test`. They are related configuration mechanisms but are not interchangeable APIs.

Are environment variables safe for storing secrets?

Environment variables can be used to inject secrets into an application, but they should not automatically be considered secure secret storage. Their security depends on how the deployment platform stores, exposes, and protects the process environment. Secrets should not be committed to source control or printed in logs. For higher security requirements, a dedicated secrets-management service is often preferable.

How can environment variables be used to control a feature flag?

A feature flag can be represented by an environment variable such as `FEATURE_X_ENABLED=true`. The application reads and parses that value during startup or configuration loading, then uses it to select the appropriate behavior. This is useful for deployment-specific switches, but environment variables alone do not provide advanced feature-flag capabilities such as gradual rollout or per-user targeting. Those requirements may justify a dedicated feature-flag system.