Configuration Sources and Precedence

Configuration precedence defines which value wins when settings are supplied by multiple sources. Applications should document a deliberate order, parse and validate the selected values, and test conflicting inputs.

Applications commonly receive settings from several places: built-in defaults, configuration files, environment variables, command-line arguments, or runtime inputs. A precedence policy specifies which source wins when more than one supplies the same setting.

There is no universal precedence order. A common policy lets more specific or deployment-controlled inputs override defaults, such as defaults < file < environment < command-line arguments. The application should define and document its own order, including how runtime inputs fit into it.

After merging sources, validate the resulting configuration: environment values are strings, and may need parsing into booleans, numbers, or other types. Also distinguish an absent setting from an explicitly supplied value such as `false`, `0`, or an empty string.

Treat sensitive settings carefully. Avoid logging secret values, and consider whether a source such as a file or environment variable is appropriate for the deployment. Tests should cover conflicts between sources as well as missing, invalid, and explicitly empty values.

Key points

• Precedence resolves conflicts when multiple sources define a setting.
• Choose, document, and test an order; there is no universal order for every application.
• Parse and validate the winning value, especially when reading environment variables.
• Do not confuse an absent value with a supplied false, zero, or empty value.
• Keep secret values out of logs and diagnostics.

Interview questions

How would you implement configuration precedence in Python?

I would represent each source as a mapping, parse values into the expected types, then merge them in the documented order. In Python, successive dictionary updates or dictionary unions can implement right-hand-wins behavior. I would validate the final configuration and avoid relying on truthiness to decide whether a value was supplied. Tests should verify both the winning value and the handling of absent or invalid values.

What can go wrong when reading configuration from environment variables?

I would keep precedence separate from type conversion and validation. For example, an environment variable containing `false` is still a string until the application parses it, and calling `bool` on a nonempty string would produce `True`. I would use explicit parsers for booleans and numbers, report invalid values clearly, and apply validation to the resolved configuration. Tests would include malformed inputs and boundary values.

What does configuration precedence mean?

Configuration precedence is the rule for resolving a setting that appears in multiple sources. For example, a service might choose defaults < file < environment < command-line arguments, so the command line wins a conflict. The order is an application decision rather than a universal Python rule. I would document it and test cases where sources disagree.

How would you design a safe configuration precedence policy for a service?

I would define which sources are trusted and what each source is allowed to control, then make the precedence and secret-handling policy explicit. A higher-priority source can unintentionally replace a safe value, so unexpected overrides should be observable without exposing sensitive contents. I would validate the final settings at startup and fail clearly for invalid required values. Tests should cover conflicts, missing settings, and accidental secret logging.