Configuration Hierarchy and Precedence

Configuration values can originate from several sources, and precedence rules determine which value the application actually uses at runtime. Understanding that resolution order is essential for predictable Java services and safe environment-specific deployments.

A Java application may receive configuration from defaults, configuration files, environment variables, JVM system properties, command-line arguments, or external configuration services. When multiple sources define the same property, the configuration mechanism must apply a defined precedence order to select the effective value.

Precedence is usually designed so that broad defaults are easy to override without changing application code. For example, a checked-in configuration file might provide a development-friendly default while an environment variable supplies the production value. The exact ordering depends on the framework and configuration library, so an interview answer should name the specific system when claiming an exact order.

In Spring Boot, configuration can be supplied through several property sources, with later or higher-priority sources overriding earlier values. Common examples include application property files, environment variables, system properties, and command-line arguments. The important principle is that the final injected value is the result of resolution across these sources, rather than necessarily the value found in one file.

Feature flags follow the same general idea. A flag can have a default value in code or configuration and then be overridden by an environment-specific setting or a remote flag service. Good designs make the source and precedence observable, avoid surprising implicit overrides, and keep sensitive configuration such as credentials out of source control.

When debugging configuration, identify every possible source of the property, determine the precedence rules of the framework being used, and inspect the effective runtime configuration. Avoid changing several sources at once because that can hide which source actually controls the result.

Key points

• Multiple configuration sources can define the same property.
• Precedence determines the effective runtime value when sources conflict.
• Exact precedence is framework- and version-dependent.
• Higher-priority overrides should be intentional and observable.
• Secrets should generally come from secure runtime configuration rather than source control.

Interview questions

What does configuration precedence mean?

Configuration precedence is the rule used when multiple sources provide a value for the same property. The source with higher precedence determines the effective value. This lets an application keep general defaults while allowing deployment-specific overrides. The exact ordering depends on the framework or configuration system.

Why should you avoid hard-coding environment-specific configuration in Java code?

Hard-coding deployment-specific values couples the application binary to one environment. External configuration allows the same artifact to run in different environments with different settings. It also makes operational changes possible without changing business logic. Sensitive values can additionally be supplied through appropriate secret-management mechanisms.

How would you debug a configuration value that has an unexpected runtime value?

First, identify the exact property name and every source that could provide it. Then check the framework's documented precedence rules and inspect which sources are active in the failing environment. I would also verify whether the value is being transformed, renamed, or supplied by an external configuration system. Finally, I would inspect the effective configuration using safe diagnostics without exposing secrets.

How does Spring Boot handle configuration from multiple sources?

Spring Boot aggregates configuration from multiple property sources and resolves a final value according to its documented property-source precedence. Common sources include application configuration files, environment variables, system properties, and command-line arguments. A higher-priority source can override the same property supplied by a lower-priority source. The exact list and ordering should be checked against the Spring Boot version being used.

How would you design configuration for a Java service deployed across development, staging, and production?

I would keep safe, non-sensitive defaults in version-controlled configuration and use deployment-specific sources for values that differ by environment. Secrets would be supplied through a dedicated secret-management mechanism rather than committed files. I would document the precedence rules and make the effective configuration observable without exposing sensitive values. For feature flags, I would also define ownership, default behavior, rollout rules, and what happens if the flag service is unavailable.